It looks fine. That's the problem.

Every other post in my feed this month is someone who built an entire SaaS over a weekend with one prompt. Congratulations to all of them. I shipped a fifteen-module application in ten days this month, designed and built through an AI workflow, and that is exactly why I do not believe most of them.

Not because it cannot be done fast. It can. Because the part that makes it work is the part nobody posts about: everything that happened before the first prompt.

What happened before the first prompt

The application was a business operations platform whose interface I had already designed end to end, more than 190 screens across a multi-module workspace. The design was finished. None of it existed in code.

I did not start with a chat window. I started with the finished Figma, a design system extracted out of it, and fifteen written rule documents, with the design rulebook as the one to read before building any screen. The system ended up as 126 catalogued components in 29 families, and every one of them names the frame or export it came from. Every screen file opens by naming its Figma canvas, its frame numbers, and what those frames leave unanswered.

Where the design said nothing, the product said nothing, on purpose. Modules with no supplied screens shipped as deliberately blank routes: no title, no description, no friendly illustration, just a way back. Even a title asserts something nobody agreed. One module sat behind that blank placeholder for nine days, with an owned open question against it, and was built the day its screens arrived. Not before.

Defects in the supplied frames, a gap that was 20 pixels on one screen and 24 on the next, a control drawn at two heights, were built as drawn and catalogued, not quietly repaired. Repairing a drawn inconsistency is a product decision, and that call belongs to the product owner, not to me and definitely not to a model.

Ten days later: fifteen modules, around 651 source files and 106,000 lines, and more than 45 logged decisions recording why each part is the way it is.

The same story on a different product

On a rebuild of a trading card game platform, the first week produced no interface at all. It produced a knowledge workspace: competitor profiles, personas, module definitions, information architecture, and an open questions file where every unknown has a named owner.

One rule did the heaviest lifting. Product detail is never inferred. Module names, features, user roles and business goals come only from what the product owner supplied. Anything unconfirmed becomes a question with an owner, not a confident sentence in a document.

Then the build: around 283 source files and 77,000 lines, with 82 test files, across four releases in under two months.

Why an assistant is dangerous in exactly one way

The workflow is not the interesting part. The constraint is.

Remove the design-to-development handoff and something disappears that nobody budgets for. The developer reading a Figma file is also a second pair of eyes. They get stuck. They get stuck on the module with no screens, the empty state nobody drew, the two values that disagree, and every time they get stuck, a question reaches the designer. Getting stuck is a quality mechanism.

An assistant never gets stuck. It proceeds, plausibly and at speed, and produces something that looks finished. Every safeguard above is a manufactured version of getting stuck: the provenance, the blank routes, the catalogue of defects, the never-infer rule. They cost very little next to what they prevent.

What prompting with nothing behind it actually buys

That is what plain-language prompting with nothing behind it buys. Not a product. A confident draft of one.

It looks fine, which is precisely the problem. Underneath is an interface with no reason for any of its decisions, and code carrying weight nobody ever chose, because nobody decided what the thing was for. Good enough for an MVP demo. After that you spend hundreds of dollars, sometimes thousands, regenerating your way out of a thinking problem, and thinking problems do not regenerate away.

Speed also changes which mistakes are expensive. When a screen took days, a wrong assumption surfaced in review before much was built on top of it. When a screen takes an hour, a wrong assumption is three modules deep before anyone notices, and it looks exactly like a decision.

The IP line

The other thing I keep seeing in those same posts is that the output is their IP. Built by a model trained on everybody else's.

Hard to hold both of those at once with a straight face.

My own caveats, since I am handing out criticism

The ten-day build has no unit test suite on its frontend. It has strict types, lint and build checks across every workspace, a boot-time assertion that ties the api to the module list, and two purpose-written check scripts aimed at the failures this workflow actually produces, which are drift and invention rather than logic errors. That is a narrower net than tests, and I would not run a project with a real data layer that way.

The workflow suits one person who can hold both roles. I genuinely do not know how it behaves with two designers and three engineers, where the handoff is also a coordination mechanism rather than pure overhead.

And none of it has been in front of a user yet. The conversion changed how the product gets made, not how it gets validated.

None of this is an argument against AI

I converted my entire practice to it. The speed is real, and the biggest gain was not even the time. It was that every design judgement now gets made against a running interface instead of a picture of one, so the empty states, the dark theme and the exit animations that no static frame ever draws get designed at the moment of decision instead of in a correction round that never happens.

But it has never once rescued a design system, a research base or a product decision I had not already made rigorous. It only ever paid back the ones I had.