Learning things at the worst possible time
Most failed launches we’ve seen share an autopsy, and it’s rarely bad code. It’s bad timing. The finance team’s one non-negotiable report never made it into the spec, and nobody found out until the accountant logged in on day two. The migration script behaved perfectly against a hundred test rows, then met four million production rows with nulls in columns the old system swore were required. The integration ran all month and fell over at nine on Monday morning, when real traffic arrived.
None of these failures happened when the mistake was made. Each one surfaced months later, at the exact point where fixing it was most expensive. That gap, between when a problem is created and when it is discovered, is where projects die.
What AI changed, and what it didn’t
For decades, writing the code was the slow part. Whole methodologies existed to squeeze more lines out of a quarter. AI ended that constraint: an agent now produces in an afternoon what a team once produced in a quarter, and the tempting conclusion is that everything else can collapse too. Prompt in, production app out, one step.
But generation was never where reliability came from. The facts that kill projects, the missing report, the dirty data, the Monday traffic, are not in the prompt and not in the model. They live in your business, and they surface only when someone goes looking. AI made code cheap; it made unverified code exactly as cheap. We’ve written before about why a prompt can generate an app but can’t operate one. The practical consequence is that the bottleneck has moved from writing software to checking it, and a one-step pipeline has nowhere to put the checking.
That is what the four stages of a Sapilon project are for. Not ceremony, and not a return to waterfall paperwork: four places to learn hard facts, arranged so that each fact surfaces while it is still cheap.
Design: be wrong for the price of a conversation
A Sapilon project starts with a short guided interview about your software: its size, its stack, your team, what it needs to do. From that, Sapilon proposes an architecture and a migration roadmap, then builds the new frontend against mocked data. No backend exists yet, and that is the point. You click through the actual screens of the system you’re going to get, and the finance team gets to fail to find their report while the fix is a conversation about a mock.
Every requirement misunderstanding is caught eventually. The only question is the price. In Design it costs an afternoon; at go-live it costs a rollback and a weekend. Front-loading the cheap version of that discovery is the single highest-leverage hour in the project.
Build: full speed, inside a fence
Build is where the agent earns the “fast” half of the promise. The backend, database, and APIs are generated against maintained, best-practice templates, and the whole application runs end-to-end on a Build Server, a real development environment rather than a preview widget.
The reliability work here doesn’t come from slowing the agent down. It comes from structure. Ownership zones decide what the AI may change on its own, what needs a human approval, and what it may not write at all, and every action it takes is logged, diffable, and reversible. Because the boundaries are enforced by tooling rather than by vigilance, the agent can move at machine speed without asking humans to review at machine speed. That trade is the heart of the whole system: constraints are what make the velocity safe to accept.
Rehearsal: practice the riskiest day until it’s boring
Go-live is the most dangerous day in a project’s life, and the data migration is the most dangerous hour of that day. So we do the whole day in advance. Rehearsal deploys the finished system to a pre-production Rehearsal Server in your own AWS account and runs it like it’s already real: user journeys walked end-to-end, every change passing automated review with a full audit trail, security and running costs checked against expectations, and the migration drilled until executing it is routine.
The nulls that would have surfaced at midnight surface on a Tuesday afternoon instead, on a server no part of your business depends on. By the time you cut over, go-live isn’t a first attempt. It’s a repetition of something that has already worked several times, which is the only kind of go-live worth having.
Live: where most of the life happens
An application spends a few weeks being created and years being changed, and the Live stage is built for the years. The new system takes over on your Live Server, the old one retires, and the machinery from the earlier stages stays on duty: monitoring, backups, versioning, upgrade-aware diffs when the underlying platform moves forward. The next feature request doesn’t skip the pipeline either; it travels the same path from design to rehearsal to live, just at a smaller scale.
And because everything is plain Git, open libraries, and your own AWS account, the stage model keeps working whoever operates it. The lifecycle page covers what years two through five look like in practice.
Why an orchestra rehearses
An orchestra is a hundred people who can each sight-read the score. They rehearse anyway. Not because anyone doubts the musicians, but because the performance happens once, in front of everyone, and ensemble failures don’t show up until the ensemble plays. The rehearsal is not the opposite of virtuosity; it’s what lets opening night run at full tempo.
Software built by AI is now full of virtuoso players. The four stages are the rehearsal schedule: Design, Build, Rehearsal, Live, each one placed where a particular kind of surprise is cheapest to absorb. The slow part of software was never the checking. It’s the rework when you skip it.