The SDLC

You validated a solution. You handed it off. You went dark until someone told you "it's done." And what shipped wasn't what you validated.

If you've lived that, you already know why this page exists.

The software development lifecycle, the SDLC, is the path your validated idea walks from a card on a backlog to working software in front of a real customer. (The backlog is the prioritized list of validated work waiting to be built; a card is one item on it.) The stages below are that lifecycle, walked in order. Every team runs some version of it whether they name it or not. Your job is not to write the code. Your job is to know the path well enough that when something on it goes sideways, you can see it.

"That's the engineering manager's job, not mine." I hear you. And you're half right. You don't own the build.

But you own the outcome. You're the one who validated this thing. You're the one who told the business it was worth doing. If you can't tell a healthy dev process from cargo-cult theater, you can't protect the outcome you just fought for. You'll find out it broke at the demo, with everyone watching, and by then it's too late to do anything but apologize.

So here's the whole path, stage by stage. This is breadth, not depth. For each stage I'll show you what healthy looks like and the failure mode waiting for you if you look away. We'll get into the deep mechanics on the next two pages, agile and just-in-time. (Agile, for now, is an approach built around shipping small slices fast and adjusting as you learn; the next page unpacks it.) This page is the map.

The team that builds it

Before the path, the people on it.

A normal agile dev team is small. Product owner or product manager, a product designer, a full-stack tech lead, two or three engineers, and QA. That's it. Five to nine people who can own a product, or own a slice of a much bigger one.

I want to be clear about the size, because people get this wrong. We're not talking about a full engineering department here. We're talking about a single team. A department is a stack of these teams, each one small enough to actually communicate. You built and hired this team back in Part 01, so go back and review that part if the shape feels fuzzy. Here, just hold the picture: small, cross-functional, and built so the work is visible to everyone on it.

A healthy team carries at least three different backgrounds, because nine people who all think the same way will build the same blind spot nine times. The version that goes wrong is the team so big nobody knows who owns what, or so uniform it can't see its own gaps.

The hand-off, and refinement

The path starts where Part 04 ended. A validated solution comes off the opportunity backlog, and now the team has to actually understand it.

This is the seam where most of the damage happens. The PM knows the problem cold. The team knows nothing yet. Refinement is the conversation that closes that gap: you walk the team through what was validated, why it matters, and what "done" would even mean, and they push back, ask the hard questions, and find the holes you didn't.

You know it worked when the team can re-explain the problem back to you in their own words before anyone writes a line of code. You know it failed when you get the silent hand-off instead: you toss the card over the wall, go dark, and three people quietly build three different interpretations of one vague sentence.

Planning with product

Once the team understands the work, you plan it together. You refine the backlog, break the big stuff down, and size it so it fits in a cadence (the team's regular working rhythm, often a one- or two-week sprint) the team can actually run.

At the map level, the one thing that makes planning healthy is who owns it. The team that's going to build the work commits to the work, sizes it, and believes it. The plan is theirs, not a date handed down to them. The mechanics of sprints, planning, and how sizing actually works are the whole next page, so I won't repeat them here. Just hold the test: a healthy plan is one the builders signed up for. The failure mode is a plan that's really a date someone promised a customer, worked backward into tasks nobody believes.

Writing the code

Now they build. And the single most important thing about how good teams write code is that they write it in small, reviewable pieces.

Not because small is cute. Because small is honest. A small change is one you can actually review, test, and ship without holding your breath. A giant change is a place for bugs to hide.

What good looks like: changes land in small, single-purpose pieces, each one shippable on its own.

The failure mode: the two-week branch nobody's seen, dropped on the team the night before the demo. (A branch is a separate working copy of the code where someone develops in private before folding it back into the shared codebase. The longer it sits unseen, the more it can hide.)

Code review and pull requests

Every change gets read by another person before it merges into the shared code. The mechanism is a pull request: a request to fold one person's change into the codebase that a teammate reads and approves first. ("Merge" is just that folding-in.)

The bar for a review is not perfection. In Google's own words, from their engineering practices, a reviewer should approve once the change "definitely improves the overall code health of the system being worked on, even if the change isn't perfect." Reviews exist to keep the codebase getting healthier over time, not to let one person block another over a comma. Good reviewers look at the same set of things every time: design, functionality, complexity (is the change harder to follow than it needs to be), tests, naming, consistency. And they keep the change small. Google's rough guide: around 100 lines reviews comfortably, 1,000 is usually too big to review well.

This is one I run hard on my own builds. On the toolkit I use to ship apps, code review is its own gated stage, plus an AI reviewer on every pull request, and I never auto-apply the AI's findings. It surfaces them, I decide. You drive.

What good looks like: small, single-purpose pull requests with a clear description of what changed and why, reviewed against the health of the codebase, not someone's personal taste.

The failure mode: the rubber-stamp "LGTM" on a thousand-line change nobody actually read, or the opposite, a reviewer who blocks the merge over style preferences a style guide should have settled.

Testing

Tests are how the team changes the code tomorrow without fear of breaking it today.

The shape to aim for is the test pyramid: a wide base of fast, cheap unit tests (each one checks a single small piece of code in isolation), a thinner layer of integration tests (these check that several pieces work together), and a small number of slow, expensive end-to-end tests (these run the whole flow the way a real user would) for the flows that really need them. Cheaper layers carry more of the load, because they run fast and don't fall over every time you touch the UI.

Now, coverage. People love to turn coverage into a trophy. Don't. Martin Fowler is blunt about this: coverage is "a useful tool for finding untested parts of a codebase" but "of little use as a numeric statement of how good your tests are." The moment you make a coverage number a target, people write junk tests to hit it. Forced 100% coverage, in his words, "smells of someone writing tests to make the coverage numbers happy." The real signal that testing is working isn't a percentage. It's that the team ships few bugs and changes code without flinching.

What good looks like: tests catch regressions before a human does, and coverage is used to find untested code, not to score the team.

The failure mode: "we have 95% coverage" on a suite of tests that assert nothing, and production still catches fire.

QA

QA is the dedicated craft of trying to break it before a customer does.

The honest version of QA is two things working together, not one. Automation verifies what you expect: regression checks, the repeatable stuff, performance. Exploratory testing discovers what you didn't expect: the weird edge case, the unscripted path, the state nobody thought to write a test for. Atlassian frames it exactly this way, and it's right. Automation handles the repetitive checks a human shouldn't re-run by hand; skilled human attention goes to investigation. Good QA isn't "automate everything." It's automating what's stable and repetitive, and pointing a sharp human at the rest.

The strongest QA idea I run is an evidence requirement. On my toolkit, every acceptance criterion has to point at real proof: an actual test name, a screenshot, a comment. A script checks that the evidence exists before QA can pass at all. "QA passed" with no evidence behind it isn't passed. It makes "done" provable instead of a feeling.

What good looks like: automation covers the repeatable paths, a skilled tester hunts the edges, and "done" is backed by evidence anyone can check.

The failure mode: QA as a vibe check. Someone clicks the happy path once, says "looks good," and the empty-state crash ships to your biggest customer.

Security

Security isn't really a point on the path. It cuts across the whole thing, designed in at every stage above instead of bolted on at one. I'll list it here so it has a home, but treat it as a thread running through all of them. The other thing to know: this stage leans on a credited industry baseline plus the real stack I use, because my own lived war stories here are thin and I'd rather say so than fake them.

The baseline is OWASP (the Open Web Application Security Project, an open community that publishes shared security standards). Their Top 10 is the shared awareness list of the most critical web-app risks, and the move is to design against it instead of patching after the fact. Two principles carry most of the weight. Secure by design: threat modeling and secure patterns built in, not bolted on. And secure by default: the app ships locked down, so security isn't something a user has to opt into. That's the standard. Credit OWASP, build to it.

On top of that, good teams automate scanning into the pipeline, because no one tool catches everything. Static analysis reads the source code for flaws without running it. Dynamic analysis probes the running app like an attacker would. Software composition analysis checks the code you depend on but didn't write, your third-party dependencies, for known holes you shipped without realizing. And secret scanning blocks committed credentials (passwords or API keys accidentally saved into the code) before they leak. Four different scans, four different blind spots covered.

Here's my real stack, so you can see what this looks like in practice and not just in theory. I built a security stage with three specialized review agents, each with a different lens, plus a lead that consolidates them and makes the pass-or-fail call. Nothing critical or high ships. Alongside the agents I run real tools: Trivy for dependency vulnerabilities, gitleaks for secret scanning wired in at two points (it blocks on the developer's machine before a change is even saved, and again on the shared server before it merges), CodeRabbit for AI code review, and Aikido for static and secret scanning. I split one broad security reviewer into three narrow ones for a specific reason: the single broad reviewer caught nothing specific. Three sharp lenses beat one blurry one.

What good looks like: the OWASP risks are designed against, not patched after; the app is secure by default; and automated scans run on every change, tied to what actually changed rather than to someone remembering to run them.

The failure mode: security as a final gate someone runs once, the week before launch, when it's far too late and far too expensive to fix what it finds.

DevOps, CI/CD, and release

This is the machinery that takes the reviewed, tested, secured code and gets it in front of a customer, reliably and on demand. CI/CD stands for continuous integration and continuous delivery, the two halves of that machinery, and DevOps is the broader practice of joining development and operations so a team can ship reliably.

The target, in the words of DORA (Google's long-running research program on what makes engineering teams perform), is continuous delivery: "the ability to release changes of all kinds on demand quickly, safely, and sustainably." The software is kept deployable the whole time, not stabilized in a panic at the end. The practices that get you there are small, frequent commits (a commit is one saved change folded into the shared code) to a shared trunk (the single main copy of the code everyone works off of), continuous integration running fast automated tests on every commit, and working in small batches, all backed by automation so a release is routine instead of an event. The tell of a healthy team: when the build goes red, fixing it is the most important thing anyone is doing.

My own CI is leaner than that, on purpose, because I'm shipping desktop and mobile apps, not running a fleet. It's lint, then build, then test on every change, secret scanning on every push, and a build process that signs and notarizes the binary (a notarized binary is one a platform like Apple has checked and approved so a user's machine will trust it), with the human confirming before anything merges. I don't run cloud infrastructure or a production fleet, so my devops is build-sign-ship-the-binary, not run-a-service. The baseline above is what good looks like when there is a service to run.

And here's why this stage matters to you specifically, not just to the engineers. You cannot be empirical if you can't release. The whole reason the validated idea exists is to get in front of a real customer and learn. A team that can't ship on demand can't learn on demand. That's the thread that ties this stage straight back to agile, and we pick it up on the next page.

What good looks like: the system is always in a releasable state, releases are small and routine, and a red build is the team's top priority.

The failure mode: the big-bang release. Months of work merged at once, deployed on a Friday, with a rollback plan that's a prayer.

Observability and monitoring

The code shipped. You are not done. You're now blind unless you instrument for it, and this is the stage I want you to actually feel, because it's the one PMs skip and it splits cleanly in two.

The dev side: catch the failures. Instrument the system so the team can answer "what's wrong and why" from telemetry instead of guessing. The standard frame is logs, metrics, and traces working together: logs give you the context, metrics tell you something's off, traces show you where it broke. Google's SRE team (the engineers who keep Google's services running, who wrote the book much of this practice comes from) boils the must-watch set down to four golden signals: latency (how slow), traffic (how much demand), errors (how often it's failing), and saturation (how full the system is, how close to its limits). Good means structured logs and error tracking that alert the team to a failure before a customer emails about it.

I'll be honest: this is a real gap in my own current stack. My rigor lives before the binary ships. I don't have runtime logging and bug tracking from this angle wired in yet. I'm naming it because pretending you've solved a thing you haven't is exactly the cargo-cult theater this whole page is trying to teach you to see.

The product side: go watch how people actually use it. This is the part that's yours, the PM's, and almost nobody tells you it exists. Beyond "is the system up," there's a whole category of behavioral tooling that lets you watch real people inside your product. Heatmaps aggregate clicks, scrolls, and attention across many sessions into one picture, so you can see where people look and where they don't. Session replay reconstructs individual sessions, so you can watch one real user hit the exact spot where they got stuck and gave up. The usual sequence is heatmaps to find the pattern, replays to investigate why.

This is the closest you'll get to sitting behind a user without sitting behind them. You'll see the gap between how you assumed the product gets used and how it actually does. That gap is where your next iteration comes from.

One line so you don't conflate two different things. This is not analytics. The quantitative side, the numbers, the funnels, the OKRs, the dashboards that tell you how many and how much, that's its own discipline, and it lives in Part 07 (KPIs & Metrics). Watching one real person struggle is a different tool than counting how many people struggled. You need both. They're not the same stage. Part 07 is where you'll learn the counting.

What good looks like: the team catches failures from telemetry before customers report them, and the PM can go watch real people use the product to find the friction the numbers can only hint at.

The failure mode: you ship and look away. The first time you learn the new flow confuses people is when the churn number moves, three months later, with no idea which step did it.

A note on breaking the work down

One thing threads through this whole path: how the work gets cut into pieces.

The hierarchy is epic, then story, then task. An epic is a chunk of customer value big enough to take a few weeks. A story is one slice of that value, sized to land inside a single cadence. A task is the actual work under a story, and here's the rule I run: a task should be no bigger than one day of work.

That last number isn't arbitrary. On a team I ran, we kept tasks to a single day exactly so that if someone came to stand-up the next morning without their task done, we'd know immediately and pair a senior engineer with them to get it unstuck, fast. The small grain is what makes a stall visible the next day instead of at the demo. You'll see this rule again, in full, on the agile and task-writing pages.

One aside on the word "feature." Some shops slot a feature tier between epic and story. You don't need it. Epic, story, task is enough to do the job, and every level you add is another level someone has to keep in sync. Keep it lean. (The tooling trap, the part where you go looking for the perfect tracker to fix your process instead of fixing the process, I covered on the overview. The hierarchy and the sizing discipline are what matter. The tool is just where you write them down.)

The deep craft of writing each level, the epic, the story, the task, so the team knows exactly what to build and when it's done, gets its own three pages. We get there after agile and just-in-time.

The point

You don't have to write the code. You have to be able to look at this whole path and tell whether it's healthy or whether it's theater.

Healthy looks like small reviewable changes, honest tests, real QA evidence, security designed in, releases that happen on demand, and eyes on the product after it ships. Theater looks like every one of those with the label and none of the substance: a coverage number that means nothing, a security gate run too late, a release nobody can roll back, a product nobody's watching.

The team builds it. You make sure what you validated is what survives the trip.