You spent three years on the science. Now it has to be a product.
There is a moment that comes to nearly every research-led company.
The thing works. The algorithm holds up. The sensor reads true. The clinical insight survives contact with real data. Years of careful work, and it is finally, genuinely done.
Then someone asks when it will be ready to sell.
That question opens a gap most teams underestimate. Not because they are naive, but because the two things either side of it look far more similar than they are.
What you have is not yet a product
You have the hard part. That should be said plainly, because it is true.
Years of domain work is one of the rarest things in any technology company. It cannot be bought in, rushed, or replaced with a bigger budget. If you have it, you have something most companies never will.
But it is not a product. A product is the thing around it. The way a first-time user meets it without being taught. The way it behaves when the network drops. The way the data is stored, secured and handled properly. The way it survives ten thousand people using it in ways you did not imagine.
None of that is a smaller problem than the science. It is a different one.
It is also the problem we work on. Purpledecks built the product software around ResMed's sleep science, and the original Bluetooth SDK for Fire1's implantable cardiac device. The rest of this piece is what that work has taught us.
The skills that made it are not the skills that ship it
An optics team is not a consumer product team. A clinical research group is not a mobile engineering group. That is not a criticism of either. It is what specialisation means.
The clearest example is the user interface. Engineers design for how the thing works inside, because they understand it inside. Users meet it from the outside, cold. There is a whole discipline in that gap, and it is not decoration. Pretty is not the same as usable, and usable is the part that decides whether anyone comes back.
The people who spent three years perfecting a signal processing approach spent those years getting very good at signal processing. Asking them to also be experts in mobile release engineering, cloud infrastructure, human factors, and health data handling is asking them to be a different company.
Most teams know this. Where it gets expensive is what they do next.
And you probably do not want those skills permanently
You need product engineering intensely, for a defined stretch. Twelve months, eighteen, maybe two years. You need it at full strength, and then you need much less of it. The work does not stop at launch, but it changes shape, and it is rarely the same size.
That is awkward to hire for. Build a full product team and you carry a payroll designed for a peak that ends. You will be managing an exit you did not plan, at exactly the moment your attention should be on customers.
Two expensive ways to get this wrong
Building the team you only need once. Hiring is slow, and hiring well for skills you do not personally hold is slower. By the time the team is assembled and working properly, a large part of the window has gone. And the bill continues after the need does. If the product is going to be the whole company, hire. That peak never ends. Most research-led companies are not in that position.
Handing it to a shop that does not understand what you have. This is the worse one, because it looks like the safe option. A firm that builds broadly and quickly will treat your core as a component. They will wrap it, abstract it, and make reasonable general decisions about it.
The trouble is that the thing that makes your core valuable is usually specific and slightly awkward. It has constraints that look arbitrary until you understand why they are there. A team that has not taken the time to understand them will engineer them away, politely, and hand you back something that works but is no longer special.
You do not always find out immediately. Sometimes you find out when a competitor ships something similar and you cannot explain why yours was meant to be better.
What good actually looks like
The right partner builds the product around your core without diluting it.
In practice that means a few things. They ask about the constraints before they design around them. They treat your domain knowledge as the asset it is, rather than something to be simplified. They build the parts you do not want to build, to a standard that will survive real users.
They also bring the experience your team was never meant to need. Years of putting products into the world teach things a research environment cannot. How to set up support. Which tools are worth paying for. What a realistic first year in the market looks like. Which mistakes are survivable and which are not. The right partner hands that over freely, the bad experiences included, and tells you what not to do before you do it.
And they hand the product back as yours, documented and maintainable, so you are not tied to them forever. That last point matters more than it sounds. A partner who leaves you dependent on them has not finished the job. They have just changed who holds it.
A product needs an owner, not a committee
There is a quieter problem we meet almost every time, and it is not a skills problem at all. It is how decisions get made.
Research organisations tend to work by committee. That is not a flaw. It is how good research works. Consensus, review, nobody's word final until the evidence is in. Regulated product work needs its reviews and its traceability too, so review itself is not the problem. Unowned decisions are. A product cannot be built by committee, and it certainly cannot be built by committee through an external team. Every open question becomes a meeting. Every meeting becomes a fortnight. The build slows to the pace of the calendar.
We have often had to help a client change this before the real work could start. One named product owner. Somebody with the authority to get answers, make the call, and bring the right stakeholders in, so that decisions have a home. It sounds like a small thing. It is regularly the difference between a project that moves and one that circles.
Launch is where the work starts
The other thing research-led teams are rarely set up for is what happens when the product goes live. Because that is not the end of the job. It is the start of a different one.
Real users arrive, and they have opinions. Bugs surface that no test found. The app store reviews start. Somebody has to run the support desk, ship the fixes, plan the next features, and keep the whole thing maintained while the world changes underneath it. Who owns that in your company? Do you have people for it? Most research teams honestly do not, and there is no reason they should have. They have never had to.
The cost surprises people too. The build is often not the biggest bill. What comes after it, year after year, frequently is. A product in the market is a running commitment, not a finished artefact, and it should be planned and priced as one from the day the project starts. What that commitment costs is its own question, and we have answered it in a companion piece on what it costs to maintain an app.
A team that only builds what you spec walks away at exactly this point. That is the moment you find out what kind of partner you hired.
What that has looked like in practice: ResMed and Fire1
ResMed came to us with decades of clinical sleep science and no consumer product. They are a global leader in sleep and respiratory medical devices, and everything they made lived in the clinical world. Prescribed, worn, medical. The S+ was their first consumer product: a bedside sleep monitor that measures your sleep with nothing worn and nothing attached.
Our job was not the sleep science. That was theirs, and it was decades deep. Our job was everything around it. The device software, the app people actually opened each morning, and the backend handling sensitive health data properly. Consumer polish on medical discipline, and the two usually pull against each other. The first project led to a second, the software for the world-first sonar sleep tracking that shipped in SleepScore. The science, again, was theirs.
Fire1 came with an implantable cardiac device, now in clinical trials. We built the original Bluetooth SDK that lets it talk to the outside world. Again, the device and the medicine are theirs. The software connecting it to the world is where we came in.
When we build medical device software, we build to the standards that apply, working under the client's quality system. That is the discipline the work demands, and it is not optional.
This is not an abstract problem to me
I came out of neural network research at Dublin City University. In 2001 I took a Marie Curie Fellowship in Karlsruhe, working on some of the earliest mobile phones that could run custom software. This was long before the iPhone. Some of the handsets had monochrome screens, and running a simple parser could be too much for them. We were finding out how far these devices could be pushed. How to present data on screens that small. How real users would actually use them, and how business systems could talk to them. Nobody had the answers yet, and the device limits shaped every decision.
After that I spent eight years at a Dublin company building on-device portals for some of the world's largest mobile companies. Vodafone, Hutchison, Bharti Airtel, Telia and One Austria on the operator side. Nokia and LG on the handset side. Global work, all of it built against the hard limits of the devices of the day.
By the time I opened Purpledecks in 2012, I had spent more than a decade turning what a constrained device could barely do into something people would actually use. I opened it knowing how to build software and little about running a business, and I learned that side the way you learn anything properly, by doing it, for fourteen years. That matters here, because the gap this piece describes is not only technical. Crossing it is a business job as much as an engineering one. A research team inside a larger organisation may never have owned the release, support, cost and customer decisions around a live product. Those decisions have been our daily work ever since.
The screens are better now than they were in Karlsruhe, but the work has not changed. Real capability on one side, hard constraints on the other, and a product to be built around both. That gap is where this firm has worked ever since.
The short version
If you have spent years building something genuinely rare, the last thing you should do is hand it to people who will treat it as ordinary.
And do not settle for a team that only builds. We built this firm to be the partner, not the build shop. There during the build, there after launch, at the end of the phone.
You bring the thing you are brilliant at. The right partner builds the product around it, helps you become the company that can run it, and gives it back to you better than they found it.
Brian Egan founded Purpledecks in 2012. He started in neural network research at DCU, took a Marie Curie Fellowship working on some of the earliest programmable mobile phones, and spent eight years building for operators including Vodafone, Hutchison and Bharti Airtel.