April 14, 2026
Small teams do not need heroic engineering
They need boring infrastructure, clear ownership, fewer moving parts, and enough discipline to avoid creating problems they cannot afford to maintain.
Heroics are a tax
Heroic engineering feels productive: late nights, clever fixes, war stories. For a team of one or three, heroics are also a warning sign. You are compensating for unclear ownership, too many services, or a system nobody can debug without the person who built it.
Small teams do not win on complexity. They win on clarity and recovery.
What actually scales down
Boring infrastructure means managed Postgres, a single app boundary, and deployment you can explain in one sentence. Fancy only where the business demands it.
Clear ownership means one place for auth, one place for billing, one owner for on-call—even if that owner is you on your phone.
Fewer moving parts means resisting the queue, the extra microservice, and the dashboard nobody opens. Every piece you add is a future 2 a.m. you.
I ship LynCareer, Lynfolio, DevSnap, and client work with this bias: someone who was not in the room for the first commit should still be able to reason about failures.
Bias to shipped learning
When risk is unknown, I cut a thin vertical slice: one workflow, observability, and a definition of done tied to usage—not slides. Scope cuts are not compromise; they are how you learn before you decorate.
How to apply it
- List every service and integration; delete or defer anything without a named owner.
- Prefer one deployable unit until pain proves you need a split.
- Document the seams: env vars, backups, and how to roll back.
- Measure after launch; refine from usage instead of adding architecture “for later.”