Vertical Slices

Building one complete feature at a time — touching every layer from user interface to database — rather than building all of one layer before moving to the next.

---

What is it?

Vertical slicing is a strategy for breaking down software work into pieces. Instead of building all the frontend, then all the backend, then all the database (horizontal layers), you build one feature at a time, end-to-end. Each slice includes everything that feature needs: its database table, its server logic, its API endpoint, its user interface, and its tests.

The name comes from imagining your software architecture as a layered cake. A horizontal slice takes one entire layer (all the frosting, or all the sponge). A vertical slice cuts through every layer at once — you get a thin piece, but it has frosting, sponge, filling, and base. It’s a complete piece of cake.

This matters because software layers need to work together. When you build all of one layer first, you’re making assumptions about what the other layers will need. Those assumptions are often wrong, and you don’t discover they’re wrong until you try to connect the layers — which might be weeks or months later. Vertical slices force integration to happen immediately, with every feature.

A walking-skeleton is the first vertical slice. Every feature after the skeleton follows the same pattern: thin, end-to-end, and independently testable.

In plain terms

Vertical slicing is like furnishing a house one room at a time instead of buying all the furniture first, then all the rugs, then all the light fixtures. When you finish the living room — furniture, rug, lights, curtains — you can actually sit in it. You have a complete, usable room. The kitchen comes next, then the bedroom. Each room is done when it’s done.

---

At a glance

Horizontal vs. vertical (click to expand)

graph TD
    subgraph Horizontal["Horizontal (risky)"]
        direction TB
        H1["All Frontend pages"]
        H2["All API endpoints"]
        H3["All Database tables"]
        H1 ~~~ H2 ~~~ H3
    end
    subgraph Vertical["Vertical (recommended)"]
        direction TB
        subgraph S1["Feature 1"]
            V1A[UI] --- V1B[API] --- V1C[DB]
        end
        subgraph S2["Feature 2"]
            V2A[UI] --- V2B[API] --- V2C[DB]
        end
        subgraph S3["Feature 3"]
            V3A[UI] --- V3B[API] --- V3C[DB]
        end
    end
    style Vertical fill:#e8f4e8,stroke:#4a9ede
    style Horizontal fill:#fde8e8,stroke:#e74c3c

Key: In horizontal slicing, layers are built independently and integrated late. In vertical slicing, each feature is a complete column through all layers. Integration happens with every feature, not at the end.

---

How does it work?

Vertical slicing is both a planning strategy (how you break down work) and a development strategy (how you build each piece).

1. Identify the feature

A vertical slice is one user-facing feature or behaviour. It should be:

• Small enough to build in one focused session (hours to a few days)
• Complete enough to test independently
• Valuable enough that someone could use it on its own

Think of it like...

A single dish at a restaurant. A dish isn’t “the protein part of five meals.” It’s one complete meal: protein, side, sauce, garnish. A diner can eat it and be satisfied. The next dish is a different complete meal, not “the sides for the first five dishes.”

---

2. Build through every layer

For each slice, implement all the layers it needs:

Layer	What you build	Example
Database	Tables, migrations, seed data	CREATE TABLE items (id, title, status)
Backend logic	Business rules, validation	”Title must be 1-200 characters”
API endpoint	Route that serves or accepts data	GET /api/items returns JSON array
Frontend	Page or component that displays or collects data	A page listing all items with titles
Tests	Verify the slice works end-to-end	”Fetching /api/items returns seeded data”

Example: a vertical slice for a search feature (click to expand)

Database: Add a text search index on the items.title column.

Backend: A search function that queries items by title match.

API: GET /api/items?q=keyword returns matching items.

Frontend: A search input on the items page. Typing triggers a filtered request. Results update live.

Tests:

1. Searching “bicycle” returns items with “bicycle” in the title
2. Searching with no matches returns an empty list
3. Empty search returns all items

This slice is complete. A user can search and see results. It didn’t require building any other feature first.

---

3. Integration happens immediately

The critical advantage: because each slice touches every layer, integration problems surface the moment you build the feature — not weeks later when you try to connect separate layers.

Common integration problems that vertical slices catch early:

• The API returns data in a format the frontend doesn’t expect
• The database schema is missing a field the business logic needs
• The frontend calls an endpoint that doesn’t exist yet
• Authentication blocks a request the frontend assumed would work

The key distinction

With horizontal layers, you discover integration problems at the end (“Why doesn’t the frontend work with the API?”). With vertical slices, you discover them immediately (“This feature’s frontend doesn’t work with this feature’s API — let me fix it now”).

---

4. Each slice creates a pattern

The first slice is the hardest. You’re making architectural decisions: how to structure routes, how to organise components, how to write tests. The second slice is faster because it follows the pattern the first one established. By the third slice, the pattern is solid and development accelerates.

This is especially powerful with AI-assisted development: the AI can study completed slices and replicate the pattern for new features with high accuracy.

Concept to explore

See walking-skeleton for the very first slice — the one that establishes the foundational pattern.

---

Vertical slices vs. horizontal layers

Aspect	Horizontal layers	Vertical slices
Unit of work	One layer across many features	One feature across all layers
When you can test	After all layers are connected	After each feature is built
Integration risk	High (discovered late)	Low (discovered immediately)
Visible progress	Invisible for months, then sudden	Visible with every completed feature
AI-assisted workflow	Difficult (too much context needed)	Natural (one feature = one focused session)

---

Why do we use it?

Key reasons

1. Immediate integration testing. Each slice proves that the layers work together for that feature. You never have a “big bang integration” moment where separate layers must suddenly cooperate.

2. Shippable increments. Each completed slice is a working feature that could, in theory, be released to users. This means you always have a deployable product — even if it only has two features so far.

3. Accurate progress tracking. With horizontal layers, “80% of the backend is done” tells you nothing about whether the product works. With vertical slices, “3 of 5 features are done” means three features actually work end-to-end.

4. Natural fit for AI-assisted development. Each slice is a self-contained task with clear boundaries — exactly what an AI coding assistant needs. The AI can see all the context for one feature without being overwhelmed by the entire system.

---

When do we use it?

• When building any application with more than one architectural layer
• When working in iterations — each iteration delivers one or more slices
• When building with AI coding assistants — slices are ideal units of work
• When you want to demonstrate progress continuously (not just at the end)
• When integration risk is a concern (which is almost always)

Rule of thumb

If you’re about to build “all the database tables” or “all the frontend pages” before connecting them, stop. Pick one feature instead and build it end-to-end. That’s your first vertical slice.

---

How can I think about it?

The feast preparation

Imagine preparing a feast for guests. The horizontal approach: cook all the appetisers, then all the mains, then all the desserts. You discover at serving time that the appetiser plates don’t fit the table, and the main course needs a sauce you forgot to make.

The vertical approach: prepare one complete course at a time. Appetiser: cook it, plate it, taste it, confirm it works with the table setting. Done. Move to the main course: cook, plate, taste, confirm. Each course is complete and tested before you start the next.

• One complete course = one vertical slice (feature end-to-end)
• Tasting and plating = testing and integration
• All appetisers at once = horizontal layer (risky batch)
• Discovering the sauce is missing = late integration failure
• The feast is servable after each course = shippable increment

The newspaper column

A newspaper doesn’t print all the headlines first, then all the body text, then all the photos. Each article is written, edited, and laid out as a complete unit — headline, body, photo, caption. The editor reviews complete articles, not disconnected layers.

• One article = one vertical slice (complete through all layers)
• All headlines = a horizontal layer (useless without body text)
• The editor = testing (reviews complete features, not partial layers)
• Going to press = deployment (you can publish with 8 articles even if you planned 10)
• The layout = the architecture (each article follows the same template)

---

Concepts to explore next

Concept	What it covers	Status
walking-skeleton	The first vertical slice that proves the architecture	complete
spec-driven-development	Writing a spec for each slice before building it	complete
monolith-architecture	The simplest architecture for vertical slicing	complete
horizontal-layers	The contrasting approach — and when it’s still useful	stub
feature-flags	Hiding incomplete slices behind toggles in production	stub

Some of these cards don't exist yet

They’ll be created as the knowledge system grows. A broken link is a placeholder for future learning, not an error.

---

Check your understanding

Test yourself (click to expand)

1. Explain what a vertical slice is and why it’s called “vertical.” What does it cut through?
2. Name the layers a typical web application vertical slice includes. What does each layer contribute?
3. Distinguish between building features as vertical slices and building them as horizontal layers. What specific problem does vertical slicing prevent?
4. Interpret this scenario: a team builds all 10 API endpoints in week one, then starts the frontend in week two. In week two, they discover that 3 of the endpoints return data in a nested format that the frontend framework can’t easily render. What went wrong, and how would vertical slicing have helped?
5. Connect vertical slices to walking-skeleton. Why is the skeleton described as “the first vertical slice”?

---

Where this concept fits

Position in the knowledge graph

graph TD
    ID[Iterative Development] --> VS[Vertical Slices]
    ID --> WS[Walking Skeleton]
    ID --> SDD[Spec-Driven Development]
    ID --> VC[Vibe Coding]
    WS -.->|is the first| VS
    VS -.->|works within| MA[Monolith Architecture]
    style VS fill:#4a9ede,color:#fff

Related concepts:

• walking-skeleton — the skeleton IS the first vertical slice; it establishes the pattern all others follow
• spec-driven-development — each slice benefits from a specification defining its expected behaviour
• monolith-architecture — slices are features within a monolith, not separate services

---

Further reading

Resources

• A Guide to Vertical Slice Architecture in Modern Web Apps (Clean Code Guy) — Comprehensive overview with code examples
• The Layered Architecture is Dead: Long Live Vertical Slices (Wireframe) — History and rationale for the shift from layers to slices
• Slicing Your Software: Vertical vs. Horizontal Approach (Oreate AI) — Side-by-side comparison with the feast analogy
• RED Loop: Vertical Slice and Walking Skeleton (Dev Genius) — How vertical slices and walking skeletons work together in practice