Headless commerce TCO: pricing everything you will run, beyond the licence
The price of headless commerce is much more than a platform quote. What it costs depends on the build, migration, people, cloud, vendors, ongoing change, reliability and eventually leaving. This model turns those items into a 24-month comparison that finance and engineering can review together and argue about with the same numbers.
Technical review: monkydot engineering
1. Agree what you are comparing
Define the options before collecting any numbers. At a minimum, the model should compare a realistic headless target with the current platform plus the work needed to keep it viable. A 'do nothing' option that assumes zero effort makes the current setup look cheaper than it is.
Use the same 24-month period, demand assumptions, markets, service level and functional scope for every option, and write down what is excluded. Costs left outside the model still exist; they just have nobody responsible for them.
- Name the baseline, the target and any phased or SaaS alternative.
- Use one currency, one tax treatment and one accounting convention.
- Separate cash timing from accounting treatment where finance needs that.
- Give every significant input an owner and a source.
2. Use one TCO24 formula that anyone can audit
For option o, calculate TCO24(o) = I(o) + M(o) + P(o) + C(o) + V(o) + O(o) + Ch(o) + R(o) + X(o) - RV(o).
I is implementation, M is migration and parallel running, P is internal people, C is cloud and infrastructure, V is vendors and licences, O is operations and support, Ch is change and enhancement, R is the risk-adjusted expected cost, X is the provision for exit or transition, and RV is any residual value or contract credit that finance accepts.
Show raw cost and risk-adjusted cost as separate lines. The formula is a way to structure the decision and does not replace accounting rules: finance decides how costs are classified and discounted.
| Symbol | Category | Typical evidence |
|---|---|---|
| I | Implementation | Delivery plan, supplier estimate, internal capacity |
| M | Migration and parallel running | Data, SEO, integration, training and dual-running plan |
| P | Internal people | Fully loaded role cost and allocated time |
| C | Cloud and infrastructure | Usage model, provider rates and commitments |
| V | Vendors and licences | Contracts, tiers, overage fees and renewal terms |
| O | Operations and support | On-call, monitoring, security and support model |
| Ch | Change | Roadmap throughput and cost per unit of delivery |
| R | Risk-adjusted cost | Risk register with probability and impact |
| X | Exit provision | Data export, replacement, termination and handover |
3. Calculate delta TCO, then NPV if you need it
Calculate the difference between options as DeltaTCO24 = TCO24(target) - TCO24(baseline). A positive delta means the target costs more over the period, before any benefits. A negative delta means it costs less in the model, which on its own does not make it the better strategic choice.
If timing matters, calculate NPV using the discount rate r approved by finance: NPV(o) = sum from month t=0 to 24 of NetCashFlow(o,t) / (1 + r)^(t/12). Then compare DeltaNPV = NPV(target) - NPV(baseline).
The project team should not pick its own discount rate. Use the rate and cash-flow convention that finance provides, and show the undiscounted TCO24 next to the NPV so the timing assumptions stay visible.
4. Build the cost ledger by responsibility
Structure the ledger so that each line can be traced to a quantity, rate, timing, owner and source. A single large 'development' line hides what will keep recurring after launch.
| Cost category | Include | Often forgotten |
|---|---|---|
| Discovery and design | Architecture, data, security, UX, delivery planning | Time spent by internal subject experts |
| Build | Storefront, backend, integrations, tooling, environments | Non-production and test infrastructure |
| Migration | Content, customers, orders, URLs, redirects, validation | Parallel running and reconciliation |
| People | Product, engineering, QA, data, SRE, security, support | Management and vendor coordination |
| Cloud | Compute, storage, database, network, CDN, backup | Capacity for peaks and disaster recovery |
| SaaS and vendors | CMS, search, payments, tax, email, monitoring | Overage fees, minimum commitments and premium support |
| Operations | On-call, incidents, patching, access reviews, restore tests | Optimisation after launch |
| Change | Features, experiments, regression fixes, upgrades | Coordinating releases across systems |
| Exit | Export, documentation, replacement and termination | Overlapping contracts during the transition |
5. Use inputs you can defend
Every input needs a definition, unit, period, owner, source date and a note on how confident you are. A supplier quote is evidence of the price, but it says nothing about how much you will use. A usage forecast is evidence of demand, but it says nothing about the rate you will pay.
- Monthly sessions, orders, API calls, catalogue size, media volume and data transfer.
- Markets, currencies, price lists, channels and planned growth events.
- The ratio of peak to normal demand and the headroom you need.
- Internal roles, fully loaded rates, time allocation and hiring lead times.
- Supplier terms for implementation, support, minimum commitments and overages.
- Current effort spent on incidents, support, releases and manual work.
- The migration inventory: data, URLs, integrations, reports and open transactions.
- Target obligations for reliability, recovery, security and compliance.
- Demand on the roadmap and how often you expect to change things.
6. Model base, peak and downside cases separately
A single forecast gives a false sense of precision. Build three scenarios that are consistent in themselves and calculate the full TCO24 for each. If you change cloud traffic, change support, vendor tiers and capacity with it.
- State which variables move together.
- Show the cost driver behind each change between scenarios.
- Keep a separate stress test for extreme continuity planning.
- Update the scenarios when contracts or demand assumptions change.
| Scenario | Purpose | What to vary |
|---|---|---|
| Base | The operating plan you can best support with evidence | Demand, roadmap, staffing and contracted rates |
| Peak | Known seasonal or campaign load | Traffic pattern, capacity, support cover and provider overage fees |
| Downside | A bad but plausible case for delivery or demand | Delays, rework, lower volume, overlapping vendors and incident cost |
7. Tie spending to commerce units
TCO gives you a total, but day-to-day decisions also need unit economics. Choose units that are linked to real decisions and define them the same way for every option and period.
Useful formulas include technology cost per order = attributable technology cost / completed orders, cost per active market = shared and direct market cost / active markets, and change cost per release = attributable change cost / production releases. Add cost per visit or per active customer only if the denominator is stable and actually useful.
| Unit metric | Decision it supports | Watch out for |
|---|---|---|
| Technology cost per order | Planning for scale and margin | Confusing it with total fulfilment cost |
| Cloud cost per order | Infrastructure efficiency | Mixing peak and normal periods; show them separately |
| Cost per active market | International expansion | Undefined rules for allocating shared costs |
| Change cost per release | Comparing delivery models | Reading it without lead time and quality |
| Support cost per order | Operational workload | Hiding differences in channel and market mix |
8. Add a risk-adjusted expected cost
Turn significant uncertainty into an explicit expected-cost line. For risk i, ExpectedCost(i) = Probability(i) x FinancialImpact(i). R is then the sum of the expected costs, adjusted where finance finds dependencies or double counting.
Ranges for probability and impact are more honest than precise-looking single numbers. Record the cost of mitigation separately and state whether it reduces the probability, the impact or both.
- Use different probabilities per scenario where the exposure changes.
- Do not count the same downside in both the scenario cost and the risk cost.
- Give each risk an owner and a trigger for reviewing it.
- Keep non-financial risks visible even if you cannot credibly put a number on them.
| Risk | Possible cost components |
|---|---|
| Migration delay | Keeping the team longer, overlapping vendors, postponed retirement of the old system |
| SEO regression | Recovery work and lost contribution, based on approved assumptions |
| Integration failure | Manual processing, support, rework and delayed orders |
| Insufficient capacity at peak | Emergency scaling, incident response and service credits |
| Reliance on key people | Recruitment, handover and interrupted delivery |
| Vendor exit | Building a replacement, exporting data and overlapping contracts |
9. Keep benefits out of the cost ledger
Speculative revenue should not be netted into TCO. Keep a separate benefits case with an owner, the mechanism, a baseline, timing and a confidence level. Examples include less manual work, faster market launches, lower cost from platform limitations or more frequent releases.
If a benefit cannot be measured credibly, present it as a strategic criterion instead of forcing a money value onto it. The decision becomes more honest, and it is still just as quantitative.
| Claim | Evidence needed | Weak substitute |
|---|---|---|
| Less operating effort | Current task volumes and the redesigned process | A generic automation percentage |
| Faster delivery | A baseline for current lead times and the changed dependency path | The framework's reputation |
| More flexibility in markets | Named launches or requirements that are blocked today | General claims about scalability |
| Higher conversion | A testable hypothesis about the experience and an attribution plan | A vendor benchmark |
10. Agree the decision criteria before you see the result
Agree the decision rule with finance, product, operations and engineering before the model is finished. Otherwise the threshold tends to move until it fits the architecture someone already prefers.
- Affordability: cash and staffing fit the approved plan in every period that matters.
- Cost: DeltaTCO24 and, if you use it, DeltaNPV fall within the agreed tolerance.
- Resilience: the business can still operate in the peak and downside scenarios.
- Unit economics: there is an explainable path to acceptable unit costs at the expected scale.
- Strategic fit: the named platform constraints are actually removed.
- Execution: migration, ownership and support are funded.
- Exit: code, data, contracts and operational knowledge can be taken elsewhere.
11. Final model review
The spreadsheet is finished when someone else can reproduce the result and explain what would change it.
- All options use the same scope, period and demand assumptions.
- The TCO24 categories add up to the detailed monthly lines.
- DeltaTCO24 is calculated against a fully costed baseline.
- If NPV is used, it uses a rate and cash-flow convention approved by finance.
- The base, peak and downside scenarios are internally consistent.
- Unit metrics have stable definitions and clear rules for attributing cost.
- Risk cost is adjusted for probability and not double counted in the scenarios.
- Benefits are evidenced separately from costs.
- Every significant input has an owner, a source and a confidence label.
- The decision criteria were agreed before the final result was known.