Every headless commerce decision gets made on a build quote. A systems integrator sends a number for the front end, the migration and the first set of integrations, finance compares it against the annual cost of the theme-based store it replaces, and the project either clears the bar or it does not. That comparison is the wrong one, because the build is the only line in a headless budget that arrives as a single, legible invoice.
The rest of the cost shows up monthly, in pieces, from six or seven vendors and at least one payroll line. Two years after launch, most retailers who went headless can tell you what they paid for the build and cannot tell you what they paid in total. This article reconstructs the full 24-month picture: what the categories are, roughly how they scale, and which of them quietly grow after go-live.
In short
- Build is typically 30% to 45% of two-year spend, not the whole number. The remaining 55% to 70% is recurring platform fees, hosting and rendering, and developer time.
- Hosting stops being a flat fee. Server-side rendering costs scale with traffic and with how aggressively you cache, so a successful campaign raises the infrastructure bill.
- The SaaS stack multiplies. A headless CMS, a search provider, a personalization engine and an image service are four subscriptions that a monolithic theme bundled into one.
- Integration maintenance is the most underestimated line. Every upstream API version bump is work you now own rather than work your platform vendor absorbed.
- Developer availability is the real constraint. Headless converts a fixed platform fee into a variable staffing commitment, and staffing is the line that fails first when budgets tighten.
None of the figures below are quotes for your store. They are the ranges that appear repeatedly in vendor pricing pages, published implementation case studies and practitioner accounts, and they are offered as a structure for your own numbers rather than as a benchmark to adopt. If you have not yet settled the platform question itself, the trade-offs sit in our guide on how to choose the right e-commerce platform for your store, which frames the architecture choice before the budget one.
What sits in a headless commerce budget
A monolithic commerce platform sells you a bundle. The checkout, the catalog, the content editor, the template layer, the CDN, the image resizing, the search box and the hosting all arrive under one monthly fee, and the vendor absorbs the cost of keeping them compatible with each other. Headless unbundles that. You buy the commerce engine, then buy or build every layer the bundle used to include.
That unbundling is the entire cost story. It is not that headless is expensive in some abstract way; it is that costs the platform used to hide now appear as separate invoices and separate maintenance obligations. Before modelling anything, it helps to name the seven categories.
The seven categories
- Initial build: front-end development, design implementation, data migration, integration wiring, QA and launch support.
- Commerce engine licence: the platform or API-first backend that still owns cart, checkout, orders and inventory.
- Hosting and rendering: the compute that renders pages, plus CDN, edge functions and bandwidth.
- Content and experience SaaS: headless CMS, search, personalization, reviews, image and video delivery.
- Integration maintenance: keeping ERP, PIM, tax, shipping and marketing connections working through version changes.
- Developer capacity: in-house salary, agency retainer or both, for everything from a copy change to a Core Web Vitals regression.
- Opportunity cost: the campaigns, merchandising experiments and seasonal pages that wait in a development queue instead of shipping the same afternoon.
The last one is not a line item and will not appear in any finance system. It is still real, and it is the category that decides whether the first year feels like an investment or a tax. A merchandising team that could previously launch a landing page in two hours, and now files a ticket, is paying a cost that does not show up anywhere.
A 24-month shape, not a 24-month quote
Here is how the categories typically distribute across two years for a mid-market retailer, expressed as a share of total two-year spend rather than in currency. Shares move with traffic, catalog size and how much work stays in-house, so treat the right-hand column as the output of a model you still need to build.
| Category | When it lands | Typical share of 24-month spend |
|---|---|---|
| Initial build and migration | Months 0 to 6, front-loaded | 30% to 45% |
| Commerce engine licence | Monthly or annual from day one | 10% to 20% |
| Hosting, CDN and rendering | Monthly, grows with traffic | 5% to 12% |
| CMS, search, personalization | Monthly or annual, grows with seats | 8% to 18% |
| Integration maintenance | Lumpy, clustered around vendor releases | 5% to 15% |
| Developer capacity and retainer | Continuous from month 1 | 15% to 30% |
Two patterns matter more than the percentages. First, the build is a minority of the total even in the most build-heavy scenarios. Second, every other line is recurring, which means the second year costs almost as much as the first year minus the build. Finance teams that model headless as a capital project with a long tail of small running costs tend to find the ratio reversed.
Build cost versus the theme you replaced
The honest comparison is not headless build versus theme licence. It is headless build versus what you were already spending on theme customization, app subscriptions and developer hours to keep a monolithic store doing things it was not designed to do. Plenty of retailers reach the headless conversation precisely because that figure had already grown uncomfortable.
If you are still deciding whether the architecture suits your store at all, the mechanics are worth understanding first. Our explainer on headless commerce explained covers what actually gets decoupled and what stays with the commerce engine, which is the detail that determines how large the build really is.
What drives the build number up
Four variables account for most of the variance between a lean build and one that doubles its estimate. None of them are about design quality.
- Checkout scope. Keeping the platform’s hosted checkout is dramatically cheaper than building a custom one. Custom checkout adds payment integration, fraud handling, tax edge cases and an ongoing compliance obligation.
- Number of integrations. Each ERP, PIM, loyalty or subscription connection is a discrete piece of work with its own error states. Integration count predicts build cost better than page count does.
- Catalog complexity. Configurable products, regional pricing, bundles and large variant matrices all push rendering and caching logic into custom code.
- Market count. Multi-currency, multi-language and market-specific compliance requirements multiply both build and QA scope.
A single-market store with a hosted checkout, a simple catalog and two integrations is a different project from a four-market store with a custom checkout and an ERP dependency. Quotes that look wildly inconsistent across agencies are often pricing different answers to these four questions.
The comparison table nobody builds
This is the table that belongs in the business case, with your own figures in place of the shapes. The point is the pattern of where money goes, not the magnitudes.
| Line | Monolithic theme store | Headless build |
|---|---|---|
| Front-end implementation | Theme purchase plus customization; weeks | Custom application; months |
| Hosting | Included in platform fee | Separate, usage-based |
| Content editing | Included page builder | Separate CMS subscription plus modelling work |
| Search | Native, basic | Separate provider, better relevance, extra fee |
| App ecosystem | Install and configure | Many apps will not work; replaced by custom code |
| Copy and layout changes | Merchandiser, same day | Developer ticket unless the CMS was modelled for it |
| Platform upgrades | Vendor handles | You handle the front end and the integrations |
The row that causes the most post-launch friction is the second-to-last one. Content modelling in the CMS is what determines whether a merchandiser can edit a page without a deployment, and it is routinely cut from build scope to protect the timeline. That cut is paid back monthly, in developer time, for the life of the site.
For a more direct side-by-side on one platform family, including where the lines actually cross, we have looked at headless versus monolithic Shopify and the real cost difference, which isolates the architecture variable from the platform variable.
Hosting, CDN and rendering bills
On a monolithic platform, hosting is a sunk cost inside the monthly fee, and traffic spikes are the vendor’s problem. Headless moves that line onto your invoice and makes it variable. The architectural decisions you make at build time determine whether that variability is a rounding error or a budgeting problem.
Rendering strategy is a cost decision
How pages get rendered is usually discussed as a performance and SEO question. It is equally a cost question, because each strategy trades compute for freshness.
| Rendering mode | Cost behaviour | Best fit |
|---|---|---|
| Static generation | Cheapest to serve; build minutes grow with catalog size | Content pages, stable catalogs |
| Incremental or on-demand regeneration | Moderate; pays compute only on invalidation | Large catalogs with frequent price changes |
| Server-side rendering | Scales directly with traffic; sensitive to cache hit rate | Personalized or inventory-sensitive pages |
| Client-side rendering | Cheap compute; weakest crawl and first-paint profile | Logged-in areas, account pages |
A catalog of 200,000 SKUs that regenerates statically on every price feed update can spend more on build minutes than a comparable site spends on server-side rendering. The failure mode is never “we chose wrong” so much as “we never modelled it”. Ask any implementation partner for an estimated monthly compute figure at your current traffic and at 3x that traffic, and treat an unwillingness to produce one as a signal.
The lines that surprise people
- Image transformation. On-the-fly resizing and format conversion is metered by most providers. A long-tail catalog generates a long tail of unique transformations.
- Edge function invocations. Geolocation, A/B tests and personalization at the edge are billed per request, and they fire on cached pages too.
- Preview environments. Every branch deployment is compute. Active development on a busy team is a real monthly number.
- Bot and scraper traffic. Server-rendered pages served to aggressive crawlers cost the same as pages served to customers. Without filtering, you pay to render for scrapers.
The last one has grown noticeably as automated agents and AI crawlers have become a larger share of requests on retail sites. A cache strategy that treats non-human traffic the same as human traffic converts a crawl problem into an infrastructure bill, which is a worse place to discover it.
CMS, search and personalization subscriptions
This is where the stack multiplies. A monolithic platform includes a page editor, basic search and some merchandising rules. Headless replaces each of those with a specialist vendor, and each specialist is better at its job and charges separately for it. The sum is usually larger than people expect, and it grows in ways that are easy to miss.
The common subscription set
- Headless CMS: priced on seats, API calls, environments and sometimes locales. The architecture is well described in the general headless CMS literature, but pricing models vary sharply between vendors.
- Search and discovery: priced on indexed records and search operations. Variant-level indexing can multiply record counts well beyond SKU count.
- Personalization or experimentation: priced on monthly tracked users or events. This line scales with success.
- Media delivery: priced on transformations, bandwidth or both.
- Reviews, loyalty and subscriptions: often carried over from the previous stack, sometimes requiring a more expensive API-enabled tier.
Two scaling mechanics deserve attention at contract time. Seat-based CMS pricing penalises exactly the outcome you want, which is more people editing content without developer help. API-call or operation-based pricing on search and CMS means a traffic increase raises two bills at once, the rendering bill and the data bill.
Negotiate the growth curve, not the entry price
First-year discounts are easy to get and mostly irrelevant. What matters is the overage rate and the price of the next tier, because that is what you will actually be paying in month 18. Ask for the tier above the one you are buying in writing, and ask what happens at 2x your projected volume.
If you are still assembling the stack rather than renegotiating it, the layer-by-layer view in our rundown of the 2026 headless commerce stack worth shortlisting is a reasonable starting shortlist, and it flags which layers can be deferred past launch. Deferring a layer is the single most effective way to keep year-one subscription spend down.
Integration and middleware maintenance
On a monolithic platform with an app ecosystem, integrations are somebody else’s maintenance problem. When a tax provider changes an API, the app vendor ships an update and you install it. Headless shifts that burden to whoever wrote your integration, which is usually you or your agency.
This is the least predictable line in the budget and the one most often set to zero. It does not behave like a monthly fee. It arrives in clusters, when an upstream vendor deprecates an endpoint, when a payment provider mandates a new authentication flow, or when your ERP goes through its own upgrade.
What triggers unplanned integration work
- API deprecations. Most commerce and logistics vendors run versioned APIs with deprecation windows measured in months. Each window is a scheduled piece of work.
- Compliance changes. Payment authentication, consent management and accessibility requirements all land as front-end and integration work.
- Upstream system upgrades. An ERP or PIM migration on the business side becomes a commerce project on your side.
- Vendor consolidation. When one of your SaaS providers is acquired, roadmaps and APIs change, sometimes quickly.
A practical approach is to budget integration maintenance as a standing percentage of build cost per year rather than as a list of known tasks. Teams that run this well tend to reserve something in the range of 10% to 20% of the original build cost annually, and to treat an unused reserve as a good year rather than as a saving to reallocate.
Middleware is a choice with a price tag
Many headless builds add an orchestration layer between the front end and the various back ends, whether a commercial integration platform or a custom API gateway. It genuinely reduces coupling and makes vendor swaps cheaper. It is also one more component to host, monitor, secure and staff.
The question to ask is whether you expect to swap back-end vendors within the budget horizon. If the answer is no, middleware added at build time is cost brought forward for flexibility you may not use. If the answer is yes, skipping it means the swap itself gets more expensive later.
Developer availability and retainer costs
This is the line that decides outcomes. Headless converts a predictable platform fee into a commitment to have engineering capacity available continuously, and capacity is harder to buy than software. The budget risk is not that developers are expensive; it is that the project assumed access to people who turn out to be busy elsewhere.
Three staffing models, three failure modes
| Model | Cost profile | Typical failure mode |
|---|---|---|
| In-house team | Fixed salary plus recruitment and ramp-up | Key-person risk; the one person who understands the build leaves |
| Agency retainer | Monthly fee with a capped hour bucket | Hours go to incidents, so improvements never ship |
| Ad hoc contracting | Lowest commitment, highest hourly rate | Slow response during peak trading; no context retained |
Most retailers end up with a hybrid, and the hybrid is usually the right answer: one in-house owner who holds the context, plus a retainer for surge capacity. What rarely works is the implicit fourth model, where nobody is assigned and work is absorbed by whoever has time. That model produces an unmaintained front end within about a year.
Benchmarking the cost of capacity
For an internal hire, the loaded cost is well above the salary figure once employment taxes, benefits, equipment and recruitment are included. For a sense of the underlying wage base in the United States, the Bureau of Labor Statistics occupational data for software developers publishes current median pay, and it is worth checking directly because the figures are revised. Loaded cost of 1.25x to 1.4x base salary is a common planning assumption, though it varies by country and by benefits package.
For an agency retainer, the number to interrogate is not the monthly fee but what the fee buys when something breaks on a Friday in late November. Retainers that look identical on paper differ enormously in response commitment. Put the peak-season response expectation in the contract, because that is the week when the difference between retainer tiers becomes measurable in revenue.
The hidden cost of slow change
Separate from the staffing bill is the throughput cost. If a seasonal landing page takes four days instead of four hours, the campaign calendar quietly contracts around what is feasible. Over two years that constraint shapes the merchandising plan, and the resulting lost upside never appears in any cost report.
This is the strongest practical argument for investing in content modelling at build time. Every editable region you give the merchandising team is a developer ticket you never pay for again, and the compounding is substantial over a 24-month horizon.
The revenue case that has to cover all of it
Add the categories together and headless typically needs to produce a measurable commercial return, not a qualitative one. The projects that end up looking like good decisions are the ones where someone wrote down the expected mechanism of return before signing, then measured it afterwards. The projects that look like mistakes usually had “better performance” as the entire business case.
The four mechanisms that actually pay
- Conversion lift from speed. Real, but bounded, and only available if the old site was genuinely slow. A theme store already passing Core Web Vitals has little headroom here.
- Organic traffic gains. Available when the previous architecture limited internationalization, URL structure or rendering of key templates. Also the mechanism most easily reversed by a bad headless implementation.
- Experimentation velocity. The most durable mechanism, and the one that depends on the content modelling decision rather than on the architecture itself.
- Channel reuse. Serving an app, a kiosk, a marketplace feed or an agent-facing API from the same commerce back end. This is the mechanism with the clearest architectural justification.
Note that only the fourth mechanism is unavailable without headless. The other three can often be obtained more cheaply on a monolithic stack with focused work. That is not an argument against headless; it is an argument for being specific about which mechanism you are buying.
A break-even worth running before you sign
The arithmetic is simple enough to do on one page. Take two-year total cost, subtract the two-year cost of staying put including the apps and developer hours you already pay for, and divide the difference by your current gross margin per order. That gives the number of additional orders over 24 months that the project has to generate to break even.
Expressed that way, the decision usually clarifies quickly. For a high-volume retailer the required lift is often a fraction of a percentage point and plainly achievable. For a store doing modest volume the same arithmetic can imply a conversion improvement nobody has ever credibly delivered. We walked through this calculation with worked numbers in when headless commerce actually pays for a retailer, including the volume thresholds where the answer flips.
What to track after launch
- Total cost of ownership per month, with every vendor invoice in one place, reviewed quarterly rather than annually.
- Developer hours by category, split between incidents, integration maintenance and new work. A rising incident share is an early warning.
- Time from merchandising request to live, which measures whether you bought velocity or lost it.
- Rendering cost per thousand sessions, which normalises infrastructure spend against traffic and exposes cache regressions.
The fourth metric is the one most teams lack and the one that catches problems earliest. A cache configuration change that triples rendering cost per session is invisible in an absolute monthly bill during a growth period, and obvious the moment you normalise it.
Where this leaves the decision
Headless is not expensive relative to its value for retailers who need multiple channels off one commerce back end, who have the engineering capacity to own a front end, and whose volume makes a fractional conversion gain material. It is expensive relative to its value for stores that wanted a faster site and could have had one for a tenth of the cost. The budget work is what tells you which of those you are, and it is worth doing before the quote arrives rather than after.
If the architecture question is still open on your side, the broader platform comparison in our e-commerce platform selection guide covers the monolithic and composable options alongside headless, which is the right frame for a decision that is ultimately about operating model rather than technology.
FAQ on headless commerce costs
How much does a headless commerce build cost?
Published implementation case studies and agency rate cards span a very wide range, driven mainly by checkout scope, integration count, catalog complexity and market count. Rather than anchoring on a figure, price the same scope with two or three partners and compare how each one answers those four variables. Quotes that differ by a factor of three are usually pricing different projects, not the same project at different rates.
Is headless cheaper than a monolithic platform over two years?
Usually not on direct cost. Headless tends to cost more in total over 24 months because you buy separately what the monolith bundled, and you carry maintenance the vendor previously absorbed. It can still be the better decision when it unlocks revenue mechanisms, particularly multi-channel delivery from one back end, that the monolith cannot provide at any price.
What is the single most underestimated headless cost?
Integration maintenance, with developer capacity close behind. Build budgets routinely include integration work and routinely exclude the cost of keeping those integrations alive through upstream API changes. Reserving an annual percentage of build cost for maintenance is a more reliable approach than listing known tasks, because the triggers come from vendors on their schedule rather than yours.
Can we go headless without hiring developers?
Not sustainably. A headless front end is an application you own, and applications need someone accountable for them. The minimum viable arrangement is one internal owner who holds the context plus a retainer with a defined response commitment for peak trading periods. Projects with no assigned owner tend to drift into an unmaintained state within roughly a year.
Why did our hosting bill grow after going headless?
Because rendering is now metered. Server-side rendering costs scale with requests and with cache miss rate, so traffic growth, a cache configuration change or heavy crawler activity all raise the bill. Tracking rendering cost per thousand sessions rather than absolute monthly spend makes the cause visible, since a regression in cache hit rate shows up immediately in the normalised figure.
Do we need middleware or an integration layer?
It depends on whether you expect to replace back-end vendors inside your budget horizon. Middleware reduces coupling and makes future swaps cheaper, at the cost of another component to host, monitor and staff. If no vendor change is anticipated, it is flexibility purchased in advance; if a change is likely, skipping it makes that change more expensive later.
How do we stop the CMS subscription from growing?
Interrogate the scaling mechanic before signing rather than the entry discount. Seat-based pricing gets expensive precisely as more people start editing content, which is the outcome you want, and API-call pricing rises alongside traffic. Ask for the next tier up and the overage rate in writing, and model your bill at double your projected volume.
What does content modelling have to do with cost?
Almost everything, on the operating side. Every page region that is properly modelled in the CMS is a change a merchandiser can make without a developer, and every region that is hard-coded is a recurring ticket. Content modelling is also the scope item most often trimmed to protect a launch date, which is why so many headless sites launch on time and then feel slower to operate than the theme they replaced.
How do we know if headless paid off?
Decide the mechanism of return before the build, then measure that specific thing. If the case was conversion speed, track conversion rate by template against the pre-launch baseline; if it was velocity, track time from merchandising request to live; if it was multi-channel, track revenue from the channels the old stack could not serve. A project with no stated mechanism cannot be evaluated after the fact, which is how two-year programmes end up with no verdict at all.