App development R&D credits: a UK founder guide

App development R&D credits are worth real money to the right company, and they are a slow-motion accident for the wrong one. The relief exists to fund genuine technological progress, not to subsidise the cost of building software. HMRC knows the difference. A lot of the advisers who cold-call founders promising a percentage of a claim do not, or pretend not to.

We build apps for a living, so we sit in the middle of this. Clients ask us to write technical narratives, or to confirm that a sprint was “innovative”, and the honest answer is usually more nuanced than either side wants. This guide sets out how the relief works in 2026, which parts of a typical app build stand a real chance of qualifying, and where founders get themselves into trouble. It is written to help you have a useful conversation with a specialist adviser, not to replace one.

What are app development R&D credits, and who gets them?

App development R&D credits are corporation tax relief on the portion of your build that seeks an advance in science or technology by resolving technological uncertainty. The relief attaches to the uncertainty, not to the product. Two companies can ship an identical app and only one of them has a claim, because only one of them had to solve something that a competent professional could not readily work out.

That definition comes from the government guidelines on the meaning of research and development for tax purposes, and every HMRC enquiry eventually comes back to it. The practical test is not “was this hard for my team”. It is “was this hard for a competent professional in the field, working with publicly available knowledge”. Those are very different bars, and the gap between them is where most rejected claims live.

The two schemes that exist in 2026

For accounting periods beginning on or after 1 April 2024, the old SME and RDEC schemes were replaced by two routes, set out in HMRC’s guidance on the merged scheme and enhanced R&D intensive support.

The intensity threshold for ERIS was reduced from 40% to 30% for accounting periods beginning on or after 1 April 2024, which brought a meaningful number of pre-revenue product companies back into scope.

What the money is actually worth

Under the merged scheme, the 20% credit is taxable. A company paying the 25% main rate of corporation tax therefore keeps about 15p of every qualifying pound. A company on the 19% small profits rate keeps a little over 16p. Under ERIS, the 86% additional deduction takes qualifying spend to 186% of cost, and surrendering that loss at 14.5% produces roughly 27p per qualifying pound.

Hold those two numbers in your head, because they change how you should think about the whole exercise. If your genuinely qualifying spend is £40,000, a merged scheme claim is worth around £6,000. That is a useful contribution to a runway. It is not a funding round, and it is nowhere near enough to justify distorting your build plan to chase it.

Which parts of an app build actually qualify?

Very little of a normal app is R&D, and the parts that are tend to be invisible from the outside. Users see screens. HMRC cares about the layer underneath, where a technological problem had no published answer and your team had to find one by systematic investigation.

Here is the split we see most often across real projects.

Rarely qualifying. Interface design and layout work. Standard authentication, including social login. Wiring up a documented payments API. CRUD screens over a database. Push notification setup. App store submission. Analytics instrumentation. Content management. Accessibility fixes. Performance tuning that follows well-known techniques. Anything you would describe by naming the library you used.

Sometimes qualifying. Offline-first synchronisation with conflict resolution where no off-the-shelf approach fits your data model. Real-time collaboration under adverse network conditions. Running machine learning inference on device inside strict memory and battery budgets. Integrating with a legacy or undocumented system where the interface behaviour has to be established experimentally. Achieving a performance threshold that published approaches do not reach for your data volumes.

The tell. If your engineers can point to the moment where they did not know whether the approach would work, ran experiments, and some of those experiments failed, you are in R&D territory. If the work was well understood from the start and the only question was how many days it would take, you are not. Uncertainty about effort is not technological uncertainty. That single distinction disqualifies more claims than anything else.

This is also why the “we used AI, so it must be R&D” argument does not survive contact with an inspector. Calling a foundation model API is integration work. Building a retrieval pipeline out of documented components is integration work. If you want to understand where the genuine difficulty in AI products actually sits, we wrote about the AI mistakes UK founders keep making and it maps closely onto what does and does not qualify here.

The costs you can include

Qualifying expenditure is narrower than “money we spent on the app”. The main categories are staffing costs for people directly and actively engaged in the qualifying project, a proportion of supervisory and managerial time, software and cloud costs consumed by the R&D, consumables, and payments for certain externally provided workers or contracted-out work.

Two changes matter a lot for app companies. First, for accounting periods beginning on or after 1 April 2024, contracted-out R&D and externally provided workers generally have to be undertaken in the UK to qualify, with narrow exceptions where the conditions genuinely cannot be replicated here. Cost saving is explicitly not one of those exceptions. If your build sits with an offshore team, this needs checking before you assume anything. It also changes the arithmetic in our comparison of UK versus India app development costs, where the headline day rate is only part of the picture.

Second, cloud and data costs are claimable where they are consumed by the R&D itself. For a team burning GPU hours on model experiments, that can be a material line. For a team running a standard production backend, it usually is not.

Apportionment is where honest claims are won

Almost nobody has a person who spends 100% of their time on qualifying R&D. You have an engineer who spent eleven days in March on the synchronisation problem and the rest of the quarter on screens and bug fixes. The claim is for the eleven days.

The only reliable way to defend that number is to have recorded it at the time. Ticket-level time tracking, or a project board where the R&D work sits in its own epic with dated tickets, is worth more in an enquiry than a beautifully written narrative produced eighteen months later. If you are going to claim, decide that at the start of the project and instrument for it. Reconstructing apportionment from memory is the second most common reason claims collapse.

The paperwork, and the deadlines that catch people out

HMRC tightened the administration of R&D claims considerably, and the compliance steps are now the part most likely to lose you the money outright.

1. Claim notification. New claimants, and companies that have not claimed recently, generally have to submit a claim notification within six months of the end of the accounting period they want to claim for. This is a pre-notification, not the claim. Miss it and the claim is invalid no matter how good the underlying R&D was.
2. Additional information form. Every claim requires an additional information form submitted before or on the same day as the company tax return. It names the qualifying projects, describes the advance sought and the uncertainties resolved, splits the costs, and names the senior officer responsible and any agent who advised. If the form is missing, HMRC removes the claim from the return.
3. The claim itself. Made in the company tax return, normally within two years of the end of the accounting period.
4. The narrative. Not a marketing document. It should name the field, state what was not readily deducible by a competent professional, describe the systematic work done to resolve it, and be honest about what failed.

The current position on all of this is set out in HMRC’s guidance on working out your R&D tax relief. Rates and thresholds do move at fiscal events, so confirm the numbers against gov.uk for your specific accounting period rather than relying on any blog post, including this one.

A worked example, with the boring parts included

Numbers make this concrete, so here is a composite of projects we have actually worked on. A fifteen-person logistics software company, loss-making, building a driver app. Twelve-month accounting period. Total company expenditure of £1.4m, of which £820,000 is on the product team.

The build has four workstreams. The driver interface and route display, which is well-understood work. The integration with two customer warehouse systems, one of which is documented and one of which is a black box that returns inconsistent responses under load. An offline mode where a driver in a signal dead zone continues to record deliveries and the device reconciles a full day of changes on reconnection, with conflicts resolved without a human deciding. And the usual scaffolding: authentication, analytics, app store submission, admin panel.

Only two of those four are candidates. The undocumented warehouse integration qualifies to the extent that the team had to establish the system’s behaviour experimentally, because no competent professional could deduce it from available information. The offline reconciliation qualifies because the team tried three approaches, two of which produced data loss under specific timing conditions, before arriving at one that held. The interface and the scaffolding do not qualify at all, and including them is exactly what turns a good claim into an enquiry.

The time records show 340 engineer days across the two qualifying workstreams, at a fully loaded cost of about £520 a day, plus £11,000 of cloud spend on the load testing environment used to reproduce the failure conditions. That is roughly £188,000 of qualifying expenditure against £1.4m of total expenditure. The intensity ratio is about 13%, well under the 30% ERIS threshold, so this company claims under the merged scheme: 20% of £188,000 is £37,600 as a taxable credit, worth about £28,200 after corporation tax at the main rate.

Two things are worth noticing. The claim is meaningful but it is not transformative, and it represents well under a quarter of the product spend. And the difference between claiming £188,000 and claiming the full £820,000 is not a bigger cheque, it is the difference between a claim that survives scrutiny and one that gets withdrawn with penalties attached.

What an HMRC enquiry actually feels like

Founders imagine a tribunal. In practice an enquiry opens with a letter asking for more detail on specific projects named in your additional information form, and it lands anywhere from a few months to well over a year after you got the money. By then the engineer who did the work may have left.

The questions are consistent. What was the advance in the field, not in your product. Who was the competent professional, and what were their qualifications. What was not readily deducible from publicly available knowledge, and how do you know. What systematic work did you do, and what were the results, including the failures. How did you arrive at the apportionment of each person’s time.

The answers that work are specific and unglamorous: dated tickets, commit history, a design document that lists three candidate approaches and why two were abandoned, a named engineer with relevant background who can talk about the problem for twenty minutes without notes. The answers that fail are adjectives. “Innovative”, “cutting edge”, and “bespoke” mean nothing to an inspector, and their presence in a narrative is usually a signal that nobody technical wrote it.

Repayment where a claim is disallowed comes with interest, and penalties follow if HMRC concludes the error was careless rather than innocent. Since the company signs the return, “my adviser told me it qualified” is not a defence that ends the matter, though it may affect how the behaviour is categorised.

How to avoid the bad version of this

The R&D relief market attracted a lot of contingent-fee advisers who took a percentage of whatever they could get through, and HMRC responded with a significant increase in compliance activity. Founders are the ones left holding the liability when a claim is withdrawn, because the company signs the return, not the adviser.

Signals that should make you slow down:

• An adviser who tells you what qualifies before speaking to your engineers.
• A promise that “all software development qualifies”, or that HMRC “rarely checks”.
• A fee structure that only pays out on the size of the claim, with no engagement on defending it.
• A narrative written by someone who cannot explain your architecture back to you.
• Pressure to include the interface work, the project management, and the app store submission because “it is all one project”.

The good version looks slower and duller. An adviser who works with a real R&D specialty, talks directly to the people who wrote the code, tells you which parts to exclude, and prices the work rather than the outcome. Ask for their enquiry record. Ask what proportion of claims they have had to defend, and how those ended.

How this should change your build plan, if at all

Honestly, in most cases it should not. The relief is worth roughly 15p to 27p per qualifying pound, and qualifying spend is usually a minority of an app budget. Redesigning a product to manufacture R&D is a bad trade every time.

What it should change is your record keeping. If you know at the outset that one workstream is genuinely uncertain, put it in its own epic, keep the experiment log, note the approaches that failed, and track time against it. That costs almost nothing during the project and turns a shaky claim into a defensible one.

It should also change how you scope. Being clear about which parts of a build are novel and which are commodity is good practice regardless of tax, and it is the same discipline that keeps budgets honest. Our checklist for scoping an app project is a decent starting point, and if you want the wider cost picture first, what app development actually costs in the UK in 2026 sets the baseline that R&D relief is a small adjustment to.

What to do next

If you are mid-build and wondering whether any of it counts, the sequence is simple. Get your engineers to write down, in plain language, the two or three problems where they genuinely did not know if the approach would work. If that list is empty, you probably do not have a claim and you have saved yourself a great deal of trouble. If it is not empty, take it to a specialist adviser with a real technical background, before your accounting period ends, so the claim notification deadline stays open.

And if you are still at the planning stage, the most valuable thing you can do is separate the novel from the routine before a line of code is written. That is a conversation we have with most clients in the first fortnight anyway. If it would help to have it now, send us a project brief and we will tell you honestly which parts of what you are describing look genuinely uncertain and which parts are a solved problem with a library attached.

Sources: HMRC, R&D tax relief: the merged scheme and enhanced R&D intensive support, HMRC, Work out your Research and Development tax relief.