Web development
Headless Shopify
Headless gets sold as the answer to everything slow. It is not. But there is a handful of situations where it genuinely is the right call, and they are worth being able to recognise.
- Same-day reply
- Fixed price
- No lock-in
- Hydrogen and Next.js
- Storefront API
- Honest assessment first
- Full control of the frontend
Service
Headless Shopify
When headless makes sense
- The store is one part of a larger site where the rest runs on something else entirely.
- You need a frontend that does not look like a webshop — configurators, calculators, heavy product views.
- Content comes from a CMS that matters more than the product catalogue.
- There are several storefronts across markets or brands on top of one catalogue.
When it does not
If the reason is speed alone, start by cleaning up the theme and the apps. I have seen stores go from 2.8 to 1.1 seconds on LCP without touching the architecture.
Headless also moves a set of responsibilities from Shopify to you: rendering, caching, deploys, error monitoring. If nobody maintains it after launch, it costs more than you saved.
How I build it
Hydrogen if the store is the core and you want to stay close to Shopify's own tooling. Next.js if the store is part of something larger, or if a Next.js codebase already exists.
In both cases I use the Storefront API and leave checkout with Shopify. There is no reason to build your own checkout, and several good reasons not to.
Deliverables
What you get
Concrete deliverables, not a report of recommendations someone else has to find time for.
- An honest assessment first
Whether headless is even the answer to your problem. In about half the conversations I have, it is not.
- A frontend in Hydrogen or Next.js
Depending on whether the store is the core or part of something larger.
- Checkout stays with Shopify
There is no reason to build your own checkout and several good reasons not to.
- A CMS if content needs editing
The theme editor goes away with headless. That cost belongs in the calculation from the start.
Process
How it works
Four steps. You know what happens when, and you can stop after any of them.
- 01
Get on a call
Twenty minutes where you explain what is going wrong and I ask the questions that decide the scope. I say so immediately if the job is not a fit.
- 02
I read the code
Before quoting I spend half a day to a day reading the project. You get an honest assessment of the state of things, including when it is worse than you hoped.
- 03
Fixed price and scope
You get a written quote with what is included, what is not, and when it is done. Not a three-month range you cannot plan around.
- 04
Delivery in your workflow
I work in your git repository and open pull requests that can be reviewed. Everything I touch is documented, so knowledge does not walk out the door with me.
Who does the work
I am the person you will be working with
My name is Mikkel and I have been building for the web since 2010. There is no project manager in between, and you will not get a junior on the job because the senior was busy. What you agree is what gets built, and I am the one building it.
Day to day I am a partner at Bigum&Co, and I have worked on more than 400 projects across ecommerce, pharma, construction and the public sector. Call or write — I usually reply the same day, and I will say straight away if the job is not a fit.
- Experience
- 16 yrs
- Projects
- 400+
- Rating
- 5.0
- Reply time
- Same day
In depth
Headless Shopify
When headless is the answer, and when it is not
Headless gets sold as the answer to everything slow, and it is not. But there is a handful of situations where it genuinely is the right call, and they are worth being able to tell apart.
It makes sense when the store is one part of a larger site where the rest runs on something else entirely. When you need a frontend that does not look like a webshop — configurators, calculators, heavy product views. When content comes from a CMS that matters more than the product catalogue. Or when there are several storefronts across markets or brands on top of one catalogue.
It does not make sense if the reason is speed alone. I have seen stores go from 2.8 to 1.1 seconds on LCP by cleaning up theme and apps, without touching the architecture. That is a week's work against a project of several months.
And there is a running cost rarely mentioned: headless moves a set of responsibilities from Shopify to you. Rendering, caching, deploys, error monitoring. If nobody maintains it after launch, it costs more than you saved.
What you lose and what you gain
You lose the theme editor. It sounds like a detail and it is not — it is where marketing can today move a section up or down without asking anyone. If that still has to be possible, a CMS is needed, and that is a separate cost in both licence and setup.
You also lose a number of apps. Every app that works by injecting something into the theme stops working. Apps operating in the backend on orders, inventory and customers keep running without trouble. It is one of the first things I map, because the list often contains at least one app nobody can do without.
In return you get full control of the frontend. No limits from what a theme can do, no scripts you did not ask for, and the ability to build exactly the experience the product needs. For some stores that is decisive. For most it is not.
Reviews
What people say about me
Mikkel Tschentscher is my lifeline when something is urgent and nobody else can work it out.
Torben Wiese(translated from Danish) Mikkel is a man after my own heart. Executes at lightning speed, has an eye for detail and is always there when you need him. It does not get better than that.
Tini Owild(translated from Danish) He is simply a pro. Highly competent and precise, brings good input, and is a huge support.
Carsten Johan Thessen(translated from Danish)
Services
Why me
- 16 years of experience
I have built for the web since 2010 and seen most of the ways a project can come off the rails. It makes the estimates more honest.
- 400+ projects
Across ecommerce, pharma, construction and the public sector. Chances are I have seen something close to your job before.
- You talk to the person coding
No project manager in between, and no junior on the job because the senior was busy. What you agree is what gets built.
Brands I have worked with
A selection. Some freelance, some through agencies, some across several years.
Questions
Frequently asked questions
- Do we lose Shopify's theme editor?
- Yes, it goes away. That is why I usually put a CMS in place if content needs to be editable without a developer. It is a cost that belongs in the calculation from the start.
- Do our apps still work?
- Some do, many do not. Apps that inject something into the theme stop working. Apps that operate in the backend on orders and inventory keep running. It is one of the first things I map out.
- Can we go back?
- Yes, the product data still lives in Shopify. But going either way is a project, so the decision should rest on solid grounds rather than a hunch.
- Can we go back afterwards?
- Yes, the product data still lives in Shopify. But going either way is a project, so the decision should rest on solid grounds rather than a hunch.
- What does it cost to run?
- Hosting for the frontend, possibly a CMS, and the time it takes to maintain. That last one is most often forgotten, and it is larger than the first two combined.
- Hydrogen or Next.js?
- Hydrogen if the store is the core and you want to stay close to Shopify's own tooling. Next.js if the store is part of something larger, or if there is already a Next.js codebase in-house.