The startup that hires us is usually in good shape technically. The codebase is organised. The engineers are capable. The product works. What they want from us is help scaling: more users, more markets, more engineers, more complexity. And then, somewhere in that conversation, we find one of three decisions that was made twelve to eighteen months ago and is now quietly constraining everything.
These decisions did not look wrong at the time. They were rational choices made under uncertainty, usually by competent people. The problem is not that they were made badly. The problem is that they were made without a clear understanding of their eventual cost, and that cost compounds invisibly until it does not.
We are not describing edge cases. We are describing the three most common patterns we encounter, in the order we encounter them.
The decisions that scale a startup are rarely the decisions that launched it. The founder who cannot tell them apart will apply the wrong ones at the wrong time.
Decision one: the architecture ceiling
At seed stage, the fastest architecture is usually a monolith. One codebase, one database, one deploy. This is correct. The team is small, the requirements are uncertain, and the overhead of distributed systems would slow down the product iteration that matters most at this stage.
The problem comes when the monolith is not designed to be split. Not every monolith needs to be split. But every monolith should be built as if it might be, which means clear module boundaries, no cross-cutting database queries between domains, and an API layer that does not assume shared memory with the business logic behind it.
The monoliths that create ceilings are the ones where the user service, the billing service, the notification service, and the reporting service have all grown into a single tangle of shared tables and implicit dependencies. When the product needs to scale a specific function, there is no clean seam to cut along. Extracting anything requires touching everything.
| Architecture choice | Right at seed | Right at Series A | Common mistake |
|---|---|---|---|
| Modular monolith | Yes | Often still yes | Skipping the "modular" part |
| Microservices from day one | No | For specific well-understood domains | Premature decomposition |
| Shared database across services | Acceptable | No | Never revisiting this decision |
The fix is not a rewrite. It is a programme of introducing explicit boundaries within the existing system: domain modules with defined interfaces, a strict rule against cross-domain database queries, and a routing layer that treats each domain as if it could be extracted tomorrow. The system stays deployable throughout. The ceiling lifts gradually. For more on the language decisions that often accompany this work, see our piece on Rust versus Go.
Decision two: the wrong first hire
The first engineering hire outside the founding team sets the culture of the engineering organisation. This is not metaphorical. The first hire defines what good looks like, what is acceptable, and what the implicit standards are. Every hire after that is calibrated against the first one.
The wrong first hire is not always a bad engineer. It is often a very good engineer who is wrong for the stage. We see two failure modes frequently.
The first is the enterprise architect: a senior engineer from a large company who brings the processes and standards appropriate for a team of forty into a team of four. The result is a codebase that is well-documented, heavily abstracted, and slow to change. The startup needs to move. The codebase is optimised for correctness at scale, not speed at seed.
The second is the solo star: an exceptional individual contributor who produces a lot of code quickly, takes implicit ownership of large areas of the system, and does not document decisions or build the team's shared understanding. The code is good. But the knowledge is concentrated. When the team needs to grow, there is no foundation to grow on. New engineers are dependent on the star, who becomes a bottleneck and eventually a single point of failure.
The engineer who is right for the first hire is a generalist who can build production systems, has strong opinions about craft, communicates clearly, and actively builds the shared understanding the team will need to scale. They are usually not the most impressive resume in the pile.
Decision three: metrics debt
Metrics debt is the least discussed of the three, and the one that surprises founders most when we name it. It works like this: in the first year, the team ships fast and instruments little. There are users. There is revenue. The product is working. Instrumenting it seems like overhead.
By year two, the team is making product decisions based on incomplete data, running A/B tests they cannot measure correctly, and unable to explain to investors why a specific metric moved. The data infrastructure was never built, and building it now means either a disruptive migration or a parallel system that never quite matches the production data.
The specific things that are almost always missing:
- User-level event tracking with a consistent schema across client and server
- Funnel instrumentation that connects acquisition to activation to retention
- Revenue attribution that links a specific acquisition channel to a specific customer's lifetime value
- A clear definition of the north star metric that the entire team can calculate from raw data independently
None of this is technically difficult. It is consistently deprioritised in favour of features. By the time it matters, the historical data does not exist and cannot be reconstructed.
The common thread
These three decisions share a structure. Each one was made correctly given the information available at the time. Each one has a cost that does not appear immediately and compounds over time. And each one is significantly cheaper to make correctly at the start than to fix later.
The architecture ceiling costs months of engineering time to resolve at Series A. The wrong first hire costs a year of organisational dysfunction and at least one more hire to compensate. Metrics debt costs quarters of operating blind on product decisions that determine whether the company grows or stalls.
None of these is fatal. Startups survive all three. But they consume the company's most valuable resource at the moment it is most scarce: engineering capacity and founder attention, in the window between product-market fit and growth.
What to do instead
For the architecture: build a modular monolith. Define your domain boundaries before you write the first line of code. Treat the interfaces between domains as contracts. They do not need to be APIs yet. They need to be explicit.
For the first hire: write down what you need the engineering culture to look like at twenty people, then hire the person who builds that culture, not just the person who ships the most code in the first six months.
For metrics: instrument every user action from day one. The schema does not need to be perfect. It needs to exist. A simple event table with user ID, event name, timestamp, and a JSON properties column is enough to start. You can build the analytics layer later. You cannot reconstruct history.
These are not complex recommendations. They require discipline rather than expertise. The startups that get them right are usually the ones where the technical founders have seen a scaling company fail at exactly these points and resolved not to repeat the pattern. Experience is expensive. This is a cheaper version of it.