University spin-outs
Product & Data Readiness for University Spin-outs
Move a research prototype toward commercial delivery without losing control of data, architecture, governance, or handover responsibilities.
Why teams reach this point
University spin-outs often inherit research code, ethics approvals, institutional infrastructure, special-category data and informal ownership boundaries. Those arrangements can work during a study but become difficult to explain to funders, partners, customers and a growing engineering team.
Risks the review surfaces
- +Research infrastructure or accounts still sit inside the university boundary.
- +Controller, processor, IP, hosting and support responsibilities are unclear.
- +Ethics-approved processing does not map cleanly to the commercial product.
- +Prototype architecture and documentation cannot support customer diligence.
What I review
- +Map product boundaries, data flows, actors, processors and infrastructure ownership.
- +Review the architecture, deployment model, access controls and operational handover.
- +Connect research documentation and governance history to the intended commercial use.
- +Prioritise a 30-day engineering plan and a longer readiness roadmap.
What useful closure looks like
- +A clear product and data boundary
- +A prioritised engineering backlog
- +A credible readiness story for funders and partners
Relevant experience
- +11+ years shipping production software
- +Delivery experience with university spin-outs
- +Healthcare, AI, education and sensitive-data systems
Frequently asked questions
Can you replace our university legal or technology-transfer team?
No. This is an engineering-led review. I make technical boundaries and implementation work explicit, then work alongside the relevant legal, DPO and technology-transfer stakeholders.
Do we need a finished product?
No, but you should have a working prototype, repository, intended commercial use and enough context to map the current data and infrastructure.
What do we receive?
The scope determines the depth, but the core output is a written risk map, architecture and data-flow observations, prioritised actions and a review call.