MVP development
An MVP that is verified before it launches.
Minimum does not mean unreviewed. We scope the first release in a week, run it through design approval, automated QA and manual review, and operate it after launch so the second release starts from a record.
Start a project- week to a scoped, priced PRD
- 1
- sign-offs before launch
- 2
- of the record kept for release two
- 100%
Why an MVP built this way lasts
-
The PRD is the scope
Discovery ends with a feature request, a PRD and a design package you approve. Minimum is defined, not argued about later.
-
Built to be release one, not a throwaway
The data model, API and interface are designed together under release controls, so release two extends rather than rewrites.
-
Verified like production
Automated QA and manual review gate the release candidate. An MVP that ships with known failures is not minimal, it is broken.
-
Fast where it should be
Agents do the repeatable work in minutes. People spend their time at the gates.
-
Operated after launch
Deployment and monitoring are part of the engagement. Production is where the next request comes from.
-
A record for the next round
Investors and new hires can read what was built and why.
When an MVP is the right first step
An MVP proves a thing. Be clear what the thing is.
- 01
You need to prove demand, not architecture
One workflow, real users, a measurable result. Everything else waits.
- 02
You have a prototype that cannot take real users
A demo built in a weekend that now has to handle logins, payments and support.
- 03
You are raising on a product, not a deck
A working release with a record of how it was built is a different conversation.
- 04
You have one feature that matters
If you cannot name it, discovery will find it.
- 05
You want release two to be cheaper than release one
It will be, if release one left a record and release controls.
- 06
You want a landing page and a waitlist
Then you do not need us yet. Come back when it is time to build.
Do two or more of these apply? Tell us which ones and we reply with how we would run it.
What an MVP engagement includes
-
Discovery and PRD
A week with you to write the feature request, the PRD and the design package.
-
Design package
Data model, API and interface, designed together and approved by you.
-
Implementation
Short cycles against the approved scope, with the implementation package growing in the record.
-
QA and review
Automated QA writes a report; a person reviews at the second gate.
-
Launch and operation
Deployment, monitoring and releases, operated by us.
-
Release two
The next feature request starts a new run against the same record.
Read more
From idea to first release
- 01
Discovery
A week with the people who own the problem. We write the feature request as the first document of the engagement and agree what done means before anything is designed.
In the record Feature request, scope, success measures
- 02
PRD and design package
Research, requirements and design are produced and land in the record as documents you can read, comment on and reject.
In the record Research report, PRD, design package
- 03
Design approval
A human gate. Work waits until you approve the design package. Nothing is built that the record does not say is being built.
In the record Logged approval, with the approver
- 04
Development
Implementation runs in short cycles against the approved scope. You see progress as it happens, with the implementation package growing in the record.
In the record Implementation package
- 05
Automated QA and manual review
Automated QA runs first and writes a report. Manual review is the second human gate. Failures go to a person instead of slipping through.
In the record QA report, review report
- 06
Release and operation
A release candidate ships only after both gates pass. We deploy it, monitor it and operate it, and the next request starts the next run.
In the record Release candidate, release log
Three ways to build an MVP
| Item | AI app builder | Freelancer | Sydeso |
|---|---|---|---|
| Time to a scoped plan | None, you start prompting | Depends | One week of discovery |
| Who approves the design | Nobody | You, informally | You, at a logged gate |
| Verification before launch | Manual clicking | Varies | Automated QA report and manual review |
| What release two inherits | Generated code nobody has read | Whatever was written down | The full record and release controls |
| Operation after launch | You | Usually not | Included, monthly |
| Price | Subscription, then a rewrite | Hourly | Per project, scoped at discovery |
How an engagement is structured.
-
Week one
Discovery
A week with the people who own the problem. We write the feature request, the PRD and the design package, and agree what done means.
- Ends in a PRD and a design package you own
- You approve it before anything is built
- Comes with a price for the build
-
After approval
Build
Development in short cycles against the approved scope. Automated QA writes a report on every release candidate and a person reviews it before it ships.
- Priced per project against the PRD
- Changes are new feature requests, priced the same way
- Every document is yours as it is produced
-
After launch
Operate
We deploy it, monitor it and run releases, month to month. Production is where the next feature request comes from.
- Monthly, separate from the build
- Take it in-house whenever you are ready
- The record comes with it
Questions
- How long does an MVP take?
- Discovery is a week. The first release candidate follows in short cycles, and you see which stage it is in at any time. We do not promise a day count before discovery, because the scope does not exist yet.
- What does an MVP cost?
- Per project, against the PRD you approve at the end of discovery. Tell us the idea and we reply with a number.
- Will we have to rebuild it later?
- No. Release one is built under the same release controls as everything we ship. Release two is a new feature request against the same record.
- Can we take over after launch?
- Yes. The repository, the accounts and the record are yours. Your team runs the next request.
- How quickly do you reply?
- By email, with how we would run the work, not a call to book a call. Send one paragraph about what should ship first and you get a written answer.
- Where does the work live?
- In your accounts. Code in your repository, infrastructure in your cloud, documents where your team can read them. We bring the process, not a dependency.
- What happens to the work if we stop?
- You keep everything: code, infrastructure, requirements, design packages, QA and review reports. There is no handover because none of it was ever ours.
Name the feature that proves it.
One paragraph about the one thing release one must do. We reply by email with how we would run it, and what it would cost.
Start a project