The MVP Roadmap
So I do not. The MVP Roadmap is a paid engagement that runs over weeks, not an hour on a call. We work the requirements out of your head across a series of working calls, then I go away and do the research, settle the architecture, and write the whole thing up as a phased plan.
You finish holding a blueprint a competent team could build from. It is yours whether or not that team is mine.
Why estimates fail
01
Someone quoted from a description rather than a scope. Nobody was lying. The information required to be right did not exist yet, and it stayed missing until the build was already underway and the number had become a promise.
02
Everything was important, so nothing was sequenced. The first release kept absorbing features until it no longer had a launch date. This is the most common way three months quietly becomes eighteen.
03
The data model, the auth approach, the platform you integrated with in week one. Nobody chose them. They were inherited from whatever was quickest that week, and unpicking them later costs more than the original build did.
None of these are engineering failures. Every one of them is a decision that was never made on purpose. The roadmap exists to make them on purpose, before they are expensive.
How the work runs
Not a questionnaire and not a discovery call with a proposal at the end. Five passes across several weeks, some of it on calls with you and some of it alone with the research, in this order, because each pass depends on the answers from the one before it.
Before scope, the question underneath it. What has to be true for this to work, and what is the cheapest way to find out you are wrong. Most products do not fail on execution. They fail because the assumption underneath them was never tested, and the build was the most expensive possible way to test it.
Every system the build has to reach. What you already run, what it has to write back to, who else on your team needs access, what data is not allowed to leave the country. Where something is already in production this is also where I read the existing code and talk to the people who maintain it. This is where cost actually lives. Adding a feature rarely moves a number much. Adding an integration always does.
What ships in phase one, what waits, and the reason attached to each. Founders find this pass the hardest and it saves the most money. Nothing gets cut for being difficult. Things get cut because they have not yet earned a place in the release that has to prove the idea.
The decisions that are expensive to reverse. Data model, auth, hosting, and where the AI actually sits in the flow rather than where it sounds good in a pitch. This is the part that happens away from you, because it takes reading, comparison and a week that nobody wants to spend on a call. Each decision is written down with the trade-off you accepted and the option you turned down, because in six months somebody will ask why.
Build order with a real number against it. Phase one, phase two, what each phase unblocks, and where the honest risk sits. Not a chart pretending to know the future. A sequence specific enough that you could hand it to a team that has never met me and hold them to it.
The deliverable
These are not five bullet points in a deck. They are the sections of one document, and it routinely runs past fifty pages, because that is what it takes to describe a build precisely enough to price it.
What is in phase one, what is deferred to phase two, and the reason recorded against every line so the decision survives the meeting it was made in.
Stack, data model, integrations and hosting, each with the trade-off you accepted and the option you turned down written beside it.
Phase one, phase two and what follows, ordered to get you something usable fastest, with what each phase unblocks stated rather than implied.
What could move the number, in which direction, and by roughly how much. The things nobody mentions until they arrive as a change request.
Priced against the sequence, not against a description. Specific enough to budget from and to hold a builder to, including one who is not me.
Written for the next person rather than for me. Hand it to another firm or to a team you hire and it still works, which is the point. A blueprint only its author can execute is not a blueprint, it is a lock-in with better manners.
The investment
Starting at
$0
CAD, for the engagement
Where it lands above that is set by one thing: how much there is to scope, which is the same thing that decides how many weeks it takes. Not by how large your budget looks, and not by how badly I want the build.
A focused first version. A clear idea, two or three integrations, nothing already built that has to be inherited. Two to three weeks of work, and it lands close to the starting figure.
A rebuild of something already carrying real users. Data to migrate, a team to interview, existing code to read, and years of accumulated decisions to unpick before a single phase can be sequenced. That is six weeks before the plan can even be written, and it is priced on what covering it properly takes.
You get told which of those you are on the first call, with the reasoning, before any money changes hands.
Credited against the build
If we go ahead, the full roadmap fee comes off the build. If we do not, you keep the blueprint and I keep the months I would otherwise have spent building against a scope nobody checked. Both of us finish ahead of where a free proposal would have left us.
Before you book
Start the roadmap
Probably not yet
If you are in this column, say so on the call and I will tell you what I would do instead. That conversation costs nothing and it has saved people a great deal more than it cost me.
The next step
Thirty minutes, no charge, no deck. You describe what you are trying to build and I tell you honestly whether an MVP Roadmap is the right next move, roughly how long yours would take, what it would cost, and what I would suggest instead if it is not.
If we go ahead, you will know the fee and exactly what the engagement covers before you pay anything.
