When I set up as a fractional CTO, the model was simple: work as an extension of a client's team, looking after all aspects of technology in their business. Strategy, infrastructure, integrations, software decisions, security. Whatever the technology problem, it lands on my desk. And when we needed to actually build something, I'd pull in developers as required.
That model is changing faster than I expected.
In the last year or so, tools like Lovable and Emergent have gone from fun experiments to serious tools I'm using on production systems. AI-assisted platforms that can take a reasonably well-defined idea and produce working, deployable software in a fraction of the time a traditional build would take. What used to require spinning up a dev team for weeks can now, for certain projects, be done without one.
I want to be careful about how I say this. Not every project fits this pattern. Complex, sensitive, or deeply integrated systems still need proper engineering teams. But for a surprising number of tools and apps I build with clients, I'm no longer reaching for developers at all.
I'm really enjoying this. As someone who started out as a software developer, there's something great about feeling hands-on again. Being able to go from idea to working software quickly, is genuinely exciting. One of my clients recently told me he never thought looking at software could make him so happy. That kind of feedback doesn't get old.
What hasn't changed is the need for someone to actually understand what's being built.
This is where I think the vibe coding trend goes wrong. AI can produce code that looks fine and runs fine until you realise it's pointing at the wrong environment, or missing an edge case that matters when real money or real data is involved. I caught exactly that on a project I built recently to handle payments. The code worked. It just would have double-charged customers. Not a problem you want to find in production.
The speed is real. The risk of moving too fast is also real. The job of a technical lead hasn't gone away, it's shifted. Less time coordinating developers, more time making sure what the AI produces is secure, scalable, and actually doing what we think it's doing.
The question I used to ask was: How long will this take to build, and is that worth it? Now the question is just: Is this worth building? That's a genuinely different place to start from, and it's happened in a pretty short window of time.
When I set up as a fractional CTO, the model was simple: work as an extension of a client's team, looking after all aspects of technology in their business. Strategy, infrastructure, integrations, software decisions, security. Whatever the technology problem, it lands on my desk. And when we needed to actually build something, I'd pull in developers as required.
That model is changing faster than I expected.
In the last year or so, tools like Lovable and Emergent have gone from fun experiments to serious tools I'm using on production systems. AI-assisted platforms that can take a reasonably well-defined idea and produce working, deployable software in a fraction of the time a traditional build would take. What used to require spinning up a dev team for weeks can now, for certain projects, be done without one.
I want to be careful about how I say this. Not every project fits this pattern. Complex, sensitive, or deeply integrated systems still need proper engineering teams. But for a surprising number of tools and apps I build with clients, I'm no longer reaching for developers at all.
I'm really enjoying this. As someone who started out as a software developer, there's something great about feeling hands-on again. Being able to go from idea to working software quickly, is genuinely exciting. One of my clients recently told me he never thought looking at software could make him so happy. That kind of feedback doesn't get old.
What hasn't changed is the need for someone to actually understand what's being built.
This is where I think the vibe coding trend goes wrong. AI can produce code that looks fine and runs fine until you realise it's pointing at the wrong environment, or missing an edge case that matters when real money or real data is involved. I caught exactly that on a project I built recently to handle payments. The code worked. It just would have double-charged customers. Not a problem you want to find in production.
The speed is real. The risk of moving too fast is also real. The job of a technical lead hasn't gone away, it's shifted. Less time coordinating developers, more time making sure what the AI produces is secure, scalable, and actually doing what we think it's doing.
The question I used to ask was: How long will this take to build, and is that worth it? Now the question is just: Is this worth building? That's a genuinely different place to start from, and it's happened in a pretty short window of time.