Suggestions
Dimosthenis Kaponis
C-Level Technology and Product Leader; Executive Advisor; Software Engineer; Entrepreneur
Dimosthenis Kaponis is a seasoned professional with over 25 years of experience in software engineering, technology, and product development. He has a diverse background that includes roles such as founder, chief executive, advisor, coach, CTO, and CPO for various startups and scale-ups.
With a strong educational foundation, Dimosthenis studied Ph.D (dropped out) in Distributed Artificial Intelligence and Multi Agent Systems, M.Eng in Computer Science, and Information Systems Engineering at Imperial College London. He also attended The Moraitis School.
Dimosthenis has held leadership positions in prominent organizations such as Metrika, Netdata, Beat (now FREENOW), and has worked in different capacities from Lead Engineer to CTO. His expertise spans strategy, product development, software architecture, team building, leadership, scaling, and systems design.
He has also contributed to top-tier institutions like Imperial College London, gaining valuable research experience. Additionally, Dimosthenis has a blend of industry experience, having worked at Goldman Sachs, Intrasoft S.A., and as a Software Engineer, Consultant, and Trainer in freelance capacities.
Currently, Dimosthenis provides strategic advice to Founders, CEOs, Product and Engineering leaders, and Investors. He works as a fractional CTO/CPO for technology start-ups and scale-ups in Europe and the United States, showcasing his holistic approach and extensive expertise.
Highlights
If there is one thing the AI-revolution will immediately bring (or, arguably, is already bringing) is (alas, I hate the term, but here goes) the ‘democratisation’ of software product development.
By now, there’s hundreds of posts, videos etc. showcasing how you can ‘make a game’ in 10’ using Claude and its agentic capabilities, even if you “haven’t coded before” etc. And, naturally, people have already started talking about the ‘end of SaaS’, how everyone will just ask some LLM to build their apps etc. Sure, that will probably happen in the future. Unfortunately, for now, those Claude outputs are not products, they are crude prototypes. And they cannot magically turn into polished, complete, products, on their own, just yet. To those hoping that your 1337 prompts will just make your ‘Claude app’ a massive success story and you, the Laziest Millionaire in the world: Sorry.
But! Given enough engineering and product know-how, you can use those systems to move fast, and build production-grade, state of the art applications in a very, very small fraction of the time, people and cost you needed just five years ago. Which is absolutely amazing!
Ergo: Your 100, 200, 400, or 1000-person company stands no chance of competing against small, dedicated teams of skilled engineers, product and marketing veterans augmented by ever-more-sophisticated AI tools. Your size, overheads, burn rate, and inefficiencies are now massive handicaps.
We’re just entering a new era of software development, not merely in the technical, but the business realm.
Years ago I was invited to do a due diligence on behalf of an investor. I’ve done this a handful of times, and it’s almost always an interesting experience. I was focusing on the technical side, but “technical” from the vantage point of an advisor to an investor, or, indeed, a CTO, is very different to what you might think: beyond languages, frameworks, architecture, cloud or on-prem, and so on, you factor in the size of the market, the unit economics, the maintainability of the system, the team and their skills, the path that led them to that moment—the interplay between different members. Then you tie those to the languages, the frameworks, the architecture and so on to reach a verdict.
That company failed the DD: The team in question had a major product market fit issue. It’s not that their product idea or vision were bad. It’s that they had no idea whether they’d catch on, or even tried to find out. Their, heavy on “sales”, light on vision, “hustling” leadership was coming up with crazy and ever changing requirements, with no justification; most likely stuff some prospect, or other, told them that week; there was no “adult” in the room, especially on the product or engineering side, to push back. This had resulted in a super complex architecture, combining microservices and serverless compute (at a time when the latter was both too expensive and too immature), in a doomed attempt to meet the crazy requirements presented to them. Instead of coming up with a simple, functional and forward looking prototype and use it for discovery, they were building like they were going to have millions of users in a month. With both engineering and product challenges draining the team, tensions arose; they were palpable during the DD. (But they apparently weren’t previously when their founders were pitching the investor.)
For early stage investments, this kind of DD can be exceptionally useful in figuring out whether team and product make investment sense. DD is rarely about the technology. It’s about everything else. And it’s surprising how superficially it is very often done, if at all.
