A roadmap plans the work. A price closes the deal.
Money is what gets approved. The proposal builder takes the costed roadmap and turns it into the document the business decision is actually made from: three plans cut from the same scope, what choosing the cheaper one gives up, what the thing costs to keep alive once it is built, and every assumption behind the figure named rather than buried in it.
- Plans
- 3, cut from one roadmap
- Recommended
- Medium
- Maintenance
- 18% of build, a year
- Payback
- Only from your figures
Hours plan the work. Money decides it.
The delivery roadmap answers how long and in what order. It is the document a delivery team needs. Approval happens in a different room, where the question is what this costs, what it saves or earns, and what happens if we do the cheaper version.
That translation is usually done by hand, once, by whoever is free, in a spreadsheet nobody opens again. It is the least reproducible document in the whole delivery and the one carrying the most consequence. So it is the one we generate.
One thing this page does not show you is a price. The rate card that turns an hour into a currency amount is our own contract pricing, and publishing it would quote every reader the same number regardless of what they are building. What is below is everything else: the scope, the hours, the split, the band, and the arithmetic. The last multiplication is a conversation.
Three plans, cut from one roadmap
The tiers are three cuts of one plan by scope, which is what makes them comparable: choosing the cheaper one means deferring identifiable work, and you can be shown exactly which.
Standard
Everything classed as essential. The smallest plan that still delivers the outcome.
- Tasks
- 5
- Effort
- 10.5+ h
- Months
- 2
Includes- must-have
- ungraded
Defers- 7.0 h of should-have work (2 tasks)
- 0.5 h of could-have work (1 task)
48% of these hours price at the senior rate
Medium
recommendedEssential work plus the should-haves: the plan most teams actually want.
- Tasks
- 7
- Effort
- 17.5+ h
- Months
- 3
Includes- must-have
- should-have
- ungraded
Defers- 0.5 h of could-have work (1 task)
40% of these hours price at the senior rate
Premium
Everything in scope, including the could-haves.
- Tasks
- 8
- Effort
- 18.0+ h
- Months
- 3
Includes- must-have
- should-have
- could-have
- ungraded
DefersNothing in scope. This is the whole roadmap.
39% of these hours price at the senior rate
The steps between them are uneven: Medium adds 7.0 h over Standard, Premium adds 0.5 h over Medium. That is this roadmap rather than the model. Almost all the optional work here is graded should-have, so it lands in one step, and Premium adds a single task on top of Medium. A package with more could-haves spreads further. The tiers are a rule for where to cut rather than three price points spaced to look like a pricing page, so the line worth comparing is Defers: it names the work you would be choosing to leave out.
Standard finishes sooner, and the earlier date is real
Every tier is rescheduled from scratch rather than inheriting the full roadmap’s month assignments. A smaller scope genuinely finishes earlier, and reusing the original months would quote all three plans the same delivery date while charging three different prices. The month figures are capacity-bound at 8 h a month, and dependencies can only push a tier later, never earlier, so they are a floor too.
Ungraded tasks are in every plan, including the cheapest
One task in this package was never given a must, should or could. Treating an ungraded task as optional would produce a Standard plan quietly missing requirements nobody decided to drop. An over-scoped Standard is visible and arguable; an under-scoped one is neither. Work already classified wont appears in no tier at all. That decision has been taken, and selling it back as a premium extra would misrepresent it.
One place an hour becomes a currency amount
Everything in the financial model is deterministic arithmetic over figures the roadmap already computed. No model is consulted, because a cost somebody might sign against has to be reproducible from the same inputs and explainable line by line.
Costing walks tasks, not stories or epics. A task carries exactly one area of the system, so it resolves to exactly one rate. Pricing a story spanning three areas would need a rule for which rate wins, and any such rule would be an invention. At the task tier there is nothing to invent.
Rate follows the type of work rather than a staffing ratio someone chose. System design, security and infrastructure price at the senior rate; product implementation and test work price at the junior rate. A task with no area at all follows the junior default, because an unattributable task is usually ordinary work and defaulting it to senior would inflate a quote on the strength of missing metadata.
The consequence is the useful part: the senior share of a project is an output, not an input. A system heavy on security and infrastructure costs more than a set of CRUD screens the same size, which is the behaviour you want and the thing a single blended rate cannot express. On this package it ranges from 39% to 48% depending on which plan you take, because the cheaper plans are proportionally more senior work.
- Build cost
- Hours at the rate for the work type, summed per task. Marked a floor whenever any task in the tier was never sized.
- Annual maintenance
- 18% of build cost a year: dependency upgrades, defect fixes, and the small changes the platforms underneath force on you. It sits inside the 15-20% band the industry has used for decades, and it is declared as an assumption so you can substitute your own.
- Annual run cost
- Maintenance plus hosting. Hosting is an input, never a guess.
- Three-year total
- Build cost plus three years of run cost. The figure worth comparing between plans, because a cheaper build with a heavier tail is not cheaper.
- Payback
- Build cost against the annual benefit you supplied. Where the benefit does not clear the run cost there is no payback period, and the proposal says so rather than reaching for a longer horizon.
Lopsided on purpose
An unanswered question resolves into 'and it also has to do X' far more readily than into 'actually you can skip Y'. So unknowns widen the top of the band and leave the bottom alone. A symmetric range would imply a coin flip that does not exist.
- Base downside-10%
- Honest estimates still sometimes land under. This is the only figure that moves the number down, and nothing widens it.
- Base upside+15%
- Ordinary estimation error, before anything specific to your project is counted.
- Each unknownupside only
- Several drivers, weighted by how much trouble each kind of unknown causes. A question that stops work moves the band furthest. A question nobody has graded is not assumed to be small. An assumption written down and accepted is cheap, and one nobody wrote down is not counted at all, which is the argument for writing them down. A package with no recorded questions widens rather than narrows: zero questions written is not evidence of zero unknowns.
- Cap+100%
- Past a doubling the figure has stopped being a forecast. The model says so rather than quoting an ever-wider range.
These are judgement rather than measurement, which is exactly why they are reported as named drivers instead of folded into one number you would have to take on trust. Your own proposal shows the weight behind every driver that moved your figure, so the arithmetic is arguable where it matters. What is not on this page is the weighting itself, which is ours.
Four things this document will not do
The same discipline as the roadmap: a proposal that admits a gap is worth more than one that looks complete and is not.
- 01
Benefit figures come only from you
The model prices the build, the run cost and the three-year total on its own. What the thing earns you is yours to supply. A payback period is calculated only from figures you gave us, and where you give none, the proposal carries no return at all. A return built on a benefit we invented would be the most dangerous number in the document.
- 02
Hosting is a number you supply
Cloud spend depends on traffic and retention that requirements leave unsaid, and it is the figure a finance team is most likely to check. Annual maintenance is derived; hosting is an input. Leave it out and the run cost says so.
- 03
Unsized work stays unpriced
Work with no estimate is carried as unknown and any total containing it is labelled a floor rather than an estimate. On this sample that is one task of eight, which is why every hour figure below is marked with a plus.
- 04
Pricing and presentation are separate layers
The document that presents the money never calculates it. Scope arrives from the planner, cost from the rate card, and this layer only decides how to say it. That separation is what stops a change to how a proposal reads from moving what it says.
One more, worth stating plainly: where the document compares your project to named products, that section carries an explicit label saying it was written from the model’s general knowledge rather than from your requirements, and to verify it before quoting. The agent writing it has no web access and will state confident, occasionally wrong things about products in front of people who may recognise them.
Everything above came out of the same package
The plans on this page are cuts of the roadmap on the roadmap page, which is itself real generator output from a fixture in CI. The demo runs the front of that pipeline on your own meeting notes, streaming each stage as it lands.
One task of eight in this package was never sized, so every hour figure above is a floor.
Tell us what you’re building
Bring us a problem, a half-formed idea, or a system that has outlived its stack. We will tell you honestly whether we are the right team for it.