Guide
How long does an MVP take, and what team does it need?
On our own projects, two to three months with one or two builders when the product has one main flow, and six months with three developers plus a CTO or delivery manager when it has several sides, payments and compliance. What sets the length is not the number of screens but the number of parties, integrations and open questions the product carries.
These are five products we built between 2021 and 2023, with the time and the team as each case study records them. They are not a rate card. They are the evidence we reach for when a founder asks how long theirs will take, and the honest answer starts with what kind of product it is.
Five builds, side by side
| Product | What it is | Time | Team | What made it longer or shorter |
|---|---|---|---|---|
| SWANS | Invite-only booking for beauty talent | 2 months, brief to launch-ready MVP | 2 full-stack engineers | Shorter: one booking flow, Stripe for payment, Airtable as the database so nobody built a data layer from scratch |
| Flur | Patreon-style creator platform on NFTs | 8 weeks to live, in iterations of 3 and 5 weeks | 2 developers, 1 delivery manager | Shorter: a rule of iterations no longer than a few weeks. The second rebuilt how claims worked, after launch |
| AnyoneGroup | Two-sided marketplace for group discounts | 6 months, clickable prototype to launch | A CTO and 3 developers | Longer: buyer, seller and admin sides, payment charged only when a group fills, seller KYC, Shopify import, tax, shipping and invoicing |
| CachePay | Crypto-to-fiat payment gateway | 6 months, Oct 2022 to Apr 2023 | 3 developers, 1 delivery manager | Longer: consumer, merchant and admin sides, merchant KYC, liquidity and custody through B2C2 and Fireblocks, a WooCommerce plugin |
| OccamStrata | Strata management on Airtable | 3 months | 1 automation engineer | An internal system on a platform. The time went on the data model, a migration out of an ageing CRM and a two-way sync |
What the table says
Team size follows the number of sides more than the length of the feature list. Two people shipped SWANS in two months because the product had one main path: a client finds an artist, checks availability, books and pays. AnyoneGroup and CachePay each had three sides, and every side is its own dashboard, its own permissions and its own idea of what an order is. That is where the six months and the third and fourth person went.
Money and other people’s systems slow things down. SWANS took payment with Stripe from booking to checkout and stayed at two months. AnyoneGroup’s payments were authorised when a buyer joined and charged only if the group reached its minimum by the deadline, with seller onboarding and KYC behind them. CachePay’s merchants were paid in fiat for crypto sales through two third-party providers, and we joined the technical calls with those providers through launch. Their schedules were not ours.
A prototype does not make a build short on its own. AnyoneGroup started from a clickable prototype and written descriptions of what everything should do, and it still took six months, because a prototype settles what the screens are, not how payment on a full group, tax across jurisdictions or seller approval behave. What a prototype tested with users does is move learning before the build. Flur shows what learning after launch costs: the first iteration let anyone claim a collectible, fan or not, and the second iteration, five weeks, replaced the claim mechanism with donations. A test with users might have caught that; the other reason, Twitter’s API pricing, no prototype would have.
How the sprint and the two builds map onto them
Every project we start now begins with a two-week product sprint: concept, a design sprint, a clickable prototype tested with users and the architecture, ending in an agreed scope and a fixed quote. Then one of two builds. A fast build of under two months, when the sprint settles the what and the how. An explore build of two to four months, when the product still needs discovering: a new market, a multi-sided platform, payments or regulation.
Read in hindsight through that process:
- SWANS is a fast build. A clear brief, one flow, two months.
- Flur is two short builds back to back, and the second one did what an explore build does on purpose: answered an open question with what real users did.
- OccamStrata sits between the two. The working sessions with stakeholders and the schema drawn before any tool was touched did a sprint’s job; the migration and the sync made it longer than a fast build.
- AnyoneGroup and CachePay are explore builds: multi-sided, with payments and compliance. At six months, both ran past the four an explore build now allows for. Part of a sprint’s job is to find that before the build starts, by cutting the scope to what launch needs, as CachePay’s founders did with us through rigid prioritisation, or by saying plainly that the build will take longer.
What moves the time
The questions that moved ours:
- How many sides? Each extra party (buyer, seller, merchant, admin) brings its own dashboard, permissions and onboarding.
- Does money do anything unusual? Taking a card is quick. Charging on a condition, splitting payouts or settling in another currency is not.
- Is there compliance? KYC, tax and invoicing each bring a provider, a review and edge cases.
- Whose systems do you depend on? Shopify at AnyoneGroup, which brought in 5,000 products; WooCommerce at CachePay; the old CRM at OccamStrata. Each has its own limits and timetable.
- Is there existing data? Moving records out of a system that is still running is work a new product does not have.
- Has a user seen it? A prototype tested before the build answers questions that would otherwise cost an iteration after launch.
What shortened ours was the reverse: one main flow, a stack chosen for the deadline (Airtable at SWANS and OccamStrata), and a scope cut to what launch needs.
What team it needs
Across these five, one to four people built each product: one automation engineer for an internal system on a platform, two full-stack engineers for a single-flow product, three developers and someone who owns the decisions, a CTO or a delivery manager, when there are three sides and money moving. Our teams today are usually two to four, each working with agents, with design in the same team as engineering, and you work directly with the founder who builds it.
What it costs
Builds start at $25k. Two engagements of about a year each ran $50k to $200k, by their clients’ Clutch reviews. The build is quoted at the end of the two-week sprint, from the agreed scope rather than from a guess, and if the sprint shows the fastest path is the wrong one you hear that before the build starts. How each offer is priced is on the pricing page.
Related offer: Product design and development. More guides →