First Slice or Whole Product: What to Release First

You have an idea for a SaaS, a CRM or an online store. There is a feature list somewhere, maybe a deck, maybe a quote that depends on that list. The decision in front of you is what the first release actually is.

Two answers are usually on the table. One is the whole product on a plan: every role, every screen, every integration, arriving together at the end. The other is one slice: a single workflow that a real person walks from the first screen to a result worth paying for, running in production.

The first answer looks complete, and it is the one you cannot judge, because nothing works until everything works. The second looks thin and gives you something to measure in the first month. This article argues for the second answer, then says what a slice has to include before it counts as one.

1. What the whole product on a plan costs you

A whole-product plan carries a property nobody writes down: for months there is nothing to try. Every screen waits for the next one. Role management waits for billing, billing waits for the contract with the payment provider, and that contract waits for a legal review nobody has started.

So the meetings review mockups instead of behavior. What a slide promises and what a workflow does only diverge in front of someone who uses the thing, and in this shape of project that person arrives late, after most of the estimate is already spent.

Take a CRM built this way. The pipeline was drawn before anyone watched a real sale: five stages, an owner per stage, a probability field. The first real salesperson used two stages, ignored the probability, and copied the next step into a personal notebook. Fixing that means rebuilding screens, permissions and reports together, because they were designed as one block.

Feedback also arrives at the most expensive moment, when the product is nearly finished and a change of direction costs real money. That is when you learn that the client record should have been two records, and that nobody will ever open the second tab.

There is a quieter cost: nobody can say whether the work is going well. A plan produces status, sixty percent done and on schedule. A slice produces evidence: three real users finished the booking path this week, and two of them stopped at the same step, looking for a phone number.

2. One path, walked to the end

A first slice is not a smaller version of the finished product. A smaller version of a whole product keeps every screen and makes each one thinner, and that is how you get a demo where every button exists and nothing completes.

A slice is a different shape. It takes the one workflow that carries the reason someone pays and runs it to the end: booking an appointment, sending an invoice and receiving the money, entering a deal and seeing the next step.

Choosing the path is a business decision, not a technical one. Pick the workflow where money or the next committed step appears. For a booking product that is the booking itself, not the settings page. For a CRM it is the moment a deal gets a next step with a date on it.

Write the path as one sentence before you write code: who does what, and what result they get. If the sentence needs the words "and also", cut them. If nobody can name the person who walks the path, you have a feature list, not a slice.

The path must be walkable by someone who is not you. Founders accept paths that only work because they know the seed data, the internal rules, which field may stay empty. Put one person outside the build on the path and watch where they stop.

Everything after the end of the path is allowed to be ugly or manual in the first release. The invoice can be sent by hand. The report can be a spreadsheet. Manual work at the edges is an honest way to postpone a decision until a real user forces it.

3. The data model follows the path

The slice decides your data model, and the data model is the part that is expensive to change later. Build the tables around the workflow, not around the future feature list.

That looks like three habits in practice. The nouns of the path become entities with clear owners: an account, a user, the record the path creates. The states the path moves through are stored as data, not as one flag someone edits by hand. And every row knows which tenant it belongs to from the first migration, even while there is a single tenant.

Keep the history of the path as data too. When a record changes state, that is a new row with a time and an actor, not an overwritten value. Six months later this is the difference between answering a customer question in one query and arguing about what happened.

The tenant point is cheap now and expensive later; the shape of the boundary is described in where a shared product mixes customer data. What the slice leaves out matters just as much.

No generic activity table for events nobody has defined. No polymorphic relations meant to save future migrations. A schema you can explain in one sitting is a schema you can change without fear, and the first slice is where you earn that.

4. A release path you can repeat

A slice needs a release path you can repeat: a repository, one command or one pipeline that puts the code where it runs, and a way to see what happened. Not a laptop with the deploy steps living in one person's head.

Repeatable is the test, not automated. If the same release can run twice, following the same written steps, by someone other than the author, the path exists. If the second release needs a phone call to the same person, what exists is a demo environment, and the product will grow around that hole.

The first slice pays the setup cost that every later slice reuses: an environment that is not the one customers use, the pipeline, and the short list of checks you recheck after every release. There must also be a place to try the change before a customer meets it, which is the whole subject of why the live site cannot be the only place to test.

Leave one way to see trouble. An error log you can open, a failed job you can find, the state of the last release. You do not need dashboards yet. You need to know, without asking anyone, whether the path is working right now.

Every later workflow is then an increment, not a new project.

5. A slice is not a demo

This is the line most first releases fail. A demo has to look finished for one walkthrough; a slice has to survive a working week. The difference is not polish. It is what happens when you are not watching.

• Real accounts: sign-up, sign-in, password reset, and at least one account that is not yours.
• A way to accept the work: a real payment or a written order, so the path ends in money or a commitment.
• A place to test it: a second environment where a failed attempt costs nothing.
• Data you can reset: one command that returns your test account to a known state.
• One person outside the build who completes the path without you narrating it.

Missing one of the five still gives you a demo, and that is a fine thing to have in week two. It is not a first release, and calling it one only hides the work that is left.

6. What waits, and when to bring in help

Everything off the path waits, and writing that list down is the honest half of the plan. Roles and permissions, reports, notifications, the second integration. Agree now that the next slice comes from the first real week of use, not from the deck.

The scope conversation happens before the build starts, with the slice on the table as one number: what it costs, when it runs in production, what it deliberately leaves out. The checklist for freezing scope before the build is the pack for that conversation.

You can write the path, the model sketch and the leave-out list without a developer. Bring one in when the slice touches money, when several customers will share one database, or when nobody on your side can run the release. Those three cases decide the parts that are expensive to redo.

Services cover exactly this kind of start: the first workflow agreed, built and put in production, with the data model and the release path that follow from it. Selected work shows results next to the operation that produced them, including products that grew from one workflow into several. If you have an idea and no code yet, start with product development from scratch, and write to me with the one workflow your first customer would pay for. Leave passwords and customer data out of the message.