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
- human gates 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
Agent jobs on runners under release controls, 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 release controls, 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 artifact of the run 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 inside the workflow and land in the record as artifacts you can read, comment on and reject.
In the record research_report, prd, design_package
- 03
Design approval
A human gate. The run waits until you approve the design package. Nothing is built that the record does not say is being built.
In the record design_approval transition, logged with the approver
- 04
Development
Implementation runs as jobs on runners in short cycles. You see every transition 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 escalate instead of slipping through.
In the record qa_report, review_report
- 06
Release and operation
A release candidate leaves the loop 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, released
Three ways to build an MVP
| Item | No-code tool | Freelancer | Sydeso |
|---|---|---|---|
| Time to a scoped plan | None, you start building | 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 | The tool and its limits | Whatever was written down | The full record and release controls |
| Operation after launch | The tool | Usually not | Included, monthly |
| Price | Subscription | Hourly | Per project, scoped at discovery |
Three ways to work with us.
-
For a team that needs the application built and run
Partner engagement
We own the application end to end: discovery, PRD, design, build, QA, release and operation. You hold the approval gates.
- Priced per project, scoped at discovery
- Your gates, our runs
- We operate production after launch
-
For a team that wants to run AI-driven delivery itself
Hosted platform
Your team and your feature requests on the Sydeso platform, with managed runners, storage, backups and upgrades operated by us.
- Per workspace, monthly
- Managed runners
- Support from the people who built it
-
For a team that keeps everything on its own infrastructure
Self-hosted
Clone the repository and run the same platform on Postgres, Redis and S3-compatible storage. Free under BUSL-1.1, AGPL-3.0 from 2030.
- Free
- Your runners, your data
- Community support on GitHub
Questions
- How long does an MVP take?
- Discovery is a week. The first release candidate follows in short cycles, and the run state tells you exactly where it is. 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. Self-host the platform, keep the record and run the next request with your own team.
- 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.
- Do we have to use the Sydeso platform?
- Every partner engagement runs on it, because the record it keeps is how we work. You can host it yourself from day one or move to self-hosting later; the platform is public under BUSL-1.1.
- What happens to the work if we stop?
- Everything is in the record as artifacts: requirements, design packages, implementation packages, QA and review reports. You keep all of it, and the platform that reads it is yours to run.
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