A first release is not a product

The screenshot is the smallest part

It is easy to confuse a first release with a product. The screens are visible. The announcement is scheduled. A few happy-path clicks work in a staging environment that nobody else is using. Then real users arrive with partial data, expired sessions, a permission they should not have, and a payment that succeeds twice.

The software that has to work after launch is mostly not the interface. It is the workflow the interface sits on: who is allowed to do what, what the system does when a step fails, how data stays true, and who can tell that something is wrong without reading a stack trace.

The five things a release must be able to survive

Before we call a first version a product, we ask whether it can survive five ordinary events. None of them are exotic. All of them show up in the first month.

• A user who is not the founder. Permissions, empty states, and copy that does not assume context.
• A step that fails halfway. Payments, emails, exports, and writes that must not double or vanish.
• A record that should not be visible. Tenancy, roles, and the quiet bugs that leak one customer into another.
• A change that must ship next week. If the first release can only be modified by the people who built it from memory, it is not yet a product.
• An operator who is not the engineer. Someone has to reset a user, replay a job, or explain a failed invoice without opening the database.

Build the workflow, not the gallery

A product is a sequence of decisions the business already makes, encoded so they can happen without a hero in the loop. That means the data model, the business rules, the integrations, and the failure states are part of the first slice — not a phase that starts after the interface is “done.”

We would rather ship one complete path — create, validate, persist, notify, recover — than five screens that all stop at “we will handle this later.” Later is when the first customer is waiting, and later is when shortcuts become the system.

A narrow path that can be operated is worth more than a wide surface that cannot.

What “done” should mean on a first release

Done is not “the happy path works on my machine.” For work we take, a first release is done when the following are true, in writing, for the slice that shipped.

• The business rule is explicit. Not “the code does the right thing,” but the rule a new teammate can read.
• The failure is visible. A failed job, a rejected payment, a permission denial — each has a place to land.
• The rollback is known. If this release is wrong, what do we turn off, and what data do we not try to unwind by hand?
• The handoff exists. Access, runbooks, and the decision log. The people who remain can continue.

This is why we talk about systems, not only screens

When a founder asks us to “build the app,” we translate that into the workflow the app is supposed to carry. That translation is the work. It is also why a first conversation can be useful even before anyone opens a design file.

If you are about to launch, ask a harder question than “does it look finished?” Ask whether the path still works when the data is messy, the user is new, and the person who built it is on a plane. That is the difference between a release and a product.