An AI-assisted MVP in four to six weeks: what agents draft, and what we never cut

Four to six weeks from discovery to a working product with real users is a claim that invites skepticism, and it should. Our cycle used to be twelve weeks. The time came out of three places: agents that draft code, tests and documentation, prototypes that reach users in days, and quality checks that run on every commit instead of in a phase at the end. It did not come out of review, user research or security. This is the week-by-week breakdown, with what agents do, what people do, what we cut, what we refuse to cut, and where it goes wrong.

The shape

One-week sprints, with a demo at the end of every one. Week 1 discovery. Week 2 flows, a tested prototype and architecture. Weeks 3–4 build. Weeks 5–6 stabilization and launch.

The four-week version folds stabilization into the last build sprint and launches at the end of week four. It fits a product with one user type, at most one integration, and system access on day one. Everything else gets six.

The first reaction is usually that build is too short. The answer has two parts. Design has already answered the questions that normally get answered in code, so engineers build something specific rather than discovering what to build. And the first draft of most code is written by agents from the agreed flows, data model and API contracts, so engineering time goes into review, integration and the hard cases instead of typing the obvious ones.

Who does what

Stage	Agents draft	People decide
Discovery	Workflow maps from session notes, a first list of edge cases	A consultant runs the interviews; the sponsor signs the one-page scope
Prototype	Clickable variants of the core flows	The designer picks; users test; most variants are thrown away
Architecture	Options with their trade-offs written out	A senior engineer decides tenancy, data model and security model
Build	Code, unit and integration tests, API contracts, migration scripts, documentation	A named engineer reviews and merges every change
Launch	Runbooks, release notes, monitoring configuration	The delivery lead approves the release; the sponsor accepts it

Week one: discovery

We talk to users. Not stakeholders, users. The people who will open this thing on a Tuesday. We watch how they do the job today, which is usually a spreadsheet, a messaging group and a phone, and write down the workflow as it is, including the workarounds.

Agents help with the paperwork. They turn session notes into workflow maps and a first list of edge cases, and a consultant corrects both the same day. They do not do the interviews. A model summarizing a conversation it did not hear is a guess with good formatting.

The output is a one-page statement of what the first release does. Three things, at most. Everything else goes on a list with a reason attached. “Moved to release two because fewer than two of eight users mentioned it” is a sentence a sponsor can accept. “Out of scope” is not.

Week one is also when we ask for everything we will need later: sandbox credentials, test data, the name of the client’s security reviewer, and a date for every user session in the program.

Week two: flows, prototype and architecture

From the discovery notes, agents generate clickable versions of the core flows in a day. Several of them. The designer picks the ones worth showing, and users click through them by midweek. Most get rejected. That is the point. A flow thrown away after one session cost a day. The same flow found to be wrong in week five costs the launch.

A senior engineer draws the data model from the flows. Not from the database. If a flow needs a piece of information, it appears in the model; if nothing on screen needs it, it does not, whatever the existing system stores. Agents check the model against every flow and list the gaps. The engineer decides what to do about them.

By the end of the week the surviving flows are taken to high fidelity and tested with users a second time. Architecture is decided in the same days, deliberately after the flows are known. Multi-tenancy, queueing, caching, how sessions and permissions work. Agents can lay out the options. The decision, and the name against it, belongs to a senior engineer, and so do the security model and the data model. These are the choices that are expensive to reverse, and they are not delegated.

The deployment pipeline, with tests and security checks wired in, exists before the first feature does. A product that cannot be deployed is not a product.

Weeks three and four: build

Two one-week sprints, each ending with a demo of working software. Agents draft the code, the unit and integration tests, the API contracts and the documentation against the agreed flows and data model. An engineer reviews each change, rewrites what is wrong, and merges it. Nothing reaches the main branch on an agent’s authority.

What changes is where engineering time goes. Less of it goes into boilerplate. More goes into review, integration with the client’s systems, permissions, and the cases the flows did not anticipate. Those were always the hard part, and people still do them.

Scope moves in these weeks more than any other. Something takes longer than planned, usually an integration. It moves to release two, with the reasoning written down, and the date holds. Sponsors sometimes push back here. The conversation is easier when the week-one list already exists and the item has a reason attached.

Weeks five and six: stabilization and launch

Real users, in production, with monitoring watching. Bugs get fixed. Performance gets checked under something close to real load, not a laptop. Agents draft the runbooks and handover documentation from the code and the change log, and the people who built the product correct them. The last days are handover, and a plan for release two that the discovery list has been feeding since week one.

What does not compress

Agents make drafting fast. They do nothing for the parts of an MVP that wait on someone.

Access to systems and data. The plan assumes sandbox credentials in week one. When they arrive in week three, the integration waits, and so does the launch.

User feedback. A prototype generated in an hour still needs a person with a calendar to click through it.

Decisions. What the first release does, which trade-off to accept, whether the number the new system calculates is the right one. These belong to the sponsor and the product owner.

Security and compliance review, procurement, app store review and cutover windows. None of them move because the code is ready.

What we cut

The third feature. Always. Discovery finds three things that matter and eight that someone wants; the eight wait.

Admin screens. In the first release, configuration is done by us, by hand, on the client’s behalf. An agent could draft an admin interface in an afternoon. It would still need review, tests and maintenance for settings that change twice in the first three months, and that is a poor use of a build week.

Integrations that can be manual for a month. If the product needs data from another system and that data changes weekly, release one gets a CSV import and release two gets the API.

Anything with the word “eventually” in front of it.

What we never cut

User research. Skipping discovery to gain a week of build has produced, every time we have seen it done, a product that needed rebuilding. Faster building makes this worse. The wrong product simply arrives sooner.

Review of AI-generated changes. Every one, by a named engineer, before it merges.

Automated tests and a deployment pipeline. These are not features and they are not optional. A product launched without them is a liability from day one.

Monitoring and error reporting in production. If we cannot see it fail, we cannot fix it.

Security basics. Authentication done properly, secrets out of the code, dependencies checked. A penetration test comes later; the fundamentals do not wait for it.

A working rollback. Every deployment can be reversed. The first deployment is rehearsed.

Governance

These rules apply to every engagement, whatever the timeline. Without them, AI-assisted delivery produces a product nobody can support or audit.

• Human in the loop. Every AI-generated change is reviewed, tested and merged by an accountable engineer.
• Every commit runs automated tests, security scanning, dependency and license checks, and secret detection. A failing check blocks the merge.
• AI contributions and prompts are logged against the change, so the audit trail shows what was generated and who approved it.
• Client code and data are never used to train models. We use enterprise model endpoints with data retention turned off.
• Architecture, security and data-model decisions are made by senior engineers, not agents.

Where it goes wrong

The sponsor who agrees to three features in week one and wants six by week four. We get the one-page statement signed, literally, and bring it to every demo.

The client system that was going to provide the data and does not, because its team is busy. The CSV import rule came from this, and so did asking for access before anything else.

User sessions that are hard to schedule. On a one-week sprint a missed session costs a whole cycle of feedback, so every session for the program is booked in week one, before we know what we will show.

Trade-offs

Four to six weeks produces a narrow product. That is the intent, and it is not right for everything. A regulated system with a fixed compliance scope, or a replacement for something that already has fifty features people use daily, needs a different shape. A mobile app bound for the stores typically needs six to eight weeks, because store review sits between the build and real users. We say so in the first conversation.

Review load is real. Agents produce drafts faster than people can read them, so the pace of a build is set by review capacity, not by how quickly code is generated. We size the team for review. Generated tests carry their own risk: they can pass by checking what the code does rather than what the flow requires, so reviewers read tests against the acceptance criteria with the same care as the code.

And the fixed dates mean that occasionally something we would have liked to include does not make it. We would rather ship the narrow product on the date and learn from real users than ship the wider one late and learn from ourselves.