Development

Deciding on headless: the questions before the architecture

Ten questions that decide whether a headless storefront is right for your store, what it costs to own, and the middle options between a theme and a rebuild.

By CartKernel · Published September 6, 2026

Headless is an answer. The mistake stores make is choosing it before agreeing on the question. A custom front end talking to a commerce platform over an API solves specific problems well, creates ongoing obligations, and does nothing at all for several of the reasons people give for wanting it. The decision should take a fortnight of honest questions, not a demo.

Below are the questions worth asking, in the order that saves the most wasted work, plus the middle options that most stores end up choosing once the questions have been answered.

Question one: what breaks today that a theme cannot fix

Write the specific failure down. Not “the site feels dated” or “we want more control”, but a sentence with a subject and a consequence: a configurator our theme cannot render, a content model with relationships the platform’s pages cannot express, six regional storefronts that need one codebase, a page type that has to be assembled from three systems.

If nothing on the list survives the question “could a well-built theme do this”, the project is a redesign rather than an architecture change, and it should be scoped as one. Most speed complaints, most design complaints and most merchandising complaints fall into that category.

Question two: what happens to the people who edit the site

This is the question that decides more headless projects than any technical factor, and it is usually asked last.

On a theme, a merchandiser rearranges a homepage, adds a section, changes a banner and reorders a collection without asking anyone. On a custom front end, every one of those becomes either a content model somebody designed in advance or a developer ticket. Teams that ship weekly on a theme sometimes ship monthly after a headless build, and the lost velocity costs more than the performance gained.

The fix is to invest in the editing experience deliberately: a content management system with real preview, components modelled around what marketing actually changes, and a deployment pipeline fast enough that a copy change is not an event. That investment is part of the project cost, not an extra.

Question three: who owns the front end in two years

A headless storefront is software your business now owns. It needs dependency updates, security patches, framework upgrades, someone on call when a build fails on a Friday, and a person who understands it well enough to change it. A theme is also software, but the platform carries much more of that weight.

Answer this concretely. Named people or a named partner, with a budget line. “We will figure it out” has ended more headless storefronts than any technical limitation.

Question four: is the speed problem actually in the framework

Sometimes it is, and often it is not. Before assuming a rebuild is the route to better Core Web Vitals, measure what is costing the time on the current site. In practice the largest contributors on a typical store are third-party scripts, oversized images, apps that inject render-blocking JavaScript, and fonts that block paint. All four are fixable without changing architecture, and all four will follow you into a headless build if the habits do not change.

A custom front end does raise the ceiling. Streaming server rendering, code splitting per route and full control over the critical path let a good team reach numbers a theme carrying six apps will not reach. It raises the ceiling; it does not raise the floor. Site speed optimization on the existing store is the cheaper experiment, and if it gets you where you need to be, the architecture question goes away.

Question five: what does the app ecosystem do for you today

Count the apps that render something on the storefront: reviews, wish lists, size guides, upsell widgets, loyalty, search and filtering, back-in-stock, subscriptions. On a theme, each of those installs and works. On a headless front end, each needs an integration, and some are only available as a script tag that will not fit your rendering model.

For each app on the list, write down one of three answers: it has a supported API and we will integrate it, we will rebuild this feature, or we will drop it. A project that reaches launch with an unanswered item on this list launches missing a feature that was earning money.

Checkout is the exception worth naming. On Shopify the checkout stays on Shopify regardless, which is a considerable simplification: payments, fraud, taxes, accelerated wallets and compliance remain the platform’s problem.

Question six: what is the search visibility plan

A custom front end can rank as well as a theme, and it will not do it by accident. Server rendering, real URLs, correct status codes, canonical tags, structured data, sitemaps, pagination, hreflang for multi-region and image optimization all have to be built, tested and kept working through every deployment.

Client-side-only rendering is the specific risk. Google can render JavaScript, and rendering is a second pass with its own queue, so a store that ships content only after hydration gives up speed and consistency in indexing for no benefit. Render on the server, hydrate for interactivity.

Plan for a launch window with a redirect map, a crawl comparison and monitoring in place. A replatform without that discipline is how a store gives up organic traffic it took years to earn, which is the subject of does migrating ecommerce platforms hurt SEO and the ecommerce site migration checklist.

Question seven: does the return justify the cost

Do the arithmetic before the design phase, not after.

Say a store does ten million in annual revenue at a two percent conversion rate. A build, a content system, integrations, testing and migration is a project of real size, and running the platform afterwards is a recurring cost. To pay for itself in two years, the storefront has to raise conversion, order value or organic revenue by a share of revenue you can name. Write down the number the project needs to produce, and ask whether the mechanism you have in mind plausibly produces it. Compare it against what the same budget spent on merchandising, retention and paid media would produce.

The figures above are illustrative. Yours are not, and they are the ones the decision should rest on. Weigh both against contribution margin, because a revenue lift at low margin buys less runway than it appears to.

Question eight: how urgent is it

A headless build takes months, and during those months the current store gets little attention. If the business needs growth this quarter, that is an argument for fixing the theme now and revisiting architecture when there is slack. How long does a headless build take gives realistic ranges by scope.

The middle options

Most stores that ask the questions above end up somewhere between a stock theme and a full rebuild.

A well-built theme with custom sections. Modern theme architecture supports genuinely custom page types and app extensions that do not block rendering. This covers more requirements than most people expect.
A theme plus an isolated custom application. A configurator, a fitment lookup, a quote builder or a bulk order pad built as its own application and embedded, while the rest of the store stays on the theme. You get the custom experience where it matters and keep the editing workflow everywhere else.
A headless front end for one surface. Content and landing pages on a custom stack, product and cart on the platform, joined by consistent navigation. Useful for content-heavy brands whose commerce pages are conventional.
Full headless. Everything except checkout on a custom front end, with a content system behind it. The right answer when several of the questions above resolve toward it, and an expensive answer when only one does.

When headless is clearly right

Three or more of these being true is a reasonable threshold: an in-house engineering team that will still be there next year, multiple brands or regions sharing one codebase, a product experience that needs interaction a theme cannot express, a content operation with an established editorial workflow and its own content system, or a scale where a small conversion improvement is worth more than the build.

When fewer than three are true, spend the budget on the store you have. The decision is reversible in one direction only, and it is worth being late to rather than early. If you want the questions worked through against your own store, headless storefront development and platform migration describe how we scope both paths.