The most expensive software decisions get made on the least evidence — a demo that went well, a quote nobody could benchmark, an assumption about a data field nobody checked. We answer the question properly first: what it would take, what it would cost, which option actually wins, and whether it's worth doing at all.
Every one of these is cheaper to fix now than after the contract is signed.
Six figures, forty pages, and no internal yardstick for whether it's fair, complete, or solving the right problem.
Both vendors looked great on their own data. Neither was asked the same questions, so the choice comes down to who presented better.
The decision keeps getting deferred for more information, and the information never arrives because nobody said what would be enough.
The savings number came from an estimate somebody made in a meeting, and now it's in a board pack with two decimal places.
The whole plan assumes a field is populated, accurate, and historical. No one has checked, and it's a week's work to find out the hard way.
Same idea, same room, three years later — with the original reasons for failure sitting in an inbox nobody has access to anymore.
A study that costs a fraction of a build and concludes "don't" has paid for itself many times over — and that's a real outcome here, not a polite fiction. We agree what would make the answer a yes before we start looking, so the finding can't be quietly reshaped into whatever keeps the work going. If the honest recommendation is to buy something off the shelf, fix the process instead, or leave it alone for another year, that's what the report says.
DMAIC improves a process you already run. Its counterpart, DMADV, is for designing something new — which is exactly what a feasibility study, a vendor selection, or a first product really is. Five phases, and the last one is not "start building".
Name the decision the research has to serve, who makes it, and when. "Learn about X" is a reading list, not a project — it never ends because nothing tells you when you're done.
Agree what would actually change the answer, and gather it: current volumes, costs, and constraints from your own systems rather than from memory. Requirements get written down before anyone sees a demo.
Score the real options against those criteria — including doing nothing — with costs, risks, and trade-offs on one page instead of in six people's heads.
Build the smallest thing that tests the leading option for real: a spike, a prototype, a vendor trial run on your data rather than on their sample set.
Check the result against the criteria set in Define, before contracts get signed or a build starts. Then you get a recommendation with the evidence attached — and the confidence level stated honestly.
Already running the process and just want it to run better? That's DMAIC, and we'll point you there instead.
Fixed scope, fixed price, and a written answer at the end of each one.
Can this be done, at what cost, and what would have to be true for it to work?
The same questions put to every option, scored the same way, on one page.
What the work really involves — gathered from the people who do it, not from a wish list.
When the only way to know is to try it — timeboxed, and thrown away on purpose.
The answer is often already in your systems — just not in a form anyone can read.
For the product or service you're about to launch — sized before it's built.
An independent read on software you're about to buy, inherit, or bet on.
Every finding in the report carries a grade from this ladder. It settles the argument that decides most selection meetings — whose input outranks whose — before the meeting starts.
| Evidence | What it means | |
|---|---|---|
| A | Your own measured data | Counts, timings, and costs pulled from your systems. Nobody argues with their own database for long. |
| B | Direct observation | Watching the work happen — the steps people actually take, not the ones in the procedure. |
| C | Hands-on trial | A pilot, spike, or vendor trial run against your data, your volumes, and your edge cases. |
| D | Comparable references | Operators with your shape of problem, asked what broke — not the reference list the vendor picked. |
| E | Published documentation | APIs, limits, licence terms, and benchmarks you can cite and re-check later. |
| F | Vendor claims | Useful as a list of things to verify. Never as the reason for a decision. |
| G | Opinion in a meeting | Where most expensive decisions actually come from. Worth hearing; worth labelling. |
A recommendation resting on grade F gets labelled as such. That's the point of grading it.
A document your team can act on and defend internally — not a slide deck that gets forwarded once and never opened again.
One to four weeks, agreed up front. Research without an end date is just reading, and it's how decisions rot for eight months.
We resell nothing and take no vendor referral fees, so "buy that instead of hiring us to build it" costs us nothing to say.
Trials and spikes run against your volumes and your edge cases, not the tidy sample set that comes with the demo.
You keep the model and the method, so when the price changes or a new vendor appears you re-run it instead of starting over.
This is applied decision research for operating businesses. We're not a lab and we don't publish papers; nothing here is legal, financial, tax, or regulatory advice, and where a question needs one of those we'll say so and tell you what kind of professional to ask.
We also don't hand back a two-hundred-page market report with no recommendation in it. Every study ends with a call — ours, in writing, with the reasoning attached — because a study that refuses to conclude has just moved the decision back onto your desk with a bigger stack of paper on top of it.
Standard practice, named plainly — nothing here is proprietary and all of it is checkable.
Different framework for a different question. DMAIC improves a process that already exists; DMADV — Define, Measure, Analyze, Design, Verify — is the Six Sigma framework for designing something that doesn't exist yet, which is what a feasibility study, a vendor selection, or a new product really is. If the process is already running and just runs badly, you want DMAIC instead, and we will say so.
Discovery normally happens inside a project you have already committed to, and it is very hard for it to conclude that the project shouldn't happen. Research runs before that commitment, with the criteria for the decision agreed up front and "don't do it" as a legitimate outcome. The deliverable is a decision with evidence attached, not a backlog.
Regularly. If a product on the market covers eighty percent of what you need at a price a custom build can't touch, that's the recommendation, and the report says so with the scoring behind it. We'd rather be the firm you call for the next decision than the one that sold you a build you didn't need.
Most research engagements are fixed-price and run one to four weeks depending on how many options are in play and how accessible your data is. A single timeboxed spike can be a couple of days. You get the scope, the price, and the questions it will answer in writing before it starts.
Then the study did its job, usually for a fraction of what the project would have cost. Killing a bad idea in week two is the cheapest outcome available, and we will hand you the evidence to defend that call internally.
No. This is applied decision research for businesses — feasibility, selection, due diligence, and operational questions answered from evidence. We are not a lab, we don't publish papers, and we don't provide legal, financial, or regulatory advice; where a question needs those, we tell you and say who to ask.
Less than you'd expect. A sponsor who can define what a good decision looks like, a couple of hours from the people who do the work today, and read access to the relevant systems. We do the digging; you supply reality and make the call.
A written report: the decision framed, the options scored, the evidence graded by how strong it is, costs and risks quantified where they can be, and a clear recommendation with its confidence level stated. Plus the working files — the scoring model, the data profile, any prototype — so your team can re-run it when something changes.
Tell us the decision you're stuck on and we'll tell you what it would take to answer it properly — scope, price, and the questions it settles, in writing before it starts.
