If your e-commerce agency builds headless commerce solutions, you could be leaving thousands of pounds on the table. The headless commerce r&d tax credit is a genuine relief that many agency founders overlook, simply because they don't realise their day-to-day technical work qualifies.
HMRC's R&D tax relief scheme is not just for pharmaceutical companies or aerospace engineers. It applies to any business that undertakes projects seeking to resolve scientific or technological uncertainty. For e-commerce agencies building headless architectures, that uncertainty shows up more often than you might think.
This post covers what qualifies, what doesn't, and how to structure your claim so HMRC doesn't push back.
What Is Headless Commerce, Really?
Headless commerce separates the front-end presentation layer from the back-end commerce functionality. Instead of a monolithic platform like a standard Shopify or Magento setup, the front-end communicates with the back-end via APIs.
This gives agencies and their clients freedom. You can build a React front-end that pulls product data, cart logic, and checkout flows from a headless CMS or commerce engine like CommerceTools, BigCommerce, or a custom-built solution.
The result is faster page loads, better omnichannel experiences, and the ability to update the front-end without touching the back-end. But it also introduces genuine technical challenges that HMRC recognises as qualifying R&D activity.
Does Building a Headless Commerce Site Qualify for R&D?
The short answer: it depends on what you're doing. Simply installing a headless CMS and connecting it to a standard Shopify storefront does not qualify. That's routine integration work, not R&D.
But if you're solving problems that no standard documentation or off-the-shelf solution can address, you're likely in qualifying territory. HMRC looks for projects where you had to overcome technical uncertainty by designing new processes, adapting existing technology in a novel way, or creating bespoke solutions to problems that aren't widely documented.
Let's look at some real scenarios.
Scenario 1: Custom API Orchestration Layer
Your client wants a headless setup that pulls inventory from three separate warehouses, each using a different ERP system. The standard API connectors don't handle real-time inventory reconciliation across disparate systems. You build a custom orchestration layer that normalises data formats, handles latency, and resolves conflicts when two systems report different stock levels.
This qualifies. You faced technological uncertainty around data normalisation, latency management, and conflict resolution. No off-the-shelf solution existed. You designed a novel approach.
Scenario 2: Optimising Core Web Vitals on a Headless Site
Your headless build passes Lighthouse audits but still fails Google's Core Web Vitals on mobile. You spend weeks optimising server-side rendering, implementing predictive prefetching, and building a custom caching layer that respects session data. Standard caching plugins don't work because your architecture is decoupled.
This qualifies. The uncertainty was around achieving specific performance thresholds in a decoupled environment where standard solutions failed. You developed a novel caching and rendering strategy.
Scenario 3: Integrating a Headless CMS with a Legacy ERP
Your client runs a 15-year-old ERP system that was never designed for headless commerce. You build a middleware layer that translates between modern GraphQL APIs and the ERP's proprietary protocol, handling data transformation, error handling, and idempotency. The ERP vendor offers no support for this integration.
This qualifies. You resolved technological uncertainty around protocol translation and data integrity in a constrained environment.
Scenario 4: Standard Headless Setup with No Novelty
You install a headless CMS, connect it to a standard payment gateway, and build a React front-end using a well-documented starter kit. Everything works as documented. No custom solutions were needed.
This does not qualify. There was no technological uncertainty. You followed established patterns.
What HMRC Looks For in Headless Commerce R&D Claims
HMRC's R&D teams have become more sophisticated. They know the difference between genuine technical innovation and routine development. For a headless commerce r&d tax credit claim to succeed, you need to demonstrate three things:
- Technological uncertainty: You didn't know at the start whether the solution was achievable within the constraints. Standard approaches didn't work.
- Systematic resolution: You didn't guess. You tested hypotheses, iterated, and documented what you tried.
- Competent professional: A skilled developer in your field would also have been uncertain. If any competent developer could have solved it with standard tools, it's not R&D.
This last point trips up many agency founders. You might think "any good developer could have figured that out." But if the solution required novel thinking, custom code, and genuine problem-solving, it qualifies. HMRC's test is whether the outcome was not readily deducible by a competent professional working in the field.
What Doesn't Qualify
Let's be clear about what HMRC will reject. Routine work, even if technically complex, does not qualify if it follows established patterns. Examples include:
- Installing and configuring a headless CMS like Contentful or Strapi using their standard documentation
- Building a standard e-commerce front-end in React or Vue using established component libraries
- Integrating standard payment gateways like Stripe or PayPal using their SDKs
- Migrating from one monolithic platform to another without novel technical challenges
- Performance optimisation that uses standard caching plugins or CDN configurations
HMRC also excludes work that is purely commercial or aesthetic. If you're making a site look better or converting better, that's marketing, not R&D. The qualifying work must be technological in nature.