So,
I’m Naveed Ahmed — a CTO based in Sydney.
I’ve spent the better part of the last decade leading engineering at two companies in parallel. At Amaka, I led the transformation of a legacy “client-per-server” integration product into a cloud-native SaaS platform built on Google Cloud — the kind of work that supports tens of thousands of small businesses through integrations with Xero, QuickBooks, Shopify, Square, MYOB, and a handful of others. At BarBooks, I joined as CTO during a turnaround phase: rightsizing infrastructure, untangling Lambda sprawl, and restoring discipline to a codebase that had drifted.
The shorthand version: I take systems that are expensive, fragile, or both — and make them less so.
How I got here
I didn’t start in management. I started in code, working across C#, PHP, Python, JavaScript, and Ruby — and across industries that ranged from finance and e-commerce to education and health. Along the way I picked up the adjacent disciplines that good engineers eventually have to learn: networking, hardware support, system design, IaC on AWS and GCP, and the occasional foray into graphic design when nobody else was around to do it.
That breadth shapes how I think now. The hardest problems in modern software rarely sit cleanly inside one discipline. A database performance issue is sometimes an indexing problem, sometimes a schema problem, occasionally a service-ownership problem. Knowing which lens to reach for first is what separates a one-day fix from a six-month migration.
What I write about here
This blog is my working notebook.
I write about system design – the actual trade-offs behind microservices, iPaaS architectures, and the middleware that sits between platforms that refuse to talk to each other directly.
I write about cloud cost optimisation – not the vendor-blog version, but the kind that comes from staring at a real AWS bill and asking why a service handling modest load is running on instances sized for a workload that never arrived.
I write about SaaS transformation – taking legacy products and refactoring them into platforms that scale economically.
And lately, I write about AI infrastructure and strategy — silicon economics, inference cost, and the structural advantages that decide who actually wins this cycle.
How I write
Three rules I try to hold to:
- No hype. If a technology earns a mention, it earns it on cost, latency, or developer velocity — not on its release week.
- Show the trade-off. Every architectural decision is a choice against something else. I try to name the alternative.
- Code over claims. When a snippet clarifies the point, I ship the snippet.
Why this exists
There’s no funnel here. No course, no SaaS, no consulting retainer behind the writing.
The blog exists because the field benefits from senior practitioners showing their working — and because the next engineer who inherits a Lambda sprawl, an over-provisioned ECS cluster, or a Redis instance being used as a permanent database deserves a reference that isn’t a vendor case study.
