Slicing a feature so every step is checkable

The wrong cut and the right one

There are two ways to divide a feature, and one of them wastes a week.

The horizontal cut builds a layer at a time. All the database tables first. Then all the API routes. Then all the screens. It feels organised. It is also three days before anything works, and when something is wrong you have three days of unverified code to search through.

The vertical cut takes the thinnest possible path through every layer and makes it work end to end. One form, one route, one table, one screen showing the result. It is ugly, incomplete and running, and everything after it is an addition to something you have already seen work.

With generated code the vertical cut is not merely preferable. It is the only one where you have any idea what is happening.

The walking skeleton

The first slice of any project is deliberately trivial and complete:

A page at /book with one field. Type a name, press save, the name is written to the database, and the page below lists every name saved so far.

No validation, no styling, no rules. Fifteen minutes of work, and when it runs you have proved the whole chain: the browser reaches the server, the server reaches the database, the data comes back, the deployment works. Every bug after this is in a feature, not in the plumbing, and that distinction saves hours.

Most people skip this and ask for the whole booking system. Then something does not work and they cannot tell whether the problem is the overlap rule or the database connection.

Slices for a real feature

Take booking with overlap checking. Six slices, each testable in under two minutes:

1. The form renders with the right fields. Nothing saves. Check: open it on your phone.
2. Submitting writes a row. Check: look in the database.
3. The list below shows saved bookings, newest first. Check: submit two.
4. Submitting an overlapping slot is rejected with a specific message. Check: try to double-book on purpose.
5. Submitting with an empty name is rejected before it reaches the database. Check: submit nothing.
6. A booking can be cancelled, and a cancelled slot becomes bookable again. Check: cancel one, rebook it.

Slice 4 is the one that carries your business. Notice it arrives fourth, on top of three things already known to work, which means when it misbehaves there is exactly one place to look.

The two-minute rule

If you cannot check a slice in two minutes, it is too big. Split it.

This is not a productivity trick. It is about where the bug can be hiding. A change you can verify in two minutes has a search space of one change. A change you verify at the end of an afternoon has a search space of an afternoon, and the model does not remember which part it was less sure about.

Commit at every green step

Each slice that works gets a commit, with a message saying what is now true. Six slices, six commits, and if slice five goes badly you lose slice five.

This is where the git block earns itself. Slicing and committing are the same habit seen from two sides: small verified steps with a way back to each one.

Saying it to the tool

We are building bookings in six steps. Do step 1 only.

Step 1: a page at /book with a form — customer name, stylist
dropdown (read stylists from the database), date, time.
On submit, do nothing yet. No validation, no styling beyond
Tailwind defaults.

Stop after this. Do not create API routes or database writes.

The last line does the work. Left alone, an agent asked for a form will helpfully build the whole feature, and you are back to reviewing an afternoon of code in one lump.

When to break the rule

Small, self-contained, obviously-correct work does not need slicing. A static About page. A colour change across a component. Adding a field that nothing depends on.

The test is whether being wrong would be visible immediately. If yes, take the whole thing in one go. If a mistake could sit quietly for a week (anything touching money, permissions, or data that must survive) slice it, however tedious that feels on a Friday afternoon.