I’ve spent ten years building platforms for other people’s companies. The whiteboard architecture, the one you’d draw with unlimited time and a clean account, has never once been the one I shipped.
Koo had a fixed four-month window and one shared central database that 40-plus services leaned on. Tokopedia’s migration finished with the team split between Jakarta and India during COVID. A securities brokerage in Indonesia wanted Kubernetes on Nutanix in their own data centre, no managed control plane, non-negotiable. A marketing-technology SaaS company had about 150 services spread across EC2, EKS, and Lambda in three regions and needed to know, in a week, what would break if they moved.
Every one of those constraints looked like the annoying part. Every one of them turned out to be the design.
The constraint tells you what to build
At Koo, the shared database was the risk. So the whole migration plan bent around it: sequence services by how tightly they were coupled to it, dual-run where we could, and cut over the database last with a rehearsed rollback. If we’d started from “ideal target architecture” we’d have decomposed the database first and blown the window.
At the brokerage, no managed control plane meant we owned the OS, the upgrades, the storage layer, and node enrolment. Uncomfortable. It also meant no surprise provider maintenance during trading hours and full control over the traffic path. Constraint and feature, same sentence.
The pattern holds often enough that I now start discovery by asking for the constraints before the goals. Goals are aspirational. Constraints are true.
Discovery is where you earn the design
Two weeks on-site with a logistics-technology company in India, walking through application dependencies, security posture, and how deployments actually happened (as opposed to how the wiki said they happened). Out of that came a target GCP architecture and a TCO model their leadership could decide on. The migration itself was later deferred for commercial reasons, and the discovery was still the most useful thing we did for them, because it told them what a move would cost and where the risk sat.
I’ve seen architects skip this and design from the diagram the client sent. The diagram is always 18 months old.
Design for the team that stays
The other constraint people forget: you leave. The client’s engineers don’t.
At the brokerage we finished the migration and security hardening, then handed over SOPs, runbooks, and structured knowledge transfer so their team could operate and extend the platform without us. Then they kept me on a year-long advisory retainer, which I take as a sign the handover was real rather than a PDF.
A platform the client’s team can’t run is a platform you’ll be paged about from a different company. Design for their skills, their headcount, and their on-call reality, or you haven’t designed for production.
What I’d tell a first-year field engineer
Ask for the constraints first. Write them at the top of the design doc, above the goals. When someone proposes the whiteboard version, check it against that list before you check it against best practice.
Best practice is what you do when nothing is in the way. Something is always in the way. That’s the job.