2HAASStart a project
All articles

Process

Why we ship a working slice in week four

Most agency projects are planned as six weeks of design and twelve of build. Here is why we put a usable slice in front of real users before month one is out, and what that slice actually contains.

The 2HAAS team2 min read

Most agency projects are planned the same way. A few weeks of discovery, six weeks of design, twelve of build, then a launch. It looks responsible on a Gantt chart. It also means the first time a real person uses the product is somewhere around month four, which is exactly when changing direction has become expensive.

We plan the other way round. By the end of week four, something you can use is live, in front of real users, on the architecture that will carry the product.

What a slice is

A slice is one real task, cut vertically through the whole product. Interface, API, data, deployment: all of it, for one job, end to end.

For a booking product, the slice might be: a customer picks a time, pays, and gets a confirmation. Nothing else. No admin panel, no settings page, no loyalty scheme. But the booking is real, the payment is real, and the confirmation arrives in a real inbox.

It is not a prototype. A clickable design answers "do people understand this screen?" A slice answers "do people finish the task, and does the system hold when they do?"

How the four weeks run

Week one: sharpen the problem. We agree on the one task the slice has to do, who it is for, and how we will know it worked. Most of the value of this week is in what we decide to leave out.

Weeks one and two: prototype in the browser. Not a deck. A working surface that decisions get made against, because people argue differently about a thing they can click.

Weeks two to four: build the slice. Production code, tests, continuous deployment, error tracking. Narrow, not flimsy.

End of week four: live. Real users, real data, and a dashboard that tells us where they stall.

What we leave out on purpose

The first slice skips almost everything that makes a product feel finished: admin tooling, edge-case flows, notifications, the second platform. Those are real work and they will come. They are also the work most likely to change once users show up, so doing them first is the most expensive way to be wrong.

What you get to judge

At the end of month one you are not judging mockups. You are looking at:

  • whether people complete the task,
  • where they hesitate or give up,
  • whether the architecture holds under real traffic,
  • and how fast the team can change it.

If the direction is wrong, finding out costs days. That is the whole point.

When four weeks isn't enough

Sometimes a project cannot produce a usable slice in four weeks. That is useful information too. In our experience it rarely means the product is too big. It usually means the problem is not sharp enough yet, and that is what week one is for.

If you want to see what a slice would look like for your product, send us a few lines. We reply within one business day.

More notes

  1. 2 min read

    Handover is the deliverable

    Most agencies treat handover as the last meeting. We treat it as the thing we are building from day one, because code is only worth what the next team can do with it.

Tell us what’s in the way.

A few lines is enough. You get a candid yes, a candid no, or a sharper question.

  • Working software in week four
  • A reply in one business day
  • Handover is the deliverable

Prefer email? [email protected]

The problem, who it is for, and what is in the way right now.

One business day to a real reply. No sales sequence, no call required.