AI Gets You to "Basically Done" Fast. Going Live Is Still a Person's Job.

The app worked. Every screen, every button, the full click-through. A founder could sit down, run the whole thing start to finish, and watch it do exactly what was asked. By any fair read, the build was done.

Then we went to put it in front of real users, and a second project appeared that nobody had put on the calendar.

Going live meant moving the builder workspace and the connected accounts out of our names and into the founder's, so they would own the software instead of renting it from us. It meant splitting the one working setup we had been building in into real, separate staging and production environments. It meant a dependency file that passed on every machine we owned, then failed the first time we ran a clean install on fresh infrastructure, which is the kind of error that does not exist until the exact moment it stands between you and your launch. It meant standing up a real hosted address a stranger could reach. And it meant getting a specific person to look at the finished thing and say, in writing, yes, this is what we agreed to.

None of that is glamorous. None of it shows up in a demo. And almost none of it is the part an AI coding tool is good at.

That gap is the whole point here. AI got the build to 90% fast. It did close to nothing for the last 10%. And the last 10% is exactly where "we're basically done" and "you can use it" pull apart by a lot more distance than anyone plans for.

Where the speed actually comes from

It helps to be precise about the speed, because it is real and we rely on it every day. Modern coding tools are very good at generating. Give them a clear screen, a known pattern, and a described behavior, and they produce working code faster than a person typing it by hand. That is why a build can look finished so quickly now. The middle of a project, the stretch that used to eat weeks, compresses hard.

The edges do not compress the same way, because the edges are mostly not code. Moving accounts into a client's name is a chain of judgment calls about ownership and access. Splitting one environment into staging and production is a decision about what is allowed to break, and where. Reading a failure that only appears on clean infrastructure means holding the whole system in your head and reasoning about what is different about this machine, at this moment. A model can help with pieces of each of those. It cannot own any of them, because owning them means being the one accountable when they go sideways at the worst possible time.

This is not a lonely opinion. The running conversation among people who build with these tools has settled on the same spot: the bottleneck in agent-assisted development is verification, not generation. The agents are everywhere, and humans still run the loops. The work that decides whether a launch happens this week or slides into next month keeps turning out to be that final stretch, the part where a tool has to become genuinely reliable at one specific job inside one specific system. That is where the real work starts, and it stays stubbornly human.

The question to ask when you hear "basically done"

Here is what that should change for a founder.

When a shop tells you the build is basically done, believe them, and also translate it. What you are hearing is the fast part reporting in. It is real progress, not a line. But "basically done" describes the 90% that compressed. It says almost nothing about the 10% that did not, and the 10% is the part standing between you and a user who can actually log in.

So ask the second question. Not "is it done," but "what specifically sits between basically-done and my first real user typing into this thing." A good answer is concrete: accounts move here, the database and the code repository split like this, we run a clean install on the real infrastructure to catch what only breaks there, we stand up the live address, and you sign off on a defined list. A vague answer, or a surprised one, is the tell. It means the launch was assumed instead of planned, and assumed launches are how a project that looked two days from done stays two days from done for a month.

Our fix for this is boring and it works. We treat going live as its own milestone, with its own definition of done, scoped and dated apart from feature-complete. Feature-complete is a real date. Live is a different real date. Pretending they are the same date is the most common way a build that genuinely went fast still feels slow at the finish, and it usually has nothing to do with the code being good or bad. The code was fine. The launch was a project, and no one wrote it down.

The speed AI gives you is worth having, and it is not going away. It just arrives front-loaded. It makes the middle cheap and leaves the two ends about as expensive as they always were, which means the ends are now most of what you are actually paying a good team for. If you are a founder about to hear that your product is nearly finished, hold two dates in your head instead of one, and ask what lives in the space between them. That space is where your launch actually is.