For problems with no off-the-shelf answer
Structured research, feasibility work and working prototypes – so you find out whether an idea holds up before you commit a year and a budget to building it.
Cheap experiments that prevent expensive commitments.
Most costly business mistakes are not bad ideas. They are reasonable ideas committed to before anyone tested the one assumption the whole thing rested on – and discovered eight months and a large budget later that it did not hold.
R&D work is the discipline of finding that assumption first, designing the smallest test that would disprove it, and running that test before the real money is spent. Sometimes the answer is build it. Sometimes it is buy it. Often the most valuable answer is do not.
- The question first. Written down precisely, with what a yes and a no would each look like.
- Smallest useful test. The cheapest experiment that could actually change the decision.
- Evidence, not opinion. A recommendation you can check the working on.
- Willing to say stop. A well-evidenced no is a successful project, not a failed one.
Six kinds of work, usually in sequence.
Feasibility studies
Can this be done, with what is available, at a cost that makes sense – answered with evidence rather than enthusiasm.
Proof-of-concept builds
A working prototype built to test one specific assumption, not a half-finished product you feel obliged to finish.
Process automation research
Finding which of your manual processes can actually be automated, what it would take, and which ones should be left alone.
Technology and vendor evaluation
Structured comparison of platforms and suppliers against your real requirements, not a features table from their websites.
Market and competitor research
Whether the demand exists, who already serves it, and where a defensible position is actually available.
Measurement and data design
Deciding what to measure and how, so the decision you make in six months has data behind it rather than anecdotes.
Everything between the question and the recommendation.
- Problem definition and scoping
- The critical assumptions written down
- Success and failure criteria agreed upfront
- Desk research and source review
- Technology and vendor assessment
- Stakeholder and user interviews
- Prototype or proof-of-concept build
- Structured testing against the criteria
- Cost and effort estimation
- Risk and dependency analysis
- Written findings with the evidence
- Build, buy or stop recommendation
Usually phrased as “we think we should, but”.
Six steps, and step two decides whether the rest is worth doing.
Define the real question
Written down in one sentence, precisely enough that an answer would actually change what you do next. Most projects arrive with a vague version of this and it is the first thing to fix.
Find the assumption that matters
Every plan rests on a handful of beliefs. One of them is usually both critical and untested. Identifying it is the highest-value hour of the whole engagement.
Agree what would settle it
What result would mean yes, what would mean no, and what we would do about an ambiguous middle. Set before the test, so the answer cannot be argued into whatever people already wanted.
Run the smallest test
Desk research, interviews, a prototype, or a limited live trial – whichever is the cheapest thing that could genuinely change the decision.
Evaluate honestly
Against the criteria set in step three, including the parts that argue against the outcome anyone was hoping for.
Recommend and hand over
A written recommendation with the reasoning, the costs, the risks and the alternatives – plus everything built along the way.
The expensive failure is the one nobody tested.
Without it
The decision gets made in a meeting, the budget is committed, and the flawed assumption surfaces eight months in – by which point too much has been spent to stop and too little works to continue.
With it
The same assumption is tested in weeks, for a fraction of the cost, before anything is committed. Either you proceed with far more confidence, or you keep the budget for something that will work.
The cheapest project we ever run is the one we tell you not to start.
What you receive at the end.
A document someone can act on, plus everything produced getting there.
- The question, and the answer, in plain language
- The evidence, with sources and method
- Any prototype or code built, and its source
- Cost and effort estimates for the recommended path
- Risks, dependencies and open questions
- The alternatives considered and why they were rejected
Everything produced is yours, including work that supported a negative conclusion. The research that stopped a bad project is often the most valuable thing in the file.
Built for decisions big enough to be worth de-risking.
R&D work pays for itself where the decision ahead is expensive, hard to reverse, or resting on something nobody has actually verified. For small, reversible choices, just try it and see.
Honest note: we will not tell you what you want to hear. If the research says the idea does not work, that is what the report will say, with the evidence attached. Hire us only if that is genuinely what you want.
- Businesses weighing a build-versus-buy decision
- Companies considering a significant automation investment
- Organisations entering an unfamiliar market or category
- Teams choosing a platform they will live with for years
- Founders testing a product idea before committing to it
- Firms with a project that has stalled and nobody knows why
The things worth knowing before you start.
How long does an R&D engagement take?
A focused feasibility question: two to four weeks. A proof-of-concept build: four to ten. We deliberately keep these short – an R&D project that runs for six months has usually become the thing it was meant to de-risk.
What if the answer is no?
Then the engagement worked. You have spent a small fraction of the build cost to avoid the whole of it, and you have the evidence to explain the decision to whoever needs convincing.
Do we own what you build?
Yes – code, research, data and documentation. That is stated in the proposal before anything starts.
Can you build the full thing afterwards?
Sometimes, and sometimes the honest recommendation is a specialist firm or an off-the-shelf product instead. The research is scoped and priced separately from any build so that recommendation is not influenced by what we would like to sell you next.
Will you sign an NDA?
Yes, as a matter of course. Most of this work involves commercially sensitive plans and it is a normal part of starting.
We are not sure what our question is.
That is a common starting point and often the first thing worth solving. A short scoping conversation usually turns a vague concern into a precise, testable question – and occasionally reveals the answer without any further work.
The rest of the technical side.
WordPress Development
Building, extending and maintaining WordPress sites that are meant to be worked on. Read more
Migration Services
Sites, mailboxes and databases moved between hosts and platforms without losing anything. Read more
Backup Solutions
Automated, tested backups, so a bad day stays a bad day rather than becoming a bad quarter. Read more
Where the question is technical.
A large share of the R&D work we are asked for sits on the engineering side – someone needs to know whether a thing can be built, what it would take, and whether it is the right thing to build at all. These are the areas we are usually brought in on.
Software feasibility
Can this be built with the stack, data and team available, and at what realistic cost. Answered with a technical spike rather than an estimate written in a meeting.
Architecture and design spikes
Short, targeted investigations into the design decision that everything else depends on – the one that is expensive to reverse once code exists around it.
Product concept validation
Whether the problem is real, who has it badly enough to pay, and what the smallest version worth shipping actually contains.
MVP definition and scoping
Cutting a product idea down to what has to exist for the first release to teach you something – and naming what deliberately comes later.
AI and automation feasibility
Whether a process genuinely suits automation or AI, what accuracy is achievable on your own data, and where a human still has to stay in the loop.
Data and integration research
Whether your systems can talk to each other, whether the data is good enough to build on, and what cleaning or restructuring would be needed first.
Technical due diligence
An independent read on a codebase, platform or vendor before you acquire it, commit to it, or build a business on top of it.
Build, buy or integrate
A structured comparison of building it yourself, licensing something existing, or assembling it from parts – with the total cost over three years, not the sticker price.
Prototype to production review
What it would take to turn a working prototype into something you can safely run, support and scale – before anyone promises a launch date.
These are scoped as short, fixed-price investigations with a written recommendation at the end. Where the answer turns out to be build it, the research is designed so the build team can start from it rather than repeat it.
What are you about to commit to?
Tell us the decision in front of you and what it rests on. We will tell you whether it is worth testing first, and what the cheapest useful test would be.