From Built to Launched: What AI-Assisted Web Apps Still Need

Why the last twenty percent got relatively harder

Building the visible application is now fast. Routes, forms, components, state, and a reasonable interface arrive in an afternoon, and that used to be most of the calendar time in a small project.

What did not change is everything with no screen attached: what happens when a token expires, what happens when two requests race, what happens when a migration half applies, what happens when a third party is down, what it costs at a thousand users, and how you find out any of it went wrong.

That work was always the harder part. It just used to be a smaller fraction of a longer project, and now it is most of what remains.

The practical consequence is that the definition of done has to be explicit. An agent finishing a feature has satisfied the request it was given, and the request did not mention token refresh, rate limits, or what to do when the storage bucket is unreachable. That is a specification failure rather than a model failure, and it is fixed the same way you fix any specification failure.

The checklist agents skip unless asked

Authentication edges. Signing in works in every generated app. What is usually missing is token expiry and refresh, session revocation, multi-device behavior, and an authorization check on every path rather than on the ones that were being looked at. Ask specifically: which endpoints can be called by a user who owns nothing, and what happens then.

Data lifecycle. Deletion, export, retention, and what happens to related records. These carry legal obligations in many jurisdictions and are pure back-end work with no visible output, which is exactly the profile of work that gets skipped.

Migrations. The highest risk generated code you will run, because a bad endpoint is revertible and a bad migration may not be. Require a down path or an explicit statement that there is none, test against a copy of realistic data rather than an empty schema, and never let a migration run unattended on first execution.

Idempotency on writes. Users double click, networks retry, and webhooks redeliver. Anything that creates a record or charges money needs a key.

Observability. Structured logs, error capture with context, and one alert that reaches a human. An application you cannot see is one you cannot operate, and the first incident is a bad moment to discover you have no logs.

Backups, tested. An untested backup is a belief. Restore one before launch.

Cost controls. A spend alarm on infrastructure and on any model API in the request path, because the failure mode of an unbounded loop is a bill.

Verify what you cannot review

When generation is cheap, more code ships than anyone reads carefully. Since review does not scale, verification has to.

That means tests around the paths where being wrong is expensive rather than tests everywhere: authorization boundaries, money movement, data deletion, and anything with an external side effect. It means running the app against realistic data volumes before launch, since generated queries are correct and frequently unindexed, and a missing index is invisible on a seeded table with fifty rows.

It also means one rule stated explicitly to the agent: never modify a test to make it pass. A suite quietly rewritten into agreement with broken code removes the only safety net covering the code nobody read.

And walk the flows yourself once, as a user, before launch. Not as a review of the code, as a use of the product. It takes twenty minutes and it catches the class of problem that no test asserts, which is the flow that technically works and makes no sense.

Why the second project is faster than the first

Most of what you decide while shipping is reusable and most teams throw it away.

The auth pattern you settled on, the migration procedure that worked, the deployment steps, the monitoring you wish you had added earlier, the third party whose sandbox behaves differently from production. That knowledge is what makes a second launch calm, and it usually lives in one person's memory and a closed session.

RDK keeps it retrievable. Files from local vaults, docs, and code are indexed as encrypted private chunks, and agents search those chunks before querying a model, so your launch checklist, conventions, and hard-won operational notes are pulled in when a task touches them rather than re-explained. Token spend drops 80 to 90 percent on repeated or reference-heavy work because the answer is retrieved instead of regenerated.

Stacked retrieval sets the proportions: a private index over your own material answers 40 to 65 percent of queries, the public network adds 15 to 20 percent, and the model handles the remaining 5 to 10 percent. For shipping work specifically, almost everything valuable sits in the first bucket, because it is your stack, your constraints, and your previous mistakes.