How do I know whether I actually need headless?

There are four reasons that justify it. Speed is genuinely costing you sales and the theme cannot get there. The design you need is impossible inside a theme. You are joining the store to a substantial content operation. Or one back end has to serve both a website and an app. If none of those describe you, a serious theme rebuild will get you most of the outcome for a fraction of this budget, and we will say so before you spend anything.

Will my existing apps still work?

Some will, several will not, and this is the part that ruins headless launches. Any app that works by injecting a script into your theme stops existing when the theme does — that typically means reviews, upsells, popups, chat and loyalty. We inventory every one of them in week one and cost the replacement for each, because finding this out two days before launch is how projects get abandoned.

Who edits the pages after launch?

Whoever edits them now, provided we plan for it. In a theme, marketing can change a homepage section themselves. In a headless build that ability does not exist unless it is deliberately built, usually by putting a content system behind the pages that change often. If nobody raises this during architecture, the team discovers after launch that every copy change is a developer ticket.

Does the checkout change?

Usually not, and that is the right answer. On Shopify the checkout stays on Shopify — it is the piece carrying payment compliance, tax logic, fraud screening and years of conversion work. Building your own is a large cost with a real downside risk. We would need a genuinely unusual requirement before recommending it.

Will my search rankings survive?

They survive if the storefront is rendered on the server and the migration of URLs is treated as its own workstream. A theme quietly did a great deal of SEO for you — metadata, canonicals, structured data, sitemaps, pagination. All of it now has to be written deliberately. That work is in the scope, not an extra.

What does this cost to run once it is live?

Hosting for the storefront, your commerce platform's own plan, a content system if you have one, and the replacements for whichever apps did not survive. That last group is the unpredictable one, which is why we price it during the assessment rather than guessing at it now.

E-commerce

Custom headless commerce

A Shopify or Medusa back end behind a storefront you actually own — built only when there is a real reason, and after we have listed everything it breaks.

From: $6,000–$35,000
Typical time: 2–4 months
Usually bought by: Scaling brands

When this is the right answer, and when it is not

Headless commerce is sold as faster and more flexible. Both are true and neither is a reason on its own.

The honest position is that a theme on a mature platform is a remarkably good deal. Somebody else has already built the cart, the checkout, tax handling, refunds, order emails, fraud screening and an app ecosystem, and they maintain all of it. Walking away from that means taking responsibility for a great deal you currently get for free, and it only pays when something specific and expensive is being blocked.

There are four situations where it pays. Speed is costing real revenue and the theme has hit its ceiling. The interface you need — genuinely custom product configuration, unusual navigation, a storefront that behaves like an application — is not achievable inside theme constraints. The store has to sit inside a serious content operation, with editorial, guides and campaigns that a theme's page structure cannot hold. Or a single back end must serve a website and a native app without maintaining two catalogues.

If none of those apply, you do not need this, and hearing that is the most valuable thing we can do on the first call. Selling a large headless build to a business whose theme rebuild would have been enough earns money once and costs a reputation.

The other half of the honest position is that headless does not simply add capability. It removes things silently. Everything your theme was quietly doing — the SEO scaffolding, the app integrations, the ability for your marketing team to change a page without a deployment — stops happening unless someone rebuilds it deliberately. That list, not the storefront code, is what makes these projects long.

How the build runs

Fitness assessment and app teardown. Which of the four reasons applies, and a line-by-line inventory of every app currently injecting a script into the theme, with a named replacement and a cost for each. This produces two quotes — one for staying on the theme and improving it, one for building headless — so the decision is yours with real numbers on both sides. One to two weeks.
Architecture. Where each piece of data comes from, what is cached and for how long, how the cart is held, how content reaches the pages, and how the whole thing deploys. Storefront API queries are designed here, including how variants and metafields will be shaped, because retrofitting that later touches every template. One to two weeks.
Storefront build. Product pages, collections, search and filtering, cart state, account pages, and the handoff into the platform's checkout. Built on Next.js against Shopify's Storefront API or Medusa, typed end to end, with image handling designed in rather than bolted on. Four to eight weeks, depending on how many page types exist.
SEO reconstruction. Server rendering, metadata, canonical URLs, structured data, sitemaps, pagination and redirects — every piece the theme used to provide, written explicitly and verified against a crawl before launch rather than after. One to two weeks.
Content editing, deployment and cutover. The content system wired up so your team can change what they used to change, deployment on Vercel or Oxygen with previews, then a staged cutover with the redirect map running first and Search Console watched afterwards. One to two weeks.

What moves the price

The range is $6,000–$35,000 over 2–4 months, and it is wide because these projects genuinely differ by a factor of five.

How many page types exist. A focused catalogue with one product template and three collection layouts is a contained build. A brand with configurable products, bundles, lookbooks, store locators and a guides section is many builds sharing a codebase.

Content, languages and currencies. A content system with a modelled schema, editorial workflow and previews is a project inside the project. Multiple locales multiply it — not only translation, but currency, tax display, delivery rules and URL structure.

What has to be rebuilt to replace an app. This is the factor that moves the number most and the one nobody estimates. A loyalty programme or a complex bundling engine that currently arrives as a theme script can be a five-figure line on its own once it has to be reimplemented against the API.

Where these builds go wrong

The app inventory happens too late. The storefront is built, launch day arrives, and reviews have vanished from every product page, the upsell no longer fires, and the chat widget is gone — because all three worked by injecting script into a theme that no longer exists. This is entirely predictable and entirely preventable, and it belongs in week one alongside a cost for each replacement, not in the week of launch.

Nobody asks who edits the site afterwards. In a theme, a marketing manager changes the homepage banner in ten minutes. After a headless build with no content layer, that same change is a code edit, a review and a deployment. Teams discover this in the first week after launch and it poisons an otherwise successful project. Either a content system is in scope or the team is told plainly, before signing, that it is not.

The checkout gets rebuilt because it can be. The temptation to own the last step is strong and it is usually wrong. The platform's checkout carries payment compliance, tax calculation, fraud screening, wallet support and years of conversion tuning that you are not going to replicate. Handing the cart back to it is not a compromise, it is the design. Building your own needs a requirement so specific that you can name it in one sentence.

See where the site stands before you brief anyone.

If the site is already live, start from what it scores rather than from a guess. The audit reports what it checked, what it found, and — the part most tools leave out — what it could not check, and why.

See the website audit Talk about this work

Questions people ask before they commit.

How do I know whether I actually need headless?: There are four reasons that justify it. Speed is genuinely costing you sales and the theme cannot get there. The design you need is impossible inside a theme. You are joining the store to a substantial content operation. Or one back end has to serve both a website and an app. If none of those describe you, a serious theme rebuild will get you most of the outcome for a fraction of this budget, and we will say so before you spend anything.
Will my existing apps still work?: Some will, several will not, and this is the part that ruins headless launches. Any app that works by injecting a script into your theme stops existing when the theme does — that typically means reviews, upsells, popups, chat and loyalty. We inventory every one of them in week one and cost the replacement for each, because finding this out two days before launch is how projects get abandoned.
Who edits the pages after launch?: Whoever edits them now, provided we plan for it. In a theme, marketing can change a homepage section themselves. In a headless build that ability does not exist unless it is deliberately built, usually by putting a content system behind the pages that change often. If nobody raises this during architecture, the team discovers after launch that every copy change is a developer ticket.
Does the checkout change?: Usually not, and that is the right answer. On Shopify the checkout stays on Shopify — it is the piece carrying payment compliance, tax logic, fraud screening and years of conversion work. Building your own is a large cost with a real downside risk. We would need a genuinely unusual requirement before recommending it.
Will my search rankings survive?: They survive if the storefront is rendered on the server and the migration of URLs is treated as its own workstream. A theme quietly did a great deal of SEO for you — metadata, canonicals, structured data, sitemaps, pagination. All of it now has to be written deliberately. That work is in the scope, not an extra.
What does this cost to run once it is live?: Hosting for the storefront, your commerce platform's own plan, a content system if you have one, and the replacements for whichever apps did not survive. That last group is the unpredictable one, which is why we price it during the assessment rather than guessing at it now.

Often taken together.

Start with the brief, not the invoice.

Send what you are trying to achieve. You get a written scope, a price and a date — or an honest “this is not the right service for that”.

Talk about Custom headless commerce All E-commerce services