Both generators met all six requirements. What they did next is the whole review.

I gave two AI app builders the same six numbered requirements, on free accounts, with no follow-up prompts. Both met all six. One finished in 109 seconds, the other in two to three minutes. The two builds cost within a few cents of each other.

On every axis I had planned to score, the result was a shrug.

Then I opened what they had written, and the review turned out to be about something I had not thought to measure: what each tool did that nobody asked it to do.

The unrequested work is the interesting part

Six requirements is a small brief, and a small brief leaves a lot of decisions unspecified. Every one of those gaps gets filled by something. That filling is where the two tools stopped resembling each other.

One of them wrote its persistence key as a bare string. The other wrote a versioned one — the equivalent of myapp.things.v1 rather than things.

That difference costs nothing today. It costs everything the first time the shape of the stored object changes, because a versioned key is a schema you can migrate past and a bare one is a schema you are stuck with. You either write a migration that guesses at the old shape, or you blow away everyone's local data. Nobody in the brief asked for a version suffix. One tool decided the future existed.

The same tool formatted currency through the platform's number formatter rather than concatenating a dollar sign onto a rounded number, and it put persistence in its own module instead of inlining it next to the render logic. It also added a projection the brief never mentioned — taking the monthly total it had been asked for and extrapolating it out to a year, with the arithmetic correct, which incidentally proved one of the trickier requirements was actually working.

The faster tool made unrequested calls too, and they were good ones — just aimed somewhere else. It added a restore action for items you had removed, and it kept a piece of information visible that one of my requirements would otherwise have destroyed. Both of those are the kind of thing a person would ask for on a second pass.

So neither tool was lazy. They were guessing about different futures. One guessed about the data outliving the code. The other guessed about the user changing their mind.

What this actually tells you

Be careful how far you push this, and I want to be first in line about the limits.

This was one brief, run once, on each tool. It is not a benchmark. Anyone reporting a winner from a single prompt is reporting a coin flip with extra steps. I also did not audit either codebase — I read what they produced and noted specific structural decisions, which is a much weaker claim than "this one writes maintainable code."

What I do think generalises is the evaluation method, not the verdict.

If you are choosing between generators, the requirements checklist will tell you almost nothing, because they will all pass it. Every one of these tools is good enough to satisfy a well-specified list. The list is the easy part.

The signal lives in the margin. Look for the decisions nobody specified, because those are the ones you inherit:

• Storage and schema. Is there a version, a namespace, any acknowledgment that the shape might change?
• Formatting and locale. Did it reach for the platform's formatter, or concatenate a symbol onto a number?
• Structure. Is the persistence layer separable, or is it braided through the view?
• Scope. Did it stop exactly at the brief, or did it add something that suggests it modelled the problem rather than the sentence?

None of those show up in a feature table. All of them show up in the diff.

The other thing worth measuring

There is a second axis I did not expect to matter and now watch closely: whether the tool's billing unit lets you price a job before you commit to it.

One of these tools bills in a flat unit you can multiply on paper before you spend anything. The other bills against the model's output, which means the same request costs more as the project grows, and a request that fails still bills you for everything the model produced while failing.

That is not a price difference. Both were within pennies on this build. It is a forecastability difference, and if you quote fixed-price work it is the more consequential of the two.

I published the full run with the exact figures, the six requirements, the screenshots of both outputs and a third tool given the identical brief — the whole comparison is here, including the tier trap where one vendor's more expensive plan carries the same allowance at double the unit price.

The takeaway I keep coming back to is smaller than a recommendation. When a generator finishes, do not just check the requirements off. Read the parts you did not ask for. That is the only place these tools are still telling you something about themselves.