Software development can qualify. Routine software work does not.

When the project seeks an advance in overall capability in the field and the team faced technological uncertainty that a competent professional could not readily resolve. That could be making a system work at a scale, speed or level of security that existing approaches did not allow. Building a product to a known specification, however large, is usually routine.

Not as a whole. A SaaS product is usually a mix of routine build and a few genuinely uncertain problems. Those problems might be a processing method, an architecture that has to meet a hard constraint, or an integration nobody has solved. We identify the uncertain parts, draw the project boundary around them and claim for those, rather than for the whole product.

Not by itself. The Government's guidelines say that using science or technology is not an advance in itself, and a framework that is new to your team is not new to the field. The work may qualify if, using it, you had to solve a problem the framework's own documentation and community could not answer.

Rarely. Fixing a defect in line with the original design is routine. It can qualify where the defect exposes a deeper technical problem that no competent professional could readily solve, for example a failure that appears only at scale and needs a new approach to resolve. The records would need to show the investigation, not just the fix.

Yes, for the uncertain parts. A mobile app is often interface work on top of established tools, which is routine. Parts that can qualify include on-device processing under tight limits, new methods of synchronising data, or sensor handling that existing libraries cannot do. We look at each feature against the same R&D test.

Contemporaneous records are best: design documents that set out the problem and the options, repository history showing the approaches tried, test results, failed prototypes and issue-tracker discussions. Developers' own explanations matter too, because we interview them. The aim is to show what was uncertain at the start, how it was tackled and what was learned.

Salaries, wages, bonuses, pension contributions, employer Class 1 National Insurance and staff training, for the time spent on qualifying R&D. Time is apportioned, so a developer who spends half their week on a qualifying project is claimed at half. Anyone whose time goes directly into the qualifying work can be included, in proportion to that time.

Only in limited cases. For periods beginning on or after 1 April 2024, contracted-out R&D and externally provided worker costs qualify only if the work is done in the UK, or the overseas exception applies. That exception needs the work to be necessary because of conditions not present in the UK. The cost and availability of workers are disregarded.

Cloud computing costs can qualify, where they are used for R&D. They were added, together with data licences, for accounting periods beginning on or after 1 April 2023. The key is the link to R&D: hosting that runs a live service for customers does not qualify, while capacity used for development and testing of the uncertain work can. We separate the two in the workings.

Yes, but you need to show the R&D inside the sprints. HMRC looks at projects, not at ceremonies. We group the work by the technical problem it addressed, which may run across many sprints, and tie the cost records to those groups. Sprint boards and tickets are useful evidence if they show the technical questions being worked on.

Usually not. Connecting systems through documented interfaces is routine. It can qualify if the integration needed new approaches because the systems were not designed to work together, and a competent professional could not readily have worked out how. The evidence has to show what the obstacle was and why established methods failed.

It is hard. Building on a platform whose purpose is to remove technical uncertainty is typically routine. A project can qualify if the team was trying to make the platform do something beyond its documented capability, and the effort went into resolving that uncertainty. We would want clear records of what the platform could not do.

Building to specification, standard web or mobile builds using familiar tools, content management setup, theming, routine upgrades and migrations, and adapting existing code for a new customer. The Government's guidelines say routine copying or adaptation is not R&D. These tasks may be skilled and time-consuming, but they are not uncertain in the R&D sense.

Usually not. Refactoring or rebuilding to improve maintainability is generally routine engineering. It could qualify where the rebuild requires a genuine technical advance, for instance moving a system to a new architecture that nobody knows how to make reliable at the scale needed. The uncertainty would have to be technical, not just effort.

Yes, where the work tackles a security problem without a known solution, such as a new detection method or a way to protect data in a setting where standard approaches fail. Configuring established security products is routine. As with all software, we need records of the problem, the approaches tried and why existing options fell short.