The MVP Trap
There is a well-worn piece of startup advice: ship fast, iterate, do not over-engineer. It is correct. An MVP that never launches helps no one, and a perfectly architected system with no users is just expensive. But the advice has a shadow side — teams that internalize it too deeply build technical debt into the foundation, then find themselves unable to move fast precisely when they need to most.
The challenge is not choosing between speed and quality. It is knowing which decisions are reversible and which are not, and being ruthless about the latter.
The Three Inflection Points
Most products pass through three distinct phases before reaching scale. Each has its own architectural profile.
Phase 1: Zero to First Users
At this stage, your only job is to learn whether the problem is real and whether your solution works. Architecture is almost irrelevant compared to validation speed. Use a monolith. Use managed services. Use a hosted database. Accept vendor lock-in. The cost of a wrong architectural bet is nothing compared to the cost of building the right architecture on top of a wrong idea.
The one non-negotiable is version control and a deployment pipeline. Everything else can be refactored. Code that you cannot confidently deploy cannot be iterated on.
Phase 2: First Users to First Revenue
This is when the irreversible decisions matter. Data model changes become expensive. API contracts, once public, are hard to break. Authentication patterns affect every downstream system. Spend time here.
Specifically: design your data model around your domain, not your current UI. A schema optimised for the first feature will fight you on the second. Identify the core entities — the nouns of your business — and model them correctly from the start.
Also: add observability before you need it. Logs, metrics, and error tracking are not luxuries. By the time you notice that production is broken, you should already have the tools to diagnose why.
Phase 3: Revenue to Scale
Scale problems are almost always database problems. The application tier is easy to scale horizontally — add servers. The database is a shared resource that degrades under load in non-linear ways. Common interventions:
- Read replicas decouple read traffic from write traffic. Route all reads to replicas; writes go to the primary.
- Query optimization often yields 10x improvements before you need to scale infrastructure. Use
EXPLAIN ANALYZE, add indexes where the planner recommends them, and avoid N+1 queries. - Caching at the right layer — Redis for session state and hot-path reads, CDN edge caching for static or semi-static content.
Microservices: When and Why
Microservices are not a scalability pattern. They are a team autonomy pattern. A well-written monolith will outperform a poorly designed microservices architecture on almost every dimension: operational complexity, latency, developer experience, and debugging.
Move to services when — and only when — you have autonomous teams that need to deploy independently, or when a specific component has radically different scaling, compliance, or runtime requirements from the rest of the system. "The microservices tutorials say to do it this way" is not a reason.
When you do break out services, the first extraction should be your least-coupled, highest-traffic read path. Prove the operational model before you proliferate it.
What We Tell Our Clients
The question to ask before any architectural decision is: "What is the cost of changing this later?" If the answer is low, defer. If the answer is high — data models, authentication, core API contracts, observability — invest now.
Build the smallest thing that could possibly work. But build it on a foundation you can stand on.