What HMRC Means by an Advance in Science or Technology for Platform Engineering
Platform engineering occupies an uncomfortable space for R&D tax claims. The work is technically demanding, the engineers are highly skilled, and the outcomes genuinely matter to the business. But "technically demanding" and "qualifying R&D" are not the same thing. The BIS Guidelines on the Meaning of R&D for Tax Purposes require an advance in science or technology overall, not just within the company. HMRC's CIRD81900 guidance is explicit: if a competent software professional could resolve the uncertainty from existing public knowledge, the work does not qualify.
For platform engineering this means the bar is higher than it initially appears. Configuring Kubernetes, deploying Terraform, setting up Datadog, and tuning Postgres are all genuine engineering work that requires skill and knowledge, but they use documented tools in documented ways. The qualifying work is in the layer above: where the platform team built something that the off-the-shelf tools could not do, or encountered technical uncertainty about distributed-systems behaviour at a scale or in a configuration not documented in existing literature.
Platform engineering claims are typically filed as part of a broader SaaS R&D claim rather than as a standalone filing. See our SaaS R&D tax credits guide for the wider context. The cost categories and scheme rules are identical.
What Qualifies in SaaS Platform Engineering
Novel Multi-Tenancy and Isolation Architectures
Multi-tenant isolation is one of the strongest qualifying areas in platform engineering. Qualifying examples include: developing row-level security or dynamic schema-per-tenant architectures at a scale where existing frameworks introduced unacceptable performance or consistency trade-offs; engineering novel workload isolation mechanisms (process, container, or hardware-level) where standard OS and container boundaries were insufficient for the security or performance requirements; and building tenant-aware sharding, routing, or rate-limiting systems where off-the-shelf API gateways and load balancers could not deliver the required semantics.
Observability and Telemetry at Scale
Observability systems that pushed beyond documented approaches qualify. Examples include: building novel sampling, compression, or fingerprinting systems for distributed traces or metrics at cardinalities or volumes that standard APM stacks (Datadog, New Relic, Grafana Tempo) could not handle within the company's cost envelope; developing novel anomaly-detection or root-cause-analysis algorithms over high-cardinality telemetry where published approaches underperformed; and engineering real-time profiling systems with acceptable overhead for production use where standard profilers introduced unacceptable latency.
Developer Platform and Internal Tooling
Internal developer platforms (IDPs) qualify where they required genuine technical advance. Qualifying examples include: building novel code-generation or scaffolding systems with capabilities not available in existing tools; engineering novel hot-reload, live-replay, or deterministic-replay systems for distributed services where existing approaches were technically insufficient; developing novel test environment provisioning systems that achieved sub-minute spin-up of complex multi-service environments at a reliability level not achievable with standard approaches; and building novel CI/CD pipeline orchestration with custom scheduling, dependency-resolution, or test-selection logic that went beyond documented CI system capabilities.
Security Engineering and Cryptography
Security engineering qualifies at the technical frontier. Qualifying examples include: implementing threshold signature schemes, multi-party computation, or zero-knowledge proof systems for key management or data verification; engineering novel sandboxing or process isolation for multi-tenant code execution where existing container and VM approaches were insufficient; developing novel authentication architectures for complex multi-party systems; and building novel intrusion-detection or anomaly-detection systems using ML models trained on proprietary telemetry where documented security tooling was inadequate.
Distributed Systems and Consensus
Distributed systems work at the frontier of computer science qualifies. Examples include: implementing novel consensus or leader-election protocols for high-availability systems where existing algorithms (Raft, Paxos, ZAB) required substantial modification to meet latency or partition-tolerance constraints; developing novel conflict-resolution strategies for multi-master or eventually-consistent data stores; and engineering novel clock-synchronisation or causality-tracking systems for globally distributed deployments where vector clocks or hybrid logical clocks were insufficient.
What Does NOT Qualify: Platform Engineering Anti-Patterns
These are the most common non-qualifying items in platform engineering claims:
- Standard Kubernetes and Helm configuration. Deploying services to Kubernetes, writing Helm charts, and configuring ingress controllers, storage classes, and resource limits are skilled operational work but are documented extensively and do not involve scientific or technological advance.
- Terraform and infrastructure-as-code provisioning. Writing Terraform modules to provision cloud resources, even complex ones, is not qualifying R&D where the patterns used are documented in provider documentation and community modules.
- Standard CI/CD pipeline setup. Configuring GitHub Actions, CircleCI, or Jenkins pipelines using documented patterns and standard integrations is not qualifying R&D.
- Database performance tuning using known techniques. Adding indexes, adjusting query plans, and tuning Postgres or MySQL configuration parameters using documented guidance is not qualifying R&D.
- Monitoring and alerting setup using off-the-shelf tools. Configuring Datadog dashboards, PagerDuty routing, and alert thresholds using tool documentation is operational work, not an advance in science.
- Cost optimisation by switching instance types or purchasing reserved capacity. These are commercial decisions that require engineering judgement but do not resolve technical uncertainty in the BIS Guidelines sense.
Qualifying Costs for Platform Engineering Teams
Staffing costs. Platform engineers, site reliability engineers (SREs), and security engineers working directly on qualifying R&D projects, apportioned by time. The apportionment must be project-level, not a blanket percentage of platform team time. Engineers spending 30% of their time on novel distributed-systems work and 70% on operational BAU contribute 30% of their employment cost.
Cloud and infrastructure costs. Cloud compute, storage, and data costs used directly in R&D development and testing environments qualify from April 2023. Production infrastructure costs do not. For platform engineering, the clearest qualifying line items are development cluster compute, load testing environments, and ML training runs for qualifying models. See our qualifying expenditure guide for the full cloud-cost rules.
Software licences. Licences for tools used directly in qualifying R&D, apportioned to R&D use. If a security team uses a static analysis tool 40% for qualifying R&D and 60% for production security scanning, 40% of the licence cost qualifies.
Subcontractors. UK-based security specialists, distributed-systems consultants, or cryptography researchers engaged on qualifying projects are claimable at 65% for unconnected parties. The UK-only rule applies. See the glossary for definitions of key scheme terms.
ERIS for SaaS Platform Teams
Most SaaS companies with dedicated platform engineering teams are profitable or approaching profitability by the time they have a team of that size. ERIS, which requires the company to be loss-making and have R&D intensity above 30%, applies to fewer SaaS businesses at Series B or later. For early-stage SaaS companies where the entire team is focused on platform and infrastructure work before commercial launch, ERIS is relevant and material. See the merged scheme guide for the full ERIS rules.
Worked Example: A SaaS Platform Team Claim
A UK B2B SaaS company (SIC 62010) has a dedicated platform engineering team of 10 engineers and total qualifying R&D spend across all engineering of £1.4m. Of that, a specialist review attributes £420,000 specifically to qualifying platform engineering projects: a novel multi-tenant query routing system (£180,000 of engineer time), a bespoke high-cardinality observability pipeline (£140,000), and a novel zero-trust internal service mesh (£100,000).
The company is profitable. Under the merged scheme at 20%, the platform-specific credit attributable to these projects is £420,000 x 20% = £84,000, which offsets corporation tax. The remaining £980,000 of product R&D generates a further £196,000 credit. Total claim: £280,000.
HMRC Enquiry Risks for Platform Engineering Claims
The two most common enquiry triggers in platform engineering claims are: over-broad time apportionments that include operational BAU work alongside qualifying R&D without clear project separation; and cloud-cost claims that include production infrastructure rather than development and test environments only. A second risk is the description of qualifying work: HMRC's officers are trained to identify generic narratives ("improved scalability", "enhanced security") that do not specify the technical uncertainty or the advance sought. A strong claim for a platform engineering project will name the specific distributed-systems problem, explain why existing approaches were insufficient, and describe the experimental approach taken.
What to Do Next
If your platform engineering team has worked on genuinely novel distributed systems, observability, security, or tooling challenges, those projects are worth reviewing for R&D eligibility. They are often the highest-quality work in a SaaS company's claim but the most frequently missed. The eligibility checker takes five minutes. For a full review, request a free assessment. Related guides: SaaS R&D tax credits overview, EdTech R&D tax credits, merged scheme explained, and qualifying expenditure categories.