The brief version
GeoVS was founded on research from my PhD in Computer Science. The technology, a novel approach to geospatial visualisation and data processing, had commercial potential that wasn't going to be realised in a university context.
We raised venture capital, built a product, found commercial customers, and ultimately sold the company to SRT Marine Systems in a trade sale. That's the arc. Here's what matters for founders reading this.
Why this matters for the founders I work with
The reason I lead with this story, before credentials, before certifications, before impressive enterprise clients, is that I have been exactly where most of the founders I work with are right now.
I have sat in the room with investors explaining a technology that most people in the room don't fully understand. I have made architecture decisions knowing they would either compound our advantage or box us in. I have hired engineers and been wrong. I have managed a board and had difficult conversations about timeline and cash. I have navigated an acquisition process (the due diligence, the negotiations, the team communication) and come out the other side.
Most technology advisors have the technical depth or the commercial experience. The intersection, where you understand both the architecture question and the business question it's embedded in, is rare.
What GeoVS taught me
Raising VC on a deep tech play is a specific kind of sell. You're asking investors to believe in technology that doesn't yet have a market category, at a stage where the revenue story is still largely hypothetical. The discipline this requires (clarity of explanation, commercial framing of technical capabilities, patience with timelines) is something that doesn't come from a business school case study.
Your architecture decisions at Series Seed are Series B problems. The choices we made in the first 12 months of building GeoVS (data model design, API structure, deployment approach) showed up two and three years later as either foundations or technical debt. I made some good calls. I also made calls I would make differently now. Both inform how I advise founders today.
Product-market fit and technical architecture are not separate problems. The pressure to ship fast in a startup context can lead to treating these as sequential: "get the product working, then fix the architecture." This is usually a false economy. The technical decisions you make while finding PMF will either give you speed in the next phase or cost you months of rework.
The exit process is a technology diligence event. When SRT Marine Systems conducted technical due diligence on GeoVS, the questions they asked were the same questions any acquirer or major investor asks: Is the code defensible? Is the architecture scalable? Are there hidden dependencies or liabilities? Is the team capable of continuing without the founders? Building with these questions in mind, even years before an exit is contemplated, is what makes a company acquirable. Having been on both sides of this process is why due diligence is now a core part of what I offer.
The exits that followed
GeoVS was the first. Three more followed: Codiance (a software engineering agency I co-founded and sold to a co-founder), IQDEV (a digital/AI transformation consultancy where I was VP of Software Engineering), and AdBrain AI (an agentic AI platform I co-founded that delivered 67% case automation for one of Europe's largest insurance brokerages). Four exits across different technology contexts (deep tech, agency, consulting, AI) means the lessons are pattern-level, not anecdotal.
What this means for working with me
When I sit in your board meeting or join your investor call, I'm not performing the role of "technical advisor." I understand the dynamics of that room because I've been on the other side of the table.
When I tell you your architecture decision will create a problem at Series B, I'm not guessing from first principles. I've lived it.
When I push back on a hiring decision or a vendor commitment, it's because I know what these choices cost when they go wrong. Not just technically, but commercially and organisationally.
If you need this level of thinking in the room but can't justify a full-time CTO: that's the problem I solve.
Related: How I approach every engagement · Fractional CTO services · AdBrain AI. 67% case automation
