Tecof • September 15, 2026
What Is Headless Commerce? How It Differs From Classic E-commerce
In Brief
Headless commerce is an architecture that separates an e-commerce system's face (the storefront) from its body (catalog, cart, orders, payment). In a traditional setup the two arrive as one package, and beyond swapping themes your reach into the storefront is limited. In a headless setup the storefront is its own application, connects to commerce functions over an API, and is written in code that belongs entirely to you. The gain is flexibility and speed; the price is a second piece of software that needs continuous maintenance. As of 2026 the question is not "headless or monolith" but "is my storefront distinctive enough to justify maintaining it separately".
Thursday evening, 18.10. A furniture retailer turning over 40 million lira a year finished its headless migration six months ago. Mobile load time fell from 4.1 seconds to 1.3, and conversion rose from 1.4% to 1.9%. There is also a problem that same evening: when the carrier integration was updated, the delivery-date block on the storefront stayed broken for two days, because that block now lives in code the team wrote rather than in the platform.
Both pictures are real and they are two faces of the same coin. Headless hands you the storefront; it hands you responsibility for the storefront too. What decides the call is not enthusiasm for the technology but whether you have a team that can carry that responsibility.
What Headless Commerce Is and Where It Parts Ways
The "head" in the name is the layer the user sees: product page, listing, cart screen, campaign blocks. "Headless" means detaching that layer from the system and putting an independent application, written in whatever technology you choose, in its place.
The monolith: one package
In traditional platforms the storefront and the commerce engine live inside the same software. You pick a theme, edit colours and blocks from the admin, and edit the theme when you want a new campaign block. The advantage: everything updates together, preview works, changes made in the admin ship as made, and nobody has to write code. The disadvantage is hitting a wall the moment you want to step outside the template.
Headless: head and body apart
A headless setup has two separate pieces of software. The commerce engine runs at the back: products, stock, price, cart logic, orders, payment, returns. At the front sits the storefront application you wrote, pulling every piece of data it needs through API calls. How you compose the product page, what information goes where, which interactions you use — all of it is yours. We described how that connection is built in the piece on APIs and integrations.
The terms: API-first, composable, PWA
- API-first: every function of the system designed as an API before anything else. It means anything doable in the admin is doable over the API; this is the precondition for headless.
- Composable commerce: sourcing each capability (search, payment, content, loyalty) from a separate provider. It is a step beyond headless and multiplies complexity fast.
- PWA: a storefront that runs in the browser but behaves like an app. Often mentioned alongside headless but not required; the app-versus-site question starts here.
- BFF: a layer placed between storefront and APIs. It consolidates many calls and becomes unavoidable as a headless project grows.
| Item | Monolith | Headless | Whose job it becomes |
|---|---|---|---|
| Storefront change | Admin or theme | Code deploy | Moves from marketing to engineering |
| Speed optimisation | Platform provides | Team writes | Moves from vendor to team |
| Security patches | Arrive automatically | Storefront side is yours | Partly moves to you |
| Adding a channel | Limited | Easy on the same API | Advantage headless |
| Content preview | Works out of the box | Built separately | An extra work item |
What You Gain: Speed, Channels, Design Freedom
Headless promises are real, but each is conditional. Projects decided without knowing the conditions stall around month six.
The truth about the speed gain
A headless storefront does not have to be fast; it can be. The gain comes from pre-rendering pages and serving them statically, fetching only the data needed, and never shipping unused code. Under 1.5 seconds on mobile is normal for a well-built headless storefront. A badly built one can be slower than a theme-based site; three analytics libraries and surplus client-side code kill speed just as effectively. On the delivery side, your CDN setup is half of this equation.
Many channels, one catalog
A website, a mobile app, an in-store kiosk and a marketplace feed can all connect to the same commerce engine. In Turkey the real gain shows up here: when Trendyol and Hepsiburada feeds, your own site and any physical store are managed from a single catalog, stock conflicts fall. But headless is not required for that; an API-first platform is enough. Headless only enters the picture when the storefront itself also has to be distinctive.
Design and experience freedom
Configurable products, room visualisation, size selectors, made-to-order flows — experiences that are hard to build on a stock theme are the real justification for headless. In categories like furniture, rugs, jewellery and medical devices the product page is effectively an application, and a template does not fit. In a standard apparel store, by contrast, the product page is a solved problem, and writing it from scratch does not pay back in conversion.
What It Costs: Team, Time, Maintenance
The line item most often skipped in headless discussions is that the project never ends. The moment you write a storefront, a maintenance obligation is born and it does not close.
Two-year total cost
| Item | Monolith | Headless | Note |
|---|---|---|---|
| Setup time | 2-6 weeks | 3-6 months | Grows with integration count |
| Storefront build | Theme licence | Team or agency | The largest line |
| Monthly maintenance | On the platform | Ongoing developer | Never below half a person |
| Campaign change | Hours | A sprint | Affects marketing speed |
| New channel | High | Low | Headless's clear advantage |
The team you need
The minimum is this: one frontend developer, one developer covering APIs and integrations, plus access to a designer. That can be part-time but it cannot be zero. Headless projects that depend on one person are the riskiest shape, because they freeze when that person leaves. If you work with an agency, write the maintenance clause and the code handover into the contract explicitly.
What you lose
The losses rarely make the list: editing pages from the admin, built-in preview, hundreds of themes on the marketplace, the plugin ecosystem, and updates that arrive on their own. Marketing's "let's move that block up" request is half an hour of work on a monolith and a development item on headless. This is the most-overlooked and most-regretted side of the decision.
Who It Suits and Who It Does Not
The call should be made against thresholds, not instinct. The table below summarises what the field shows.
| Situation | Annual revenue | Technical team | Recommendation |
|---|---|---|---|
| Standard catalog, one channel | Up to 15m TRY | None | Stay on a monolith |
| Marketplace plus own site | 15-50m TRY | Outsourced | API-first monolith |
| Custom product configurator | Above 15m TRY | In place | Headless makes sense |
| Multi-country, multi-currency | Above 50m TRY | In place | Headless or hybrid |
| B2B and B2C, one catalog | Above 50m TRY | In place | Strong headless candidate |
Extra factors in the Turkish context
Three local items shape the decision. First, accounting and ERP: a Logo, Mikro or Netsis integration is independent of the storefront, so a headless move neither helps nor hurts it. Second, e-invoicing and GİB compliance: these sit at the back and never touch the storefront. Third, shipping: when Yurtiçi or Aras integrations change, the delivery blocks on the storefront are affected — and on headless those blocks are your responsibility. Those three show the migration is not "purely a frontend job". We covered selection mistakes in the platform-selection piece and the platform comparison in our comparison of three popular platforms.
The Middle Path: Hybrid Setups and an Agent Layer
The debate is usually framed as binary, but the third route works best in the field: leave the body as it is and detach only the page that needs it.
Partial headless
Writing one category with a product configurator as its own application while keeping the rest in the admin captures most of the gain without paying most of the cost. The homepage, category listings and blog stay in the platform, marketing keeps its freedom, and only one flow is custom-built.
Detaching agents, not the storefront
The shift of the last two years is that what connects to commerce functions is no longer only a storefront — it can be AI agents. If catalog, order and analytics functions are exposed as APIs, a stock check or a price update can be delegated to an agent. That underlines once more that the real technical precondition is being API-first; agents working inside defined permission boundaries use the same functions.
Measure speed first, argue architecture second
If the justification for headless is "our site is slow", three things should be tried first: converting images to modern formats, cleaning up third-party scripts, and fixing cache settings. There are plenty of cases where those three alone take 4 seconds below 2, at one percent of the cost of a headless project.
Making the Decision in Thirty Days
A headless decision is made with measurement, not architecture debate. The timeline below turns the debate into data.
Days 1-7: measure where you are
Write down mobile load time, the speed of your five highest-traffic pages, conversion rate and cart abandonment. No decision this week; a baseline is established. A migration without a baseline cannot answer "did it get better" afterwards.
Days 8-14: list the requests you could not meet
Collect every storefront request from the last six months that got a "we can't do that". Next to each, write why: theme limitation, missing data, or time? If at least two-thirds come from missing data and time rather than theme limits, headless will not solve your problem.
Days 15-21: apply the cheap fixes
Do the image optimisation, script cleanup and cache settings, then repeat week one's measurements. If you reach your speed target here, speed stops being a justification and the decision rests solely on needing a distinctive experience.
Days 22-30: pilot with a single page
If the answer is still headless, detach the single highest-value page — usually product detail — and build it as a pilot. Give the pilot three measures: load time, conversion and developer days. The third usually comes out at twice the estimate, and that is where the real information is.
Here is the job for tomorrow morning: write down three things you wanted to do on the storefront in the last six months and could not, and note beside each whether it was a theme limit or a time limit. If all three were time limits, what you need to change is the schedule, not the architecture. On an API-first e-commerce setup the option to write your own storefront stays open, while marketplace and ERP integrations sit in the same place either way.
Frequently Asked Questions
Is headless always faster?
No. Headless gives you the possibility of speed, not a guarantee. A poorly built headless storefront with surplus client-side code can be slower than a theme-based site. What decides speed is not the architecture but how much work the page does.
Will my SEO suffer if I go headless?
Not if it is built correctly — the speed gain usually helps. There are two risks: without server-side rendering the content cannot be crawled, and if the URL structure changes, traffic is lost because old addresses were never redirected. A redirect map deserves its own line in the migration plan.
Should a small store go headless?
Usually not. A store with a standard catalog, one sales channel and no technical team never uses the flexibility headless brings but still pays the maintenance. The same budget returns far more on advertising and content.
How long does a migration take?
With one storefront, limited integrations and an off-the-shelf commerce engine, three months is a realistic floor. Once ERP, marketplace feeds, multiple languages and B2B price lists are in play it passes six months. Estimates usually break not on the storefront but on testing the integrations.
Can the marketing team edit pages themselves?
Only if you build a separate content management layer for exactly that. Without it, every change joins the development queue. In projects that leave this layer out of the first release, it becomes the loudest complaint after month six.
Are composable commerce and headless the same thing?
No. Headless detaches only the storefront; composable also splits every back-end capability across separate providers. Composable maximises flexibility but multiplies integration and contract management; it is hard to run without a technology team of about five.
Does headless require a mobile app?
It does not. Feeding a mobile app from the same API becomes easier, but the app decision is a separate business question and depends on how often your traffic returns. In one-off purchase categories an app rarely pays back.
Agency or in-house team for the migration?
An agency speeds up the first release; in-house is what sustains maintenance. If you choose an agency, look for three clauses: full code handover, documented dependency list, and at least six months of maintenance. Without those three you are buying debt, not a project.
Can you go back from headless?
You can, but not cheaply. Your data is safe because the body did not change; what you lose is the investment in the storefront plus the traffic wobble during the move. That is exactly why starting with a pilot always beats a full migration.