Home → Fractional CTO
Growth breaks engineering in predictable ways. The architecture that fit ten engineers stops fitting forty. Releases get slower as the team gets bigger. Incidents start eating the roadmap. I step in as a part-time engineering leader and fix the foundations — while staying hands-on enough to write code, review PRs and shape system design alongside your team.
Lead time creeps up quarter over quarter. Estimates stop meaning anything. Nobody can say with confidence what ships next month, and release day has become an event people brace for.
Architecture that was right for the first product no longer carries the traffic, the team size, or the roadmap. Every new feature touches five services and three teams.
On-call is exhausting the senior engineers. Postmortems repeat themselves. The same class of failure keeps returning because nothing structural changed after the last one.
The bill grows faster than usage and nobody owns it. Right-sizing is a quarterly panic rather than a property of how workloads get built and deployed.
Hiring worked; structure did not follow. No clear ownership model, no career framework, no shared definition of what good looks like — so quality depends on who picked up the ticket.
Plenty of experiments, no adoption. The gap is rarely the model — it is context, evaluation, and the engineering discipline to run it as a product rather than a demo.
How involved I am, how long we work together, and what we focus on depends entirely on what you are trying to solve. Every engagement starts with a conversation, not a proposal.
Part-time engineering leadership alongside your existing team. I own the architecture decisions, build the operating model — ownership, rituals, career framework, delivery governance — and make sure engineering stops being the thing that slows the business down.
Fits when engineering has outgrown ad-hoc leadership but does not yet justify a full-time executive hire.
A focused review of where the platform is today, where it needs to go, and how to get there without burning the house down. You get a written assessment, a target architecture, and a sequenced migration path with the risks named. Practical, not theoretical.
Fits when you know the platform needs to change but disagree internally on what and in what order.
Fixing how teams plan, build and ship — hiring and squad structure, CI/CD, observability, release quality, on-call. The unglamorous foundations that decide whether growth is manageable or chaotic.
Fits when the people are good and the process is what is failing them.
Cutting through the noise to find where AI genuinely pays in your product and your engineering workflow — then building it so it is cost-effective and maintainable by your team after I leave. Context and evaluation first, tooling second.
Fits when there is pressure to "do something with AI" and no agreed definition of what good would look like.
A delivery baseline using DORA metrics, an architecture and cloud cost review, and conversations with engineers, product and the executive team. What people tell you and what the data says are rarely the same, and the gap is usually where the real problem lives.
A written assessment: what is actually constraining delivery, what is structural versus circumstantial, and what will get worse if left alone. Named, prioritised, with the trade-offs stated plainly rather than softened.
A 90-day plan that orders the work by leverage — what unblocks the most, soonest, at the least risk. Some of it I lead. Most of it your team leads, which is the point: the change has to hold after I stop showing up.
Fifteen years leading engineering across iGaming, fintech, logistics, insurance and capital markets — Singapore, Bangkok, Jakarta, Nairobi, Dubai. Currently leading a 50+ person engineering organisation through a full transformation mandate.
Rewrites by default. A rewrite is occasionally the right answer and usually an expensive way to avoid a diagnosis. I will argue for incremental re-architecture until the evidence says otherwise.
Staffing. I do not place engineers or sub-contract delivery. The work is making the team you already have more effective.
AI for its own sake. If AI does not clearly pay for itself in your product or your engineering workflow, I will say so rather than build you a pilot that quietly dies.
Decks as deliverables. The output is a team that ships better and a platform that holds. Documents exist to serve that, not to stand in for it.
Everything a full-time CTO does — architecture decisions, engineering operating model, delivery governance, hiring shape, vendor and cloud decisions — on a part-time basis. The difference is scope of time, not scope of responsibility. In practice it suits companies whose engineering has outgrown ad-hoc leadership but does not yet justify a full-time executive hire.
A consultant usually produces a recommendation and leaves. I stay accountable for the outcome — sitting in your architecture reviews, your delivery rituals and your incident retros until the change holds without me. The deliverable is a team that ships better, not a deck.
Yes. I review PRs, shape system design alongside the team, and write code where it helps — usually foundations: workload templates, CI/CD pipelines, infrastructure modules. Staying in the codebase is what keeps the architectural advice honest.
Your existing team. The goal is to make the engineers you already have more effective — better structure, clearer ownership, faster feedback loops. I do not sub-contract delivery or place engineers.
Deepest experience is in iGaming, fintech, logistics and insurance — high-frequency, low-latency, consumer-facing platforms where downtime is expensive. I have led engineering organisations in Singapore, Thailand, Indonesia, Kenya and the UAE, and work remotely with distributed teams across time zones.
With a conversation. From there the usual first step is a short diagnostic — a delivery and architecture baseline, plus interviews with engineers and stakeholders — which produces a written assessment and a sequenced plan. What follows depends on what that surfaces.
Whether you're in London, Singapore, San Francisco or anywhere in between — if the problem is worth solving, let's talk. I work remotely with teams worldwide.
Based in Dubai · Available globally · +971 585 638 114