When You're Outgrowing This Scale

In one line: When your engineering org passes 50 people, teams routinely block each other, monolith deploys feel risky, and on-call exhausts a single brain — you've outgrown the small-company workflow.

In plain English

The small-company workflow has natural limits. The patterns that worked at 20 engineers start to creak at 60. Recognizing the signals early lets you transition deliberately instead of in crisis. The next chapter — Large Company Workflow — covers what changes.

Signs you've outgrown the small-company workflow

Signs you're approaching the next stage:

• Engineering org > 50 people. Communication overhead is constant. Decisions take days, not hours.
• Multiple teams routinely block each other. "We're waiting on the platform team" becomes a regular phrase.
• The monolith deploys are getting risky. Every deploy touches code from 20 engineers.
• You're considering microservices for real reasons. Different teams need different deployment cadences; different services have wildly different scaling needs.
• Compliance work is consuming significant time. SOC 2, HIPAA, PCI all stack up.
• You have on-call but it's exhausting. A single engineer can't reasonably understand the whole system.

That's when Chapter 13: Enterprise becomes relevant.

Wrapping Up Part 11

Small-company web development in 2026 is a sweet spot. The tooling is mature, the patterns are well-understood, and a small team can ship genuinely impressive software:

• Pick the dominant stack (Next.js + Postgres + Vercel + Supabase + managed services).
• Build a modular monolith.
• Add process when missing it causes pain.
• Lean on managed services for everything not central to your differentiator.
• Maintain code quality through review and testing.
• Monitor production from day one.
• Plan for the next year, not the next decade.

The hardest discipline: resisting both extremes. Don't be sloppy like a personal project; don't be heavyweight like an enterprise. Stay in the middle, where execution speed is highest.

Worked example: a clean graduation

A startup hits 55 engineers. The CTO notices three signals over one quarter:

1. Two teams blocked each other on a shared module three times in a month.
2. A bad deploy took down the app for 12 minutes because the monolith merge bundled fifteen people's changes.
3. SOC 2 work is now consuming one full engineer's time, but they have no security org to own it.

Instead of waiting for things to get worse, the CTO starts a deliberate transition: spin up a small platform team, extract two services from the monolith (the two that scale very differently), and hire a security lead. None of these moves are "we became an enterprise overnight" — they're surgical responses to specific signals.

Three months later, the team is operating under more of the patterns in Chapter 12. The transition was uncomfortable but not catastrophic.

Highlight: graduating gracefully beats graduating in crisis

Most companies don't notice they've outgrown their workflow until something breaks badly — a major incident, a key hire quitting, a missed deadline. The hard skill at this stage is noticing the signals early and acting on them before the crisis.

The signals listed above are the leading indicators. Watch them quarterly. When two or three are flashing red, start the transition — don't wait for the fourth.

Common mistakes

Where people commonly trip up

• Declaring "we're an enterprise now" the moment you hit 50 headcount. Headcount alone isn't the signal — pain is. A 60-engineer team without blocking dependencies or risky deploys can run small-company patterns longer; a 35-engineer team with a brittle monolith may need enterprise practices sooner. Watch the symptoms, not the org chart.
• Treating the transition as a wholesale rewrite. "We need to be enterprise" turns into a six-month re-platforming project that ships nothing. Pick the two most painful signals, address them surgically, and let the rest of the workflow keep working until it doesn't.
• Promoting your strongest IC to "VP Engineering" to handle scale. Running an org and writing code are different jobs. Forcing the transition on someone who didn't want it loses you the IC and the manager. Recruit externally for management roles you don't have internal interest in.
• Believing you'll get to enterprise practices "after this launch." The next launch always exists. If you're three signals deep into the outgrowing list, the transition has to happen during the work, not after — or the next big incident makes the decision for you.
• Losing the speed advantage that got you here. Enterprise patterns add coordination cost on purpose. The risk is over-correcting: adopting RFCs for every change, ARBs, multi-week planning cycles. The goal is to layer in just enough enterprise to keep the wheels on — not to become the company you were rebelling against at 10 people.

Page checkpoint

Checkpoint Quiz

Did the outgrowing signals stick?

Required

What's next

→ Continue to Chapter 13: Enterprise — what changes when you scale to enterprise: hundreds of engineers, regulatory compliance, massive infrastructure.