Early in almost every project conversation, I ask a question that sounds simple and isn’t: what does success look like?
Not “what does the tool do” — what does winning look like. A peer-reviewed publication? A demo that lands a bigger grant? A product that thousands of people use without anyone from the lab in the room? The answer matters, because it quietly determines how the thing should be built. And a tool built for the wrong answer is one of the most expensive mistakes in research commercialization.
“They’re still research-grade. They’re not a product.”
— an engineering professor, describing his lab’s prototypes
Two products that look identical
Picture two versions of the same app.
The first is built to run a study. Eighty participants, a defined protocol, a research assistant present to set it up, calibrate the hardware, and guide each person through. Data goes wherever is convenient — a local drive, a spreadsheet. It needs to work reliably for eighty people, once. That’s the spec.
The second is built to reach the public. Tens of thousands of users, no research assistant, no calibration ritual, no one to call when a screen is confusing. It has to be self-guided and self-explanatory, and it cannot fall over when usage spikes. The data has to live somewhere secure, somewhere that scales, somewhere compliant.
On a screen, these two products can look the same. Underneath, they are not. The first makes assumptions the second cannot afford — a trained operator, a small fixed load, data handling that was never meant to grow. You cannot smoothly inflate version one into version two. You rebuild. And rebuilding is slower and more expensive than building it right the first time, because now you’re also untangling everything the prototype quietly assumed.
Why this trips up good projects
It trips people up because both versions are correct for their moment. Building the scalable, self-service, cloud-backed version on day one would be its own mistake — over-engineered, over-budget, and slower to the evidence you actually need first. Research budgets are finite. You should not spend money proving something you haven’t validated yet.
So the answer isn’t “always build for scale.” The answer is: decide which one you’re building, on purpose, and build the first one so it doesn’t trap you.
That’s the real skill. A research prototype and a market-ready product are different builds — but the prototype can be architected so that scaling later is an extension, not a demolition. The data model can anticipate more users even while serving few. The code can be structured for a developer who isn’t on the team yet. None of that requires building the expensive version early. It just requires knowing the expensive version is coming.
A crawl-walk-run that actually works
The approach we take with research partners is deliberately incremental — crawl, walk, run. Start with the simplest version that proves the concept. Validate it. Publish it. Use that evidence to justify the next phase. Then build the next phase onto the first one — because the first one was designed to be built on.
It is easy to add complexity to a simple thing that was made well. It is painful to strip complexity out of a tangled one, or to scale a thing that was never meant to grow. Most of the cost overruns I see in this space come from one of those two directions.
So before the first line of code: build for the study, or build for the world? You don’t have to build both today. You do have to know which one is in front of you — and make sure today’s version is a foundation, not a dead end.
This is one of the first questions we work through with every research team. Peppermint Labs is a product strategy and research commercialization consultancy based in Toronto, helping academic teams and founders across Canada build the right version at the right time.