Research-Driven Development

Most software projects start with assumptions. What the user needs, which architecture fits, how the data should flow. When those assumptions are right, everything goes smoothly. When they're wrong, you find out in production, months late and over budget.

Research-driven development is how we avoid that. We test assumptions before we commit to them.

The problem with building on assumptions

Standard development treats requirements as given. Someone writes a spec, engineers build to it, and the team discovers whether the spec was right after the thing ships.

This works when the problem is well-understood. A standard API, a typical e-commerce site, a CRUD app. The patterns are known. You don't need to question them.

But most of the projects we take on aren't like that. They involve new domains, unfamiliar constraints, or problems where the right approach isn't obvious. In those cases, building on untested assumptions is the biggest risk on the project.

Hypothesis, experiment, evaluate

The fix is simple in principle: treat uncertain decisions the way a scientist treats an open question. State what you believe, design a test, look at the results, and adjust.

In practice, this looks like:

• Name the assumption. Before writing production code, identify what you're betting on. "Users will complete this flow in one session." "This API can handle our volume." "The data model supports the reporting we need." Saying it out loud is half the battle.
• Build the smallest useful test. A prototype, a spike, a proof of concept. Whatever takes days instead of weeks. The goal isn't polish, it's signal.
• Evaluate honestly. Did the test confirm the assumption or challenge it? If it challenged it, that's not a setback. That's the whole point — you just saved weeks of building in the wrong direction.

This loop repeats throughout a project. Early on it's about architecture and approach. Later it's about edge cases and performance. The habit stays the same.

What this looks like in practice

We worked with a global medical device company that needed to pseudonymise millions of events daily for GDPR compliance before ingesting them into a data lake. The natural assumption was that this kind of volume required heavy infrastructure, dedicated servers, a bespoke processing engine.

Before committing to any of that, we evaluated three approaches: bare metal with Java, Erlang on Azure, and Azure Functions with a custom rules engine. The serverless option handled the volume at a fraction of the operational complexity.

Without that evaluation, the project defaults to the "safe" choice: over-provisioned infrastructure, months of setup, and an ops burden that outlasts the build. Instead, we shipped a focused pipeline in less time with less to maintain. The research phase didn't slow the project down. It removed the slowest path from consideration.

Why this matters for your project

Every project has a research phase, whether you plan for it or not. The difference is whether it happens at the start, when a pivot costs days, or after launch, when it costs months.

We put "Research & Development" in our name because we think this should be deliberate. Honest about what we know and disciplined about what we don't.