For founders and leadership teams
Fractional CTO
I was Cat in a Flat's only developer for years before anyone called me CTO - by the time the title showed up, I'd already been doing the job. That's usually how it goes: a business doesn't wake up needing a full-time CTO, it wakes up needing CTO-level thinking long before it can justify the salary.
That's the gap I fill - technical direction, the calls on architecture and hiring, keeping engineering pointed at what the business actually needs. Whatever cadence makes sense: a day a week through a rough patch, a few hours a month once things settle, full-time while you look for someone permanent. Either way, you're getting someone who's actually built and shipped it, not advised on it from outside.
I've also been the CTO on the other side of an acquisition - Cat in a Flat's sale to Rover happened on my watch, so I know what that process actually looks like from inside a target company, not just in theory. If you're heading into a sale, a merger, or any kind of technical leadership transition, that's exactly the kind of thing I can help you through.
Good fit if:
- You're technical but stretched too thin to lead engineering and run the business at once
- You're non-technical and need someone you trust to translate between the board and the engineering team
- You're hiring a permanent CTO and want the role properly covered until they start
- You're heading into an acquisition, merger or leadership handover and want someone who's actually been through one
Systems built to last, not just to ship
Software Architecture
The mobile-first rebuild at Cat in a Flat was that kind of problem - a platform that had grown the way most platforms do, one decision at a time under pressure, until nobody could quite remember why half of it worked the way it did. A lot of architecture problems are actually that: decisions nobody's revisited since the pressure that caused them passed.
I look at what you've got, work out what's actually causing the pain, and map out the route from where you are to where you need to be.
Sometimes that's a full platform redesign. More often it's a handful of targeted changes that buy you another two years before a bigger rebuild is worth the disruption - and I'll tell you which one you actually need, not sell you the bigger project.
Good fit if:
- Your platform is creaking under growth you didn't plan for
- You're planning a major migration - cloud, database, framework - and want it de-risked first
- You need the system designed properly before your team starts building it
Ongoing guidance, not a one-off report
Technical Advisory
You don't always need a fractional executive in the room, but you might want a trusted sounding board before making expensive engineering bets. I can provide an objective second opinion for startups and growing businesses who want to sanity check their tech strategy. Or maybe you're looking at an investment or an exit - I've been through the due diligence grinder firsthand, so I know exactly how to look at your architecture through the eyes of investors and buyers.
I work with you on an ongoing basis rather than delivering a one-off report: regular check-ins, honest opinions even when they're not what you wanted to hear, and available when it actually matters rather than to a fixed schedule. It's the model behind a lot of the DPR & DAC7 advice on this site - conversations like this are how it started.
Good fit if:
- You need a second opinion before a decision that's expensive to get wrong
- You're weighing build versus buy versus outsource and want someone impartial in the room
- You're an investor or acquirer and want technical due diligence before you commit
Before you press launch
AI Software Review
Tools like Lovable, Cursor and Claude mean a founder can now get a working product built without hiring an engineer at all. The trouble is that "working" and "safe to run in production" aren't the same thing - AI-generated code has a habit of looking plausible while quietly getting security, data handling or edge cases wrong, and it takes someone who actually reads the code to tell the difference.
I review AI-assisted or AI-generated codebases the way I'd review any handover: for security holes, for maintainability, and for the decisions a person would have made differently. You get a clear list of what's fine, what needs fixing before launch, and what will cause problems in six months if it's left alone.
Good fit if:
- You built your product yourself with AI tools and want a second opinion before you launch it
- You've inherited a codebase and aren't sure how much of it to trust
Sometimes the fastest path is to build it
Software Development
I work on things like the Citizen Space Aggregator - Delib's free tool indexing tens of thousands of public consultations - because a growing business often ends up with smaller products orbiting the main one that still need building and keeping alive. Delib asked me to rebuild the Aggregator and take on hosting it long-term, so their team could stay focused on Citizen Space itself - the kind of job that goes to someone you already trust.
I work full-stack, from Python through to modern JavaScript, and I'm comfortable dropping into an existing codebase and working to your conventions rather than my own. No lengthy ramp-up, no throwaway prototype code - just software built to stay.
Good fit if:
- You've got a smaller product that needs building or running, and you'd rather your team stayed focused on the core one
- You want to test whether an idea's worth building before you commit real budget to it
- You want the person who advised on the architecture to also help build it
