What actually makes a build R&D, and what's just assembly

A note before we start: this is an engineering-honesty question, not a tax one. Whether a piece of work qualifies for any R&D relief scheme is a question for your accountant, decided against the current rules at the time you claim. What follows is about something upstream of that — how we, as engineers, tell the difference between a build that's genuinely uncertain and one that's just unfamiliar to the client asking for it.

Clients describe a lot of ordinary work as "innovative." Usually they mean it's new to them, not new to engineering. A configurator that reads pricing rules from a spreadsheet and renders a quote is a well-understood pattern — building it well still takes skill, but nobody involved is genuinely unsure whether it will work. That's assembly: known components, combined competently, in an order that suits the client's specific business.

The actual test: does anyone know the answer before the code exists?

The honest dividing line isn't novelty to the client, or even novelty to the market. It's whether a competent engineer, looking at the brief, can say with real confidence how the thing will behave before it's built. If the answer is yes — even if it takes real craft to execute — you're assembling known parts. If the answer is genuinely no, and the only way to find out is to build a version, test it against reality, and see what breaks, you're in R&D territory.

This shows up less often than founders expect, and less often than "innovative" briefs suggest. Most software problems that feel novel to a business owner have been solved somewhere before, even if not in exactly this configuration. The uncertainty that actually counts is technical, not commercial — "will this integration behave correctly under real load" is a testable, mostly-known question. "Can this matching algorithm produce reliable results against data this noisy, using an approach nobody's validated for this data shape" is a different kind of question, and the answer genuinely isn't known until someone builds and tests it.

What genuine technical uncertainty tends to look like

• The first attempt is expected to fail, at least partially. If a competent build always works first-time-through with only cosmetic fixes, the underlying uncertainty was low.
• Existing documentation and prior art don't answer the question. Not "we didn't look it up" — genuinely, the combination of constraints here hasn't been solved and published anywhere findable.
• The build process itself generates the knowledge. You learn something true about whether the approach works only by trying it, not by reasoning about it in advance.
• A different, equally competent team might reasonably have taken a different technical approach, because there wasn't a settled best-practice answer to converge on.

None of this depends on how impressive the outcome looks to a non-technical audience. A slick-looking dashboard can be pure assembly. A genuinely uncertain piece of matching or optimisation logic can look, from the outside, like nothing changed at all — because the interesting part was working out whether an approach was viable, not building the interface around it.

Why the honest answer matters, separate from any tax question

We flag this distinction to clients for a reason that has nothing to do with relief schemes: it changes how a build should be scoped and priced. Assembly work can be estimated with real confidence, because the risk is mostly about effort, not outcome — you know roughly how long it takes and that it will work. Genuine R&D can't be estimated the same way, because part of what you're paying for is the answer to "does this even work," and that answer sometimes comes back no.

Pricing R&D-shaped uncertainty as if it were assembly-shaped certainty is how projects blow their timeline. The honest move is to say up front which one you're actually commissioning.

A build partner who calls everything R&D, regardless of whether the technical answer was ever really in doubt, is usually doing one of two things: inflating the perceived sophistication of ordinary work, or setting up a justification for scope and timeline slipping later. Neither is a reason to trust the label.

A worked distinction, without a client attached

Take two briefs that would both get called "AI-powered" in a sales conversation. The first: route incoming customer enquiries to the right team using a language model's classification output, with a known set of categories and a fallback to a human reviewer. That's assembly. The categories are known, the model's behaviour on this kind of task is well-documented, and a competent engineer can predict roughly how well it will perform before writing a line of code — the interesting work is in the integration and the fallback handling, not in resolving an unknown.

The second: build a system that has to reconcile conflicting, partially-missing operational data from multiple unrelated sources into a single trustworthy figure, where no existing approach has been shown to handle this particular combination of noise and contradiction reliably. Here nobody can honestly say in advance which technique will hold up, and finding out requires building candidate approaches and testing them against the actual mess of real data. That's the genuine article — not because it involves a fashionable technology, but because the outcome was authentically unknown until the work was done.

The label "AI" tracks neither category reliably. Plenty of AI integration work is assembly. Plenty of R&D-shaped uncertainty involves nothing more exotic than a data-matching problem nobody's solved for this exact shape of data before.

What we tell clients when they ask

If a brief includes a component we genuinely don't know the answer for yet, we say so, and we scope that component separately with a different risk conversation than the rest of the build. If the brief is well-understood assembly — even sophisticated, well-crafted assembly — we say that too, honestly, and price it with the confidence that comes from knowing it will work. Whether either category then qualifies for a specific relief scheme is a conversation for your accountant, working from the technical facts as we've described them, against the rules current at the time. We stay in our lane: telling you honestly which kind of uncertainty you're actually paying for.