Chapter 12: Case Study: The SDLC in a Five-Person Startup

Why this matters

Every principle in this book has been presented abstractly or in isolated examples. This chapter and the next make them concrete by walking through the same underlying set of decisions — process model, requirements, design rigor, testing strategy, deployment approach, operations — for two genuinely different contexts, starting with a small, early-stage startup. Seeing the same framework produce a very different, but equally reasonable, set of choices is the clearest way to internalize Chapter 3's "match process to context" lesson.

The context

Five engineers, building a B2B SaaS product, pre-product-market-fit — the team doesn't yet know for certain which features customers actually want, and the primary business risk is building the wrong thing slowly, not building the right thing unreliably.

Process model (Chapter 2-3)

Choice: lightweight Kanban, informal daily syncs instead of formal Scrum ceremonies.

Reasoning: five engineers who talk constantly already have full shared context — formal sprint planning and review ceremonies would be pure overhead relative to just... talking to each other throughout the day. Kanban's continuous flow fits well since priorities shift rapidly based on immediate customer feedback, in a way that doesn't respect fixed two-week sprint boundaries gracefully.

Requirements (Chapter 4)

Choice: lightweight, conversational requirements captured directly in a Jira ticket's description — no formal spec documents, no extensive acceptance criteria for most work.

Reasoning: with the founder/product lead sitting three desks away from the engineers, ambiguity gets resolved in a two-minute conversation rather than needing to be preemptively eliminated in writing — the cost of under-specifying is low (a quick clarifying question) relative to the cost of over-investing in documentation for requirements that will likely change again next week based on customer feedback anyway.

Design (Chapter 5)

Choice: design happens as a whiteboard conversation or a brief Slack thread for most features; a short written design doc only for something genuinely foundational (like the initial choice of database and core data model).

Reasoning: most features are small enough that a 10-minute conversation surfaces any major design issue; the team explicitly invests more design rigor specifically in the few decisions that would be expensive to reverse later (Chapter 9's point from the companion Database book about schema/technology choices being high-stakes, hard-to-reverse decisions).

Testing (Chapter 7)

Choice: solid unit test coverage for core business logic, minimal integration tests, no dedicated QA/UAT process — engineers manually verify their own features before shipping.

Reasoning: the team can't afford dedicated QA headcount at this size, and the primary risk (building the wrong thing) isn't one testing addresses anyway — testing effort is deliberately weighted toward preventing regressions in core logic that's expensive to debug in production, while accepting more manual, informal verification for UI-level correctness given the team's size constraints.

Deployment (Chapter 9)

Choice: continuous deployment — every merge to main deploys to production automatically, multiple times per day, using feature flags for anything not fully ready for all users.

Reasoning: at this size and stage, speed of iteration is the dominant priority, and the team's small, well-understood codebase makes frequent deployment genuinely low-risk (small changes, per Chapter 9's core argument) — there's no case for the overhead of canary/blue-green infrastructure at this traffic scale and team size.

Operations (Chapter 10)

Choice: informal on-call — whoever built a feature is generally the first line of response if it breaks, with the whole team reachable via a shared Slack channel; no formal PagerDuty rotation yet.

Reasoning: at five engineers with low overall traffic, formal on-call rotation infrastructure would be premature process overhead — the team is small enough that "who do we ping" is trivially solved informally, though this is explicitly flagged as something to formalize once the team or traffic grows meaningfully (directly Chapter 3's point about revisiting process choices as context changes).

Common mistakes

1. Assuming a startup at this stage needs "less process" uniformly across every dimension, rather than recognizing the team deliberately invests more rigor specifically where the stakes are genuinely high (the core data model choice) and less where they're genuinely low (most feature requirements).
2. Copying a larger, more mature company's process wholesale (formal Scrum ceremonies, a dedicated QA team, canary deployments) without recognizing these carry real overhead disproportionate to this team's actual size and risk profile.
3. Treating the informal on-call approach as a permanent, correct-forever choice rather than an explicitly context-dependent one that should be revisited as the team and traffic grow.
4. Not recognizing that "lightweight" doesn't mean "no process at all" — this team still has deliberate choices at every stage, just calibrated to genuinely lower stakes and smaller coordination needs than a larger organization would face.

Discussion / interview questions

1. "How would you structure the SDLC for a five-person, pre-product-market-fit startup?" Strong answer: Lightweight process throughout (Kanban over Scrum, conversational requirements, minimal formal design except for high-stakes/hard-to-reverse decisions), continuous deployment for fast iteration, and testing focused on core logic rather than comprehensive coverage — reasoning explicitly from the team's actual size, stakes, and dominant risk (building the wrong thing, not building unreliably).

2. "Why might a small startup deliberately invest more rigor in a database/architecture decision than in most feature requirements?" Strong answer: Some decisions (core data model, foundational technology choices) are expensive and hard to reverse later, while most feature requirements will likely change again soon based on customer feedback — rigor should be calibrated to how expensive a mistake would be to fix, not applied uniformly regardless of stakes.

3. "Why might continuous deployment be a reasonable default for a small startup even without canary or blue-green infrastructure?" Strong answer: At small scale, small, well-understood, frequent changes are inherently low-risk (per Chapter 9's core deployment-risk argument), and the overhead of canary/blue-green infrastructure isn't yet justified by the team's traffic scale or complexity — speed of iteration is the dominant priority at this stage.

4. "What would you flag as needing to change as this five-person startup grows to fifty engineers?" Strong answer: Informal on-call would need to become a formal rotation; conversational requirements would likely need more structure as more people (with less shared context) are involved; some design decisions might need more formal review as more teams depend on shared components — directly Chapter 3's point about revisiting process choices as context evolves.

Chapter summary / cheat sheet

• A five-person, pre-PMF startup reasonably chooses lightweight process almost everywhere: Kanban over Scrum, conversational requirements, minimal formal design (except for genuinely high-stakes, hard-to-reverse decisions), core-logic-focused testing, continuous deployment, and informal on-call.
• The dominant risk (building the wrong thing slowly) shapes every choice — process overhead is minimized specifically where the cost of informality is low and speed of iteration matters most.
• Rigor is still deliberately applied where stakes are genuinely high (foundational architecture decisions) — "lightweight" doesn't mean "no judgment," it means calibrated judgment.
• Every choice in this case study is explicitly flagged as context-dependent, expected to evolve as the team and product mature — not a permanent, one-size-fits-all answer.

---