Over the past year I’ve had introductory conversations with dozens of researchers — public-health scientists, engineering professors, clinicians, community-college instructors. Different fields, different institutions, different countries. Almost every one of those conversations arrived at the same place.

The researcher had something good. Not an idea on a napkin — something real. A prototype that had been user-tested. A study that had been peer-reviewed. A tool that worked, that the people who tried it genuinely liked. And then, almost word for word, some version of this:

“I don’t want this to die when the funding runs out.”

— a researcher, eight years into building a single tool

That sentence is the reason Peppermint Labs exists.

The gap nobody budgets for

There is a well-documented gap between research and a product in the world. In commercialization circles it gets a dramatic name — the “valley of death.” On the ground it’s quieter than that. It looks like a validated prototype sitting on a lab server. It looks like a paper that proved something works, with no next step funded. It looks like an app that’s live on one platform, for one small study population, and nowhere else.

The research did its job. It answered the question. What it didn’t do — what research funding almost never pays for — is the unglamorous, expensive work of turning a validated prototype into something a stranger can pick up and use without a research assistant sitting beside them.

A few patterns show up again and again.

Research-grade and market-ready are different products. A tool built to run an 80-person study is architected for 80 people. It assumes a trained assistant will set it up, calibrate it, and walk each participant through it. A product built for ten thousand people assumes none of that. These are not the same build with a fresh coat of paint. If you only build the first one, you will rebuild it later — usually from scratch, usually for more.

The team that built it doesn’t stay. Research software tends to be built by graduate students and postdocs. They are talented, and they are temporary. They graduate. They take jobs. They go quiet over the summer. The knowledge of how the thing actually works walks out the door with them, and the project stalls — not because the science was wrong, but because nobody is left who can open the code.

The funding is structured against continuity. Grants are finite and tightly scoped, and often use-it-or-lose-it. The money to maintain a tool — to keep it from quietly breaking as the operating systems around it update — is rarely in the budget at all. As one researcher put it to me, academic-built software tends to “get cracks in it and die.”

What actually closes the gap

None of this is a knock on researchers. Building, maintaining, and commercializing software is a different discipline than running a lab, and no one should expect a principal investigator to be fluent in both.

What closes the gap is treating commercialization as its own piece of work — scoped, resourced, and planned from the start, not improvised after the grant runs out. In practice that means a few things:

  • Build with the end in mind. Even the first research prototype should be architected so it can scale later, even if it doesn’t yet. That single decision saves a full rebuild.
  • Tie the work to milestones, not just deliverables. A phase of work should produce something you can leverage — a publication, a conference demo, the pilot data that unlocks the next grant. Momentum compounds. Dormancy doesn’t.
  • Plan for the day the team turns over. Documented, readable code and a real handoff, so the project doesn’t live or die by one person’s memory.

The hardest part of research commercialization isn’t the research, and it isn’t the technology. It’s the stretch in between — and it’s the stretch almost nobody plans for.

That’s the work Peppermint Labs was built to do — a research commercialization consultancy based in Toronto, working with academic labs and research teams across Canada and North America.