Skip to content
MAMohammed Alakel, home
All writing

· 2 min read

Ship in slices that stand on their own

A slice is not a piece of a feature. It is a small, complete thing that works in production by itself. Build in those, and a project can stop at any point and still be worth something.

  • Method
  • Engineering
  • Delivery

The Build stage of my method has one rule: ship in slices that each stand on their own in production. It sounds like standard advice about small iterations. The important words are stand on their own.

Layers versus slices

The instinctive way to build a feature is in layers. First the database schema. Then the API. Then the business logic. Then the interface. Each layer is necessary, and none of them is useful until the last one lands.

The trouble with layers is that nothing is real until everything is done. Feedback arrives late. Estimates are hard to check because progress is invisible. And if the project is cut halfway — which happens — you are left with a schema and an API that nobody can use.

A slice cuts the other way: a thin piece of the feature through every layer, small enough to build quickly, complete enough that a real user can do something real with it.

What makes a slice stand on its own

A slice is ready to ship when:

  • Someone can use it. It does something end to end, even if narrowly.
  • It is safe in production. It handles errors, respects permissions and does not break anything that already works.
  • It would be worth keeping if everything stopped. If the project were cancelled tomorrow, this slice would still be a small improvement, not dead code.

That last test is the demanding one. It rules out "scaffolding" slices that only exist to enable the next slice.

An example

Suppose the goal is a content management system for a portfolio: editable projects, career history, media uploads and publishing.

A layered plan builds all the tables, then all the admin screens, then publishing. Nothing ships until the end.

A sliced plan might go:

  1. The public site reads its existing content from the database instead of from files, with no visible change. Small, safe, and it proves the data layer.
  2. An admin screen that edits one content type — say, capabilities — end to end.
  3. Projects, including their case-study fields.
  4. Media upload for projects.
  5. Everything else.

Each step is useful on its own. Each can be verified in production before the next begins. And the riskiest assumption — that the database can faithfully replace the files — is tested first, when it is cheapest to be wrong.

Why this matters beyond speed

Slices change the conversation with everyone involved. Progress is something people can click on, not a percentage in a status report. Priorities can be changed between slices without waste. And problems surface while they are small.

The takeaway

When planning work, do not ask "what are the layers?" Ask "what is the smallest thing a real person could use, that we would be glad to have even if we stopped there?" Build that. Then ask again.