📖 Lecture — Vertical Slices, Walking Skeletons, and the Design Review

By Week 8, your capstone has a name, an architecture diagram, a stack of ADRs, and probably a folder full of half-finished pieces. This week is about proving those pieces actually work together, end to end, and doing it in a way that keeps something demoable at every stage. What a vertical slice actually is. A vertical slice is a thin but complete path through every layer of your architecture: a request comes in, passes through your application code, reaches your model or inference service, and a response goes back out — and the whole path is deployed somewhere real and observable, not just running in a notebook or on localhost. "Thin" means the slice doesn't need every feature, every edge case, or every piece of business logic. "Complete" means it touches every layer your final system will touch: ingress, app logic, model serving, and response — with real components wired together, even if the functionality inside each layer is minimal. Vertical vs. horizontal, and why it matters. The natural instinct for many builders is to build horizontally: finish the entire database schema, then all the backend logic, then finally start on the UI or the API contract. The problem is that nothing is usable, testable, or demoable until every layer is done — and any wrong assumption made in week one about how the layers connect doesn't surface until the very end, when it's expensive to fix. A vertical slice inverts this: you build one thin path through all the layers first, so integration problems surface immediately, while the cost of fixing them is still low. The walking skeleton comes before the MVP. A walking skeleton is the smallest possible end-to-end system with real components wired together, but trivial functionality — think a request that hits a real API gateway, calls a real (even if tiny) model endpoint, and returns a real (even if unimpressive) response, all deployed on real infrastructure. It is not the MVP. The MVP is the smallest version of the product a user would find valuable; the walking skeleton is the smallest version of the system that proves the plumbing works. Stand up the skeleton first, confirm every joint in the architecture actually connects, and only then start layering in the feature depth that turns it into an MVP. Where "shared" folders go wrong. A common failure mode when students first try to slice their work vertically is panicking about where to put code that's used by more than one feature, and defaulting to a shared/ or common/ folder. Left unchecked, that folder becomes a dumping ground that couples every slice to every other slice, defeating the purpose of slicing in the first place. The discipline is to keep each vertical slice as independent as possible and only extract shared code once duplication is real and proven — after you can see the same logic repeated verbatim in two or more slices, not before. The design review is a checkpoint, not a demo day. This week's design review exists to validate that the Week 3 architecture you sketched on a diagram actually runs, however minimally. Frame it around the artifacts you already have:

The review isn't about having a finished product. It's about showing that your design decisions survived contact with a real, deployed system — and being honest about where they didn't. Deployed and reachable, not just running. A vertical slice that only runs on localhost doesn't prove much: it skips exactly the parts of the architecture (networking, service discovery, container orchestration, observability) that are hardest to get right and most likely to break in production. This week's lab requires your slice to be deployed to a real, if small, orchestrator — a local Kubernetes cluster via kind or minikube — and reachable through an actual Service, not a mock or a stub.