From Startup to Scale: Engineering Decisions That Don't Age Well
Speed is a legitimate competitive advantage at the startup stage. Moving fast, shipping before you're ready, and taking on technical debt in service of learning: these are correct decisions in the early days.
But some shortcuts compound in ways that aren't obvious until they become existential. Here are the ones we see most often in the codebases of growth-stage companies we're called in to fix.
The N+1 Query Problem
You're doing one database query to fetch users, then one more for each user's posts. At 100 users, it's a 200ms response. At 10,000 users, it's a timeout. Use query profiling from day one and learn to spot N+1 patterns before they're in your critical path.
Synchronous Everything
Your payment processing blocks your API response. Your email sending blocks your write endpoint. Your third-party API calls can take 5 seconds and bring down your server. Everything that doesn't need to be synchronous should be asynchronous. Get familiar with job queues (Sidekiq, BullMQ, Celery) early.
The Monolith is Fine, Actually
Microservices are a solution to an organizational scaling problem, not a technical one. A well-structured monolith will comfortably serve you to hundreds of millions of requests. Don't introduce the operational complexity of microservices until you have teams large enough to own each service.
Schema Migrations in Production
"I'll just ALTER TABLE this real quick in production." Famous last words. At 10GB tables, this locks your database. Learn zero-downtime migration patterns (expand-contract, shadow tables) before you need them.
No Observability
If you can't answer "is anything broken right now?" within 30 seconds, you have a monitoring problem. Set up structured logging, metrics, and alerting from week one. It will save you days of debugging later.
The Right Mindset
Build for the next 10x, not the next 100x. Over-engineering for speculative scale is as dangerous as ignoring it entirely. Ship, measure, and refactor with data.