How long does a headless build take?

For a catalog under about 10,000 SKUs with a conventional checkout, plan on three to four months from kickoff to launch. Larger catalogs, B2B pricing rules, ERP integration or multi-currency push that out. The honest variable is rarely the storefront. It is the data — how clean your product records are, whether pricing lives somewhere we can reach programmatically, and how many integrations have to keep working on launch day. We front-load that assessment so the number we give you in week two is the number you get.

Will we lose search traffic when we migrate?

Not if the redirect map is built properly, and this is where most migrations go wrong. We map every indexed URL before a line of storefront code is written, then verify the map against live crawl data rather than against the old sitemap, which is usually incomplete. We also run the redirect check in both trailing-slash forms, because a rule written one way and a backlink written the other way produces a hard 404 that nobody notices for months. We have found that exact failure on sites we did not build.

Do we still need a platform if we go headless?

You need something to hold the cart, run checkout, process payments and store customers and orders. Headless changes where the storefront lives, not whether commerce logic exists. That backend can be BigCommerce or Shopify in headless mode, or it can be Throttle, the commerce platform we build and run ourselves. Which one is right depends on your payment requirements, your B2B rules and how much of the checkout you need to control.

What happens if we want to leave you later?

You get the repository, the infrastructure accounts and the documentation, because they were yours the whole time. We build in your GitHub organization on your Vercel or Cloudflare account, not in a proprietary wrapper you have to buy your way out of. Every build ships with a README that onboards a developer who has never seen the project. That is the standard we hold internally, and it is the same reason handover is uneventful.

Is headless faster than a themed store?

Usually, but not automatically, and anyone promising a Lighthouse score before seeing your catalog is guessing. A headless storefront removes the app-script pileup that slows most themed stores, and server components let us send far less JavaScript to the browser. But a headless build with unoptimized images and a chatty API layer can be slower than a well-tuned theme. The gain comes from controlling the render path, not from the architecture label.

Headless Commerce Development

Headless Commerce,
Built to Last

Storefronts on Next.js for merchants who have outgrown
what a hosted platform will let them do.

Schedule Your Call

Most agencies sell headless as an upgrade. It isn’t. It is a trade: you give up the convenience of a themed platform and you get back control over every part of the buying experience. That trade is worth making for some merchants and a waste of money for others.

We have shipped both. We have been building on BigCommerce since 2010, we build on Shopify, and we run four headless storefronts in production on our own commerce platform. That range is the reason we can tell you which side of the line you fall on before you spend anything.

When headless is the right call

Headless earns its cost when the platform itself has become the constraint. In practice that shows up as one of these:

Your catalog has outgrown the admin. Tens of thousands of SKUs, deep category nesting, or product data that lives in an ERP and has to stay in sync. Themed platforms slow down here in ways that are hard to design around.
Your pricing isn’t retail pricing. Customer-specific price lists, quantity breaks, quote-to-order, net terms, tax exemption. B2B rules are where hosted checkouts run out of room first.
You need the checkout to do something it won’t do. Custom fulfillment logic, unusual payment flows, a field the platform doesn’t expose.
App sprawl is now the performance problem. When eleven scripts load before your product image does, and removing any one of them breaks something, the theme is no longer the thing you’re optimizing.
The storefront is a product, not a brochure. Configurators, real-time availability, account portals — interfaces that need to behave like software.

When it isn’t

We turn this work down more often than we take it. Headless is the wrong call when:

Your store converts fine and the complaint is aesthetic. A theme rebuild costs a fraction and gets you there.
You have no in-house technical contact and no budget for ongoing support. Headless moves maintenance from the platform to you.
Your catalog is a few hundred SKUs with standard pricing. You will spend six figures to arrive where a well-built theme already is.
The real problem is traffic or merchandising. Re-architecting the storefront does not fix a demand problem, and it delays fixing it.

If that is your situation we will say so on the first call. It costs us a project and saves you a year.

What we’ve shipped

Four headless storefronts in production, each with a different reason for going headless.

MEPSelect — HVAC equipment supply

A B2B distributor catalog where the buyer is a contractor specifying equipment, not a shopper browsing. The work was in making a technical catalog searchable by people who know exactly what they need and have a part number in hand.

Stockard Tool — professional cutting tools

The largest catalog of the four, in the thousands of pages. Cutting tools are specified by dimension and material, which means faceted navigation is the product, not a feature bolted onto it.

RV Gear Pro — RV parts and camping gear

We originally built RV Gear Pro on BigCommerce, where it hit its sales goal in two months. The headless rebuild added a real account area: order history scoped to the buyer, saved addresses and payment methods, subscriptions, and reorder by whole order or single line item.

OffroadGearPro — ATV and UTV parts

Fitment-driven shopping, where the question is always “does this fit my machine” before it is anything else.

See the full portfolio

How we build

The stack is deliberate, and every piece of it is replaceable. That matters more than the specific names.

Next.js 16 with the App Router and React Server Components. Most of the page renders on the server, so the browser downloads a fraction of the JavaScript a themed store ships.
Throttle for cart, checkout, customers, orders and subscriptions — the commerce platform we build and run ourselves. When the checkout needs to do something unusual, we change the checkout rather than working around it.
Server-side pricing. The cart total is computed on the server every time. A price cannot be tampered with from the browser, which is a category of bug that quietly affects a lot of custom storefronts.
Clerk for authentication, behind an interface we own, so it can be swapped without touching the rest of the application.
Tailwind CSS and shadcn/ui for the interface layer, so design changes stay cheap after launch.
Cloudflare or Vercel at the edge.

Every build ships with webhook signatures verified against the raw request body, UUID validation at each dynamic route boundary, and CSP, HSTS and X-Frame-Options set through composed middleware. Accessibility is not a retrofit: skip-to-content, focus traps, ARIA labelling and 44-pixel touch targets are in the component library.

Migrating without losing your search traffic

This is the part of a replatform that goes wrong most often, and it is invisible until the traffic report arrives six weeks later.

We map every indexed URL before writing storefront code, and we verify that map against live crawl data rather than the old sitemap — sitemaps are routinely incomplete, and the URLs missing from them are usually the ones with links pointing at them. We then test the redirect map in both trailing-slash forms, because a rule written one way and an inbound link written the other produces a hard 404 that no one catches.

We know that failure mode well because we find it on sites we did not build, including our own. It is the difference between a migration that holds its rankings and one that spends a year recovering.

After launch

Headless moves maintenance from the platform to you, which is the real cost nobody quotes. We stay on:

Ongoing development — new features, seasonal work, whatever the roadmap holds.
Performance and monitoring — Core Web Vitals, error tracking, uptime.
Dependency upgrades — framework and SDK versions, before they become a forced migration.
Marketing support — SEO, email, paid, and the analytics to tell whether any of it is working.

You own the repository, the infrastructure accounts and the documentation from the first commit. They are in your GitHub organization, on your hosting account. Handover, whenever it happens, is uneventful by design.

Start with the assessment, not the build

The first conversation is about whether you should do this at all. If the answer is yes, you get a scoped plan with a real number. If it’s no, you get the reasoning and a cheaper recommendation.