What an MVP owes you in twelve weeks

Twelve weeks after an MVP development company starts, you should be holding seven objects, not a slide. A repository in an account you control. One workflow a person who did not build it can run from a clean machine. The sentence that defines done, already true or already failed. The list of what was cut, written down rather than forgotten. A way to undo the release. A measurement of whether the workflow worked for a real user. And the credentials — cloud, data, third parties — in your name. If week twelve arrives as a demo and a promise, the test has already failed. The Digital Services Playbook states the outer bound in one checklist line: ship a functioning minimum viable product that solves a core user need as soon as possible, no longer than three months from the beginning of the project, using a beta or test period if needed (U.S. Digital Services Playbook, Build the service using agile and iterative practices).

Three months is not a rival to the longer scoping rule, and it is not a promise that every product is finished in a quarter. The six-month bound on a first release — one workflow, one user type, everything else deletable without killing the hypothesis — is argued in how to scope an MVP so it ships. Twelve weeks sits inside that bound. It is the inventory you should be able to point at halfway, while there is still time to stop. A plan that contains nothing a user can touch until month six has not used the first half. It has spent it.

The playbook was written for government digital services, and two of its neighbouring lines are easy to misuse. It also says to release features and improvements multiple times each month, and to keep delivery teams small. Those describe a team that already has a service in users' hands. They are not a demand that a founder's first quarter match a mature product organisation's cadence. The line that binds at week twelve is the first one: working software for one core need. The rest of the checklist — version control, the whole team having access to it, a prioritised backlog, code review — is how that software stays yours rather than becoming a recording of a demo.

What you are not buying is a performance cluster. DORA's 2024 Accelerate State of DevOps report let four clusters emerge from the answers of nearly 3,000 working professionals, and it did not set the levels in advance. In that year's snapshot, the elite cluster — 19% of respondents, with an 89% uncertainty interval of 18–20% — deploys on demand, multiple times per day, with a change lead time under one day, a change fail rate of 5%, and failed-deployment recovery in under an hour. The low cluster — 25% of respondents, interval 23–26% — deploys between once a month and once every six months, and its change fail rate is 40%, with recovery between one week and one month (DORA, Accelerate State of DevOps Report 2024). Read the columns separately. The 19% and the 25% are shares of respondents. The 5% and the 40% are how often those clusters' changes fail. They are not the same kind of number, and the uncertainty interval is on the shares.

A twelve-week MVP that deploys on demand has usually skipped the product and built a pipeline. That is the wrong object. The DORA figures are here so you do not hire a firm to make you elite, and so you do not accept a firm that cannot undo. The low cluster's recovery, measured in weeks, is what it feels like when the only copy of the release lives on someone's laptop. The deliverable is one workflow you can ship and reverse. Daily deployment is a later problem, and it is a good one to have.

Object one: the repository, in your organisation, with history. Not a zip, and not a repository you will be added to at acceptance. The playbook's same checklist says to use a source-code version control system and to give the entire project team access to the issue tracker and to version control. Access that starts in week twelve is a tour. Access that started in week one is a record: which decisions were made when the scope was still movable. If you cannot open the history on your phone without asking anyone, you do not have this object.

Object two: one workflow a stranger can run. Pick the sentence from the scope and follow it with someone who was not in the sprint — you, if you are honest, or a user who has not been coached. Include the ugly path. Empty state, third-party timeout, the wrong password, the record that is missing a field. A happy path on a seeded account is a demo. The playbook's test is a core user need, and a core need includes the moment the need cannot be met. If the stranger gets stuck and the only remedy is the person who built it, the workflow is not in your hands yet. It is in theirs.

Object three: the acceptance sentence, already scored. It is either true or it is not. "Clinics can complete an eligibility check without calling us" does not become true because the screen exists. Write down the evidence: how many real attempts, what counted as success, what you did with the failures. A sentence nobody has tried to falsify is a slogan. This is the same acceptance the founder has to own; the twelve-week difference is that the evidence now exists, rather than being promised for the end.

Object four: the list of what was cut, still written down. Cutting is how the three-month line is met, and the cut list is how you stop the argument that something was forgotten rather than deferred. Each line should say what it was, why it can wait, and what would make it next. A roadmap that lives in a founder's memory will be remembered differently by the vendor, and the difference will be discovered in an invoice. The deletion test itself — would the hypothesis still be testable without this — belongs to the scoping article. The object you hold at week twelve is the outcome of having applied it, on paper.

Object five: a way to undo the release. Name the person who can put the previous version back, and the page or command they use, and have them do it once while you watch. This is the entire lesson of the low cluster's recovery time. A rollback you have not performed is a theory. It does not need to be elegant. It needs to have happened once, on the real account, before a customer is the person who discovers it does not. If the product's first release is still behind a beta flag, undoing it can be as small as turning the flag off. Small is allowed. Unrehearsed is not.

Object six: a measurement that is not a feeling. The playbook asks which metrics will indicate how well the service is working for its users, and it says to watch them rather than to present them at the end. For one workflow, one number is enough: attempts, completions, and the point where people stop. Vanity totals — accounts created, pages viewed — do not tell you whether the sentence is true. If the only evidence of success at week twelve is that the team is proud of the screens, you have a portfolio piece. You do not yet have an MVP.

Object seven: credentials in your name. Cloud account, domain, source host, email provider, error tracker, the model provider if a model is in the workflow, the card on the invoice. A vendor who holds these "so you don't have to think about it" is holding the company. Transfer is a task with a checklist, and it belongs inside the twelve weeks, not in a handover appendix nobody schedules. The same is true of secrets. A production key that exists only in a vendor's password manager is not your key.

Two objects people expect are deliberately not on the list. A pitch deck is not one of them. Neither is a second workflow, a native mobile app, or an assistant that answers questions the hypothesis does not ask. If the hypothesis is not itself about a model, the model is scope you add after the sentence is true. If the hypothesis is about the model, then the evaluation that says what a wrong answer is belongs inside the twelve weeks, because the sentence cannot be scored without it. That is a smaller claim than a platform. It is a threshold and a set of examples, attached to the one workflow.

The commercial shape that matches the inventory is a bounded piece of work with a named end, not an open retainer that is always almost done. An AI integration sprint is that shape when the workflow has to land inside a product you already have: one capability, one deliverable, a date. A first product that does not exist yet is the same discipline with a different door. Either way, week twelve is a pile of objects you can point at. It is not a status meeting.

What this looks like when the product is already a workspace other people share, rather than a single script, is ordinary and specific. A multi-tenant agency operating system we built had to put projects, clients, contracts, and an admin-trained knowledge assistant in one place, because the permission model and the assistant constrain each other. The twelve-week version of that kind of product is not all of those modules. It is one of them, end to end, in the customer's account, with the others written on the cut list. Describing the whole system is not a claim about how fast it was built. The durations on that work are not the point, and several figures of that kind on this site are still estimates. The point is which objects exist.

There is a clock you should not start. You cannot name the one user and the one workflow, and you are hoping twelve weeks of building will reveal them. It will reveal a tour of the backlog instead, and the playbook's three-month line will be missed for a reason that was visible on day one. Do the cutting first. Then start. A startup software development company is useful once the sentence exists and the seven objects are the engagement, not a surprise at the end. If you want the labour arithmetic that turns those weeks into a budget, what an MVP build actually costs is the companion, and it is a method rather than a rate card. AI product development is the capability underneath, when the workflow is a product and not a one-off script.

On the Friday of week twelve, ignore the demo reel. Open the account you were told is yours and look for the seven. History you can read. A workflow a stranger just finished, including a failure. The sentence, with a count beside it. The cut list. A rollback that has been done once. One metric that would be embarrassing if it were zero. Credentials that do not require the vendor to stay in a good mood. Missing two is a conversation you can still have, because you are inside the six-month bound and the objects are specific. Missing five is a reason to stop paying for the next twelve weeks until the first twelve are real.