01 / Who this is for
Post-seed startups
MVP development for startups: from the round to production
You have closed a round, you have a window of months to prove something, and you don't yet have the team that will build the product. I cover that window: I design and build the MVP, ship it to production, and hand it over in a state the CTO you'll hire can pick up — with no technical choices that lock you into me.
What you hold at delivery
- Source code
- Your repository
- Architecture document
- Your infrastructure
- Release pipeline
- Technical handover
- Remaining backlog
Not a courtesy list: it is the condition for a CTO hired at month six to pick up the product and keep going instead of rewriting it. If that isn't true, the MVP isn't an asset — it's a debt.
- Who it's for
- Post-seed or post-pre-seed startups with capital raised, a product thesis and no in-house technical team hired yet.
- What I deliver
- A production product with real users, plus the code, architecture documentation and infrastructure in the startup's name.
- Indicative time
- An estimate, not a contractual commitment: 8–16 weeks from scope definition to the first production release, depending on how wide the scope is.
- What I don't do
- I don't work for equity, I don't take a stake in the company and I don't act as a part-time CTO. I am a technical supplier with a defined mandate.
02 / Diagnosis
Why the first product often sinks
The risk with an MVP isn't that it looks bad. It's that it gets thrown away.
A startup's first product is judged by investors on what it demonstrates and by the next technical team on what can be inherited. Almost always, one of the two judgements gets sacrificed for the other.
The scope grows until it eats the window
Every conversation with a prospect adds a feature that «is absolutely needed». Six weeks turn into five months, the round burns down and the thing you set out to prove still hasn't been proven.
A prototype nobody can inherit
A no-code tool or a prototype written in a hurry is fine for validating, but it becomes a problem the day you hire your first developer: there is nothing to build on, and the first thing they ask for is to redo everything. That's months of runway spent twice.
Technical choices that lock you into the supplier
Code not handed over, infrastructure registered to the agency, proprietary components, no documentation. The product works as long as you keep paying that supplier. It's the most effective way to make a company unfundable in two months of technical due diligence.
Over-engineering, which is the opposite mistake
Microservices, orchestration and scale for a million users when there are zero users. It costs three times as much, takes three times as long, and still gets rewritten, because the assumptions the scale was designed around turn out wrong as soon as real users arrive.
Nobody wrote down why it was built that way
The code says what it does, not why that route was chosen and which alternatives were rejected. Without that document whoever arrives next redoes the same evaluations from scratch, or worse, dismantles choices that had a precise reason.
The product never really went to production
A demo on a staging environment proves nothing under two questions from a technical investor. A product with real users, logs, recorded errors and a repeatable release is a verifiable fact. The distance between the two is where the weeks die, and it has to be budgeted from the start.
The three routes to a first product, without going easy on any of them
Each one makes sense in a different context. Listing the limits of mine too is the only way to make this comparison useful.
| Aspect | Prototype or no-code | An MVP like this |
|---|---|---|
| Time to first version | Days or a few weeks. That's its real advantage. | 8–16 weeks as an estimate, depending on scope. |
| Upfront cost | Low, sometimes close to nothing. | Significant: it's a runway investment and should be assessed as one. |
| What it's for | Validating that the problem exists and that somebody will pay to solve it. | Showing a product in operation and building the base your team will grow on. |
| Inheritability by an in-house team | Poor: almost always starts over from zero. | It's the design requirement, not a hoped-for side effect. |
| Standing up to technical due diligence | Weak: there is no code to look at. | Code, architecture documentation and a reviewable release history. |
| When it's the right choice | When you don't yet know whether the problem exists. In that case, do it, and come back later. | When validation is already done and you have to build the real product. |
03 / Approach
Scope defended, delivery you can inherit
An MVP built to be inherited
My stated goal is to make myself unnecessary: at delivery, your team has to be able to carry on without me.
The work starts by defining what the MVP has to prove — one sentence, not a twenty-page document — and from there the minimum scope that proves it is derived. The architecture is deliberately boring: widespread technologies, a single application service, no orchestration, no exotic components. Not because it's simpler for me, but because a boring stack is one you can find people to hire for, and one a new CTO can read in a week instead of a month. Where a third-party component is needed — authentication, transactional email, a payment gateway — a standard service gets integrated and isolated behind an interface, so replacing it later costs little.
A written scope, and an explicit «not now»
It's the mechanism that protects the runway better than any good intention, and it holds on one condition only: that somebody on your side can say no.
A boring stack, deliberately
Widespread, documented technologies, with a labour market behind them. No choice that requires a rare specialist to maintain, and none that exists just because it was interesting to try.
Infrastructure in your name from day one
Repository, hosting, database, third-party services: all on your accounts, with me as a collaborator. There is no moment at delivery when something has to be migrated, because nothing was ever registered to me.
A repeatable release, not a manual deploy
A pipeline that ships code to production with one command, separate environments and the ability to roll back. It's the difference between a product and a demo running on someone's laptop.
An architecture document with the rejected alternatives
Not just what was built: why, and which routes were assessed and left aside. It's the document that lets whoever comes next avoid redoing the same analysis and avoid dismantling choices that had a reason.
Technical handover at delivery
When the first developer or the CTO arrives, I pass on the project: architecture, decisions, remaining backlog, known weak points. Weak points too, because there are always some, and hiding them doesn't make them disappear.
What typically falls inside an MVP's scope
- Registration, authentication and role management, built on a standard service rather than rewritten
- The core product flow, the one that proves the thesis, built properly
- A minimal admin panel, because without one you end up supporting users by hand on the database
- Integration with the third-party systems the flow can't do without, isolated behind a replaceable interface
- Logs and error tracking: without them, the first real users report problems you can't reproduce
- The essential product metrics, the ones you need to decide and investors need to understand
- A written backlog of everything deliberately deferred, delivered together with the product
Where a request ends up
Incoming requests
From a client · From an investor · From you
The sentence to prove
Written before starting
Scope
Built now
«Not now» backlog
Decision on record
The «not now» backlog isn't discarded material: it's the list of consciously deferred decisions, and it's handed to you together with the product.
04 / Terms
Terms and scope
The terms, before the promises
An MVP is a runway investment. This is the information you need to decide whether it makes sense to build it with me.
How we work
- Scope
- Defined and written before starting, with an explicit «not now» backlog. Additions are assessed at the next milestone, not mid-flight.
- Milestones
- Roughly every two weeks, something testable in a reachable environment. Not progress percentages.
- Who does what
- Architecture, technical decisions and code review are mine. For development I draw on trusted collaborators when the volume calls for it.
- Point of contact
- One person only, the founder or whoever holds the mandate on the product. Scope decisions require someone who can say no.
Technical setup
- Principle
- A boring, widespread stack, with a labour market behind it. No technology chosen because it was interesting to try.
- Architecture
- One application service, one database, no orchestration. It splits when there's a measured reason, not before.
- Third parties
- Authentication, transactional email, any payment gateway: standard services, isolated behind a replaceable interface.
- Environments
- Development, staging and production kept separate, with a repeatable release pipeline and the ability to roll back.
Ownership and exit
- Code
- On your repository from the first commit. There is no moment when it needs to be transferred, because it was never mine.
- Infrastructure
- Accounts and services registered to the startup, with me as a collaborator you can remove whenever you want.
- Constraints
- No encrypted components, no usage licences, no service that shuts off if you stop working with me.
- Handover to the team
- Documented technical onboarding for the first developer or the CTO, known weak points included.
Timing and pricing model
- Indicative time
- An estimate, not a contractual commitment: 8–16 weeks from scope definition to production, depending on how wide the scope is.
- Quote
- Fixed on the defined scope, with milestones. Not an open hourly rate.
- Equity
- I don't work for equity and I don't take a stake in the company. I'm a supplier, and that keeps incentives clean on both sides.
- After delivery
- A support period agreed before starting, with a written scope. Extendable, but not a disguised retainer.
Included in an MVP project
- Definition of the scope and the «not now» backlog, in writing
- Architecture document with the rejected alternatives and their reasons
- Development in testable milestones, with code review done by me
- Separate environments and a repeatable release pipeline
- Logs, error tracking and essential product metrics
- Production launch and technical handover for the team taking over
Not included, and I say so upfront
- CTO role, even part time: that needs an in-house person, not a supplier
- Equity work or a stake in the company
- Brand and visual identity design: I build the interface, not the brand
- User acquisition, marketing and growth
- Hosting fees and third-party service costs, which stay in your name
- Any promise about traction, future rounds or market outcomes
05 / Route
Four phases, scope defended
How you get from the thesis to a product in operation
The durations are estimates to help you plan, not contractual commitments. The variable that moves them most is how fast scope decisions come back from your side.
- 01
Scope
We write, in one sentence, what the MVP has to prove, and from there derive the minimum that proves it. Everything else goes into the «not now» backlog, tracked and delivered with the product.
- Cosa ricevi
- A scope document with the thesis to prove and the deferred backlog.
- Durata
- 1 week (estimate)
- 02
Architecture
Technical choices, third-party components, data model, environments. I document the rejected alternatives and the points where the MVP is deliberately fragile, so nobody discovers them later.
- Cosa ricevi
- Architecture document, repository and infrastructure on your accounts.
- Durata
- 1–2 weeks (estimate)
- 03
Development in milestones
We start with the core flow, the one that proves the thesis. Roughly every two weeks there is something you can put in front of a user or show to an investor.
- Cosa ricevi
- Testable milestones in a reachable environment, one at a time.
- Durata
- 6–12 weeks (estimate)
- 04
Production and handover
Launch to production with logs and error tracking active, then the handover: architecture, decisions, remaining backlog and known weak points to the first developer or the CTO.
- Cosa ricevi
- Product in production, documentation, technical handover completed.
- Durata
- 1–2 weeks (estimate)
No phase commits you to the next one: you can stop after the scope or after the architecture, and either way the documents produced stay yours and can be used with any other supplier.
06 / Frequently asked
The same ones I get on the phone
Questions about MVP development
The questions founders ask me in the first half hour. If yours isn't here, write it to me.
01How long does an MVP take?
As an indicative estimate, not a commitment: between 8 and 16 weeks from scope definition to the first production version. The variable that moves the dates most isn't development: it's how fast scope decisions come back from your side. A founder who answers open questions the same day shortens the project more than any technical choice.
02Do you work for equity?
No, and it isn't a question of trust in your project. Working for equity would make me a partner with an ambiguous mandate, and the last thing you need in the first months is a supplier acting like a partner without being one. I prefer a clean relationship: defined scope, fixed quote, delivery. If the product does well I'm glad, but the decisions are yours.
03Can you act as CTO in the meantime?
No. I can cover the architecture and technical decisions of this project, which is a different thing from being a company's technical lead: that role requires being inside product and people decisions every day, and an external supplier can't do that well. What I do is build the product so the CTO you hire can pick it up without rewriting it, and give them a proper handover when they arrive.
04What happens when I hire my first developer?
It's the scenario the project is built for. The code is already on your repository, the infrastructure is on your accounts, the architecture is documented with the rejected alternatives, and the remaining backlog is written down. I do the technical handover to the person who arrives, known weak points included, and from there they can carry on. If needed I stay available for an agreed period, but the stated goal is that it isn't needed.
05Is the code mine?
Yes, from the first commit: the repository is yours and I'm a collaborator. The same goes for everything else — hosting, database, third-party services are registered to the startup. There is no moment at delivery when something has to be migrated, because nothing was ever registered to me. It's also why technical due diligence doesn't turn up surprises.
06How do you stop the scope from exploding?
With a mechanism, not good will. Before starting, we write in one sentence what the MVP has to prove. Every subsequent request gets checked against that sentence: if it serves it, it enters the scope; otherwise it goes into the «not now» backlog with the decision on record. The backlog is delivered to you together with the product, so nothing is lost: it's deferred consciously. It does need someone on your side who can say no, though.
07What technologies do you use?
Deliberately boring and widespread ones, chosen on two criteria: that there's a labour market for hiring people who know them, and that a new CTO can read them in a week. The starting architecture is one application service and one database, with no orchestration: it splits when there's a measured reason, not to anticipate a scale you don't have yet. The specific choices depend on the product and are discussed with you, not imposed.
08What happens if the product doesn't work in the market?
It can happen, and it isn't within my control or any supplier's: I'm accountable for the product, not for traction. What I can do is limit the damage: a minimal scope burns less runway, and a product you can inherit with a documented architecture is reusable if you change direction. Be wary of anyone who ties their technical work to promises of market outcomes.
09Do I need to have already raised to talk to you?
It helps, because an MVP built this way is a significant investment and needs capital to sustain it. If you haven't raised yet, the right move is often something else: validating with a prototype or no-code tools that the problem exists and that somebody will pay to solve it. In that case I'll tell you so on the call instead of selling you a project that burns through the little you have.
07 / Related
Where to go next
Pages connected to this one
If your case isn't exactly this one, it's probably one of these.
08 / Contact
Half an hour, no automatic quote
Tell me what it has to prove
Let's take half an hour: you tell me what the product has to prove and in how much time, I tell you whether the scope fits the window you have and whether it makes sense to build it now. If the right move is to validate first with something lighter, I'll say so and I won't sell you an MVP.
Or write to me: I answer myself, usually within one working day. An NDA before going into detail isn't a problem.
All the contact detailsHow the call works
- Length
- 30 minutes, video call or by phone.
- Who is there
- Me. No salesperson, no handover between people.
- What I need
- To know what the product has to prove, for whom, and in how much time. No written spec needed.
- What you get
- An honest opinion on a realistic scope and the order of magnitude. The quote comes after the scope is defined.