Ten weeks to an investor milestone, a rough prototype, and nobody in house to build it.
- Client
- An early-stage startup with an investor milestone
- Scale
- A rough prototype and no developers in house
- Engagement
- An MVP build to a fixed ten-week date
The outcome in five lines
| Measure | Before | After | Evidence |
|---|---|---|---|
| Time to a production-ready version3 | a rough prototype, 10 weeks to the milestone | 9.5 weeks | Measured |
| MVP scope and delivery plan2 | a rough prototype | defined in 5 days | Measured |
| Developers building the product1 | 0 in house | our senior team, back end and front end in parallel | Measured |
| Where the build stood2 | no team in house to ask | a demo and a scope review every week | Described |
| The investor milestone3 | 10 weeks away | met | Described |
Three lines are measured. Two describe how the work ran and carry no number. The small number beside each line says how it was measured.
The problem, in the client's terms
The startup had a rough prototype, ten weeks left to hit an investor milestone, and zero internal developers. There was nobody on their side who could build the product.
A prototype shows the idea. It is not a product anyone can run in production, and the gap between the two is where most of the work sits. Ten weeks is not long enough to find that gap slowly.
With no developers of their own, the founder could not start building while deciding what to build. Every week spent choosing a team or arguing scope came out of the ten, and a slip would be carried personally, in front of the investors.
- ConstraintA fixed date, set by an investor milestone ten weeks out.
- ConstraintNo developers in house to build, review or take over the code.
- ConstraintThe scope had to fit the date, not the other way round.
How the delivery was built, before and after
Switch between the two. This shows the system that did the work: a scoping week, two build tracks running side by side, and a weekly loop back to the founder.
- What hurt in this state
- Built in this engagement
Three decisions, and what we turned down
The plan is the easy part to copy. The choices behind it are what hit the date, so each one names what it replaced and what it cost.
Build both halves at once, against an agreed API contract
Turned down
Back end first, then the front end
It pushes every screen into the last weeks, so the first thing the founder can click arrives when there is no time left to change it.
Chosen
A back end track and a front end track in parallel from week 1
Both tracks build against an interface agreed during scoping, so each weekly demo shows screens working against the real back end rather than mock data.
What it cost: The contract has to be settled inside the scoping days, and any change to it after that touches both tracks at once, so a late change costs more than it would in a build done one half at a time.
A demo and a scope review every week, not a fixed specification
Turned down
A full specification signed at the start
It assumes the prototype already answered every question. The first time the founder sees the real product would be at the end, too late to trade a feature for the date.
Chosen
A working demo every week, followed by a scope review
The founder sees what exists, decides what comes next, and always knows where the build stands against the date.
What it cost: The founder spends time every week reviewing and deciding, and the scope stays open until release, so nothing is final early.
Cut scope to protect the date
Turned down
Move the date to fit the scope
The date was set by an investor milestone. Moving it spends the one thing the founder could not buy back.
Chosen
Hold the date and let the weekly review decide what waits
Each request is weighed against the time left, so a cut is the founder's call made in a review, not a surprise in the last week.
What it cost: Whatever did not fit the ten weeks waited for a later release, and the founder carried that conversation with anyone who expected it in the first one.
How it was delivered
Scoping in days 1 to 5, the build in weeks 1 to 9, and the release at 9.5 weeks, inside week 10.
Scoping
The MVP scope and a delivery plan, defined together with the client in the first five days.
Weeks 1 to 1 of 10
Build
A senior team built the back end and front end in parallel, with a demo and a scope review every week.
Weeks 1 to 9 of 10
Release
The first production-ready version launched at 9.5 weeks, meeting the startup's deadline.
Weeks 10 to 10 of 10
Who owns what now
At the milestone the client held a production-ready product they could put in front of investors and users.
Results
The date the founder had, and the date the product was ready.
- The founder saw a working build every week instead of a status report, and made the scope calls in the review.
- The investors saw a production-ready product at the milestone, not a prototype and a promise.
10 weeks
The milestone, from the start
9.5 weeks
Production-ready version
The product was ready before the milestone, not on the morning of it.
| Option | Weeks from the start of the engagement. |
|---|---|
| The milestone, from the start | 10 weeks |
| Production-ready version | 9.5 weeks |
Source: Source note 3
What a slipped milestone would cost you
We do not publish what an engagement costs. So this works from your side: what your company spends while a milestone slips, before counting what the slip does to the round itself.
Burn spent while the milestone slips
Enter your figures
- Slip plus hiring, if you build in house
- Enter a hiring cost
This is spend with nothing new to show for it. The case above shipped half a week inside the date.
What went wrong, and what we would change
Half a week is a thin margin
The release landed at 9.5 weeks against a 10-week date. That is inside the milestone, and it is also half a week of slack on a ten-week plan. Next time, a release candidate goes in front of the founder by week 8, so the last stretch is for fixes, not features.
A prototype is easy to over-trust
A rough prototype often looks further along than it is. What we would change: decide in the scoping days, in writing, which parts of it are kept and which are only a reference, so nobody discovers that in week 6.
Will a fixed-date build work for you?
It fits when
- A date is set by something outside your control, such as investors or a launch event.
- You can make scope decisions every week, and you are willing to cut.
- You have a prototype or a clear idea, but no team to build it.
Look elsewhere when
- Every feature in your plan is required for the first release. Then the date has to move.
- Nobody on your side has time for a weekly review. The loop needs a decision maker in it.
- The product needs certification or a regulator's approval before launch. That sets the date, not the build.
Check it yourself this week
If your list is longer than the weeks you have, and nobody has said what waits, this case study is about you. Put your burn into the calculator above.
- Write down the date, and who set it.
- List every feature you believe must ship by that date.
- Mark the ones a user or an investor would miss in the first month.
- Count the weeks left, and who on your side will review the build each week.
The stack, by layer
- DeliveryA back end track and a front end track in parallel, weekly demos and scope reviews
- TeamA senior team on our side; the client had no developers in house
How each figure was measured
- Where the client started: a rough prototype, 10 weeks to an investor milestone, and no developers in house.
- Scope and delivery plan agreed in the first five days, then weekly demos and scope reviews through the build.
- Weeks from the start of the engagement to the first production-ready release.
- Reported by the client at the milestone.
Tell us your date and what exists today, and we will tell you what fits before it.
Send the milestone date, what you have built so far and who is on your side. A software engineer reads it and replies with an honest answer, including when the date needs a smaller first release.