When a research-backed software project stalls, the instinct is to look for a scientific reason. A flawed hypothesis. A result that didn’t replicate. A method that didn’t hold up.
In my experience, that’s rarely what happened. The projects I see stall almost never stall because the science failed. They stall in the middle — in the unglamorous stretch between a promising prototype and a finished tool — and the reasons are structural, not scientific.
The people who build it are temporary
Research software is usually built by graduate students and postdocs. They are often genuinely good at it. They are also, by design, passing through.
A postdoc finishes their term and takes a job. A graduate student’s priority — correctly — is graduating, and a build schedule competes with a thesis. Undergraduates change majors, or hit a hard semester, or simply leave for the summer. I’ve learned never to assume the person who started a build will be the person who finishes it.
“I never put all my eggs in the undergraduate-research basket — a student can change their major, or have a breakup.”
— a professor, on relying on student developers
Every one of those transitions is a knowledge transfer, and knowledge transfer in software is not a clean handoff. The new person inherits a codebase they didn’t write, with reasoning that lived mostly in the previous person’s head. The project doesn’t fail. It slows to the speed of someone re-learning it — and sometimes it stops there.
The summer goes quiet
Academic timelines have a rhythm, and that rhythm has gaps. Terms end. Students disperse. Conference season pulls everyone in different directions. A project with real momentum in April can be dormant by July — and dormant projects are hard to restart, because context has to be rebuilt before the work can resume.
This isn’t anyone failing at their job. It’s just what happens when the people doing the building are also students, with a student’s calendar and a student’s priorities.
The PI is the bottleneck — and shouldn’t be
Above all of it is the principal investigator, holding the project together between teaching, grant writing, publishing, reviewing, mentoring, and a personal life. Coordinating the build — chasing updates, reconciling who’s doing what, keeping the technical work on track — lands on them by default. It’s the part of the project most easily dropped, because everything else has a hard deadline and the build doesn’t.
When a researcher tells me a project has been “sitting” for a while, this is almost always the story. Not a failure of will or talent. A structural gap: no one whose actual job is to keep the thing moving.
What steady looks like
The fix isn’t heroics. It’s continuity — someone accountable for momentum who isn’t also teaching three courses.
In practice that means a few unglamorous things. A team that doesn’t graduate out from under the project. Code written to be picked up by someone who didn’t write it — documented, readable, handoff-ready by default. A cadence of communication that fits the PI’s real bandwidth, whether that’s a weekly call or an async update, so staying informed doesn’t become another job. And work organized so that a quiet summer doesn’t reset progress to zero.
A research project doesn’t need to be rescued from bad science nearly as often as it needs to be carried through its fragile middle. That stretch — between “it works in the lab” and “it’s a real tool” — is where good projects go quiet.
It’s also, more often than not, where they can be saved. Peppermint Labs is a research commercialization consultancy based in Toronto, working with academic teams and founders across Canada and North America to carry projects through exactly this stretch.