Architecture

I provide independent system architecture consulting: domain modelling, event-driven design, API contracts and data architecture for products that have outgrown their first build. Engagements run from a two-week architecture review to full design-and-build ownership — for clients in India, the UAE and the UK.

When do you actually need an architect?

Nobody hires an architect on day one — and nobody should. You hire one the day the shortcuts start charging interest. The signs are always the same, and I’ve seen them from Bengaluru to London:

• Every feature, regardless of what it does, somehow touches the same three tables — and the engineers have started padding estimates because they know it.
• The “temporary” queue from 2023 is load-bearing, and nobody remembers all its consumers.
• Deploys need a WhatsApp group, a rollback plan nobody’s tested, and a prayer.
• One engineer understands the core. Their leave calendar is your risk register.
• The last two big initiatives quietly died in “refactoring first” — the foundation eats every roadmap that lands on it.

None of this is bad engineering. It’s success arriving faster than structure — the shortcuts were correct when you took them, because the alternative was not shipping. But jugaad architecture compounds like informal credit: quietly, and then all at once. The skill isn’t avoiding debt; it’s knowing which debts to pay before they call themselves in.

What does the service include?

• Architecture review. Two weeks, every major flow traced end to end, a written verdict you can act on without hiring me again: what’s sound, what’s dangerous, and the fix sequence with reasoning. The verdict names the three findings that matter most at the top — because a forty-page report with no priorities is a filing cabinet, not a deliverable.
• Domain modelling. The entities and events your business actually runs on — drawn from how money and goods really move, not from the org chart. This is the highest-leverage work in the whole discipline: the wrong entities calcify into every feature built on them, and un-calcifying them later is the expensive surgery everyone’s avoiding.
• Event-driven design. Where events earn their complexity — audit trails, replay, integration seams — and, just as important, where a boring CRUD service is the right answer. The failure modes are predictable and I’ve written the tuition guide: Event-driven pitfalls covers ordering, replay and poison messages, the fees everyone pays at least once.
• API contracts. Versioned, typed, honest about failure modes — contracts your integration partners can build against without a call, and your own teams can’t quietly break. Half of “our microservices are unreliable” is actually “our contracts are vibes”.
• Data architecture. One source of truth per fact, projections for speed, and the discipline about which is which. When the cache and the truth disagree, the system should already know which one wins — if that decision happens during an incident, it happens wrong.

How do you approach a system you’ve never seen?

I start from the money path. Every business has one flow where value actually moves — the order that becomes revenue, the loan that becomes a receivable, the trade that becomes a position. That flow is the one that can’t be wrong, so it gets modelled first, in double-entry discipline even outside fintech — because “where did this number come from” is a question every system eventually faces, and append-only truth is the only good answer. The rest of the architecture hangs off that spine. It’s the same thinking that runs my fintech engineering practice; architecture is just that discipline generalised beyond money.

The obvious alternative is modelling the org chart — one service per department, because the meeting invite list looked like a system diagram. That’s how you get eight services sharing one database and calling it microservices: all of the operational cost, none of the independence. Service boundaries follow data-change-together lines, not reporting lines. Getting this wrong is the single most expensive architecture mistake of the last decade, and undoing it pays for a lot of two-week reviews.

Schemas before slide decks. I read the database first, because schemas don’t lie — the deck says event-driven, the schema says forty nullable columns on a table named orders_v2_final. The gap between the two is usually the review’s first finding. It’s the same skill as the published teardowns: reading systems accurately from their artefacts — I’ve done it in public fourteen times, from Kaspi running a super-app on a monolith heart to Stripe’s API discipline, so you can audit exactly how I read a system before showing me yours.

Complexity is a budget, and most systems overspend it in the wrong place. The review regularly prescribes less architecture than the team expected — fewer services, fewer queues, one database held properly. Every component you don’t run is one that can’t page you at 3 AM. The goal is a system that’s exciting to your customers and boring to your on-call rotation; in infrastructure, excitement is a defect.

What happens after the review?

Every engagement, whichever path, produces a running decision log — each significant choice with its reasoning, its alternatives and its revisit-trigger written down. Teams inherit architecture through documents, not osmosis; the log is what makes my leaving safe.

Three paths, your choice. Execute internally — the verdict is sequenced so your team can run it; I stay available for design questions at a light cadence. Design-and-build — I own the core implementation alongside your engineers, typically the domain model and the money path, with the knowledge landing in their heads and in decision logs, not just in the code. Standing advisory — for teams that want the senior pair of eyes continuously: /services/advisory covers that shape, and /services/fractional-cto covers the version with delivery accountability.

And when the review uncovers a migration — it usually does — the method is already written: strangler-pattern replacement, parallel runs, diff-zero cutovers. The zero-downtime migration article has the recipe; the migration case study has the receipts.

When should you NOT hire me?

Three situations where this service is the wrong spend, said out loud so the right ones stand out. Pre-product-market-fit — your architecture should be embarrassing right now; structure before traction is premature optimisation with an invoice, and the honest advice is a one-hour call, not an engagement. When the problem is people, not systems — if two teams can’t agree on ownership, a new service boundary just gives the argument better vocabulary; I’ll say so in week one rather than bill through it. When you want validation, not a verdict — the review exists to change decisions, and if the rebuild is already funded and announced, a report blessing it is theatre I don’t sell. What’s left is the real market for this work: systems carrying real load, teams willing to hear “less architecture, better held”, and decisions still open enough to change. Barobar? Then read on.

What’s the proof?

• Fourteen published architecture reviews of companies that got it right at scale — the deep-dive series on Stripe, Revolut, Monzo, Nubank, Mercado Pago, Kaspi, PhonePe, OPay, TymeBank, Airwallex, Afterpay, Visa, Mastercard and LemFi: read them. Kaspi’s monolith carrying a super-app, PhonePe surviving UPI’s volume — NPCI’s published data had UPI past fifteen billion transactions a month in late 2024 (npci.org.in) — the same reading eye points at your system.
• The ledger rebuild and the ERP migration — architecture verdicts executed to production.
• The portfolio system — event-sourced truth with live projections, the pattern this page keeps recommending, running in practice.

Related reading

Event-driven pitfalls · Ledger design · Zero-downtime migration · Postgres in production

Send the ugly diagram

Send me your real architecture diagram — the one with the dotted lines and the question marks, not the one from the pitch deck. Book the review. No judgment; the ugly diagram is why the work exists, and seedhi baat — if two weeks of reading says your system is fine, that verdict is worth having in writing too.