What should never get cut
Seven things are load-bearing. Everything else is a feature.
The core user journey. The product logic. Onboarding clarity. Authentication and account access. Basic QA. Deployment and release setup. The handover of ownership and access.
None of these are exciting and none of them demo well. All of them are the difference between a product you have and a product you merely paid for. A build that ships without a release process has not shipped. A build that ships without a handover of accounts and keys has shipped to someone else.
What goes first
The things that feel essential in a planning document and prove optional in a live product.
Secondary user flows. Advanced admin features. Nice-to-have automations. Complex dashboards. Any polish that does not touch the core journey.
These get cut not because they are worthless but because they are unfalsifiable. A dashboard built before anyone has used the product displays numbers nobody has learned to care about yet. An automation built before the manual process has run is an automation of a guess.
Onboarding is not polish
The most common thing cut wrongly is the moment a user first understands the product.
Onboarding gets treated as decoration because it does not appear on the feature list. It is the point at which a stranger decides whether the thing you built is for them. Everything downstream depends on it and nothing upstream can compensate for it.
A first version with a rough dashboard and clear onboarding produces usable information. A first version with a beautiful dashboard and confusing onboarding produces users who never reached the dashboard.
The question that predicts the outcome
You can tell how a build will go from what the founder asks in the first conversation.
The question that predicts trouble: can you just build all the features first, and we will figure out the details later. It sounds efficient. What it means is that the details will be decided anyway, silently, by a developer guessing under a deadline, without you in the room.
The question that predicts a good outcome: what should we cut from version one so we can launch the strongest first version properly. A founder who asks that has already understood the thing that matters. They are not trying to build less. They are trying to build the right object.
What more budget actually buys
The additions between a focused build and a larger one are structural, not decorative.
More money in a first build does not buy more screens. It buys more user roles and the permissions model that implies, deeper product logic, payments, admin environments somebody has to operate daily, richer integrations, more testing, and a more robust launch foundation.
That is the honest description of the gap between a focused first version and a larger one. It is also why founders comparing quotes see numbers that do not seem to correspond to anything visible.
Where Wall & Fifth sits
The exclusions conversation is the most valuable hour of a build, and it happens before anyone writes code.
What the first version is for, what it deliberately leaves out, and what must be true on launch day. Those three answers set the scope, the number, and whether either holds.
For a defined first version, that is New Builds. Where the product direction needs to stay open while the software takes shape, it is usually Embedded Partner.
This is written for founders who
This is written for founders who
- Have a feature list and no way to rank it
- Are being asked what to cut and do not know how to answer
- Are worried that a smaller first version means a worse product
- Have been quoted more than expected and need to know what is safe to remove
FAQ
Questions people usually have before the next step feels obvious.
What should never be cut from a first build?
The core user journey, the product logic, onboarding clarity, authentication and account access, basic QA, deployment and release setup, and the handover of ownership and access. These are not features. They are the conditions under which a product exists at all.
What is usually cut first when budget is short?
Secondary user flows, advanced admin features, nice-to-have automations, complex dashboards, and polish that does not affect the core journey. Most of it is not lost, only scheduled for later once real usage has told you whether it was needed.
Is a smaller first version a worse product?
No, because it is a different product with a different job. Version one exists to produce information about real users. A larger first version does not produce better information, it produces the same information later and at greater cost.
Should onboarding be in version one?
Yes. It is the point at which a stranger decides whether the product is for them, and everything downstream depends on it. It is frequently cut because it does not look like a feature, which is precisely why it is the most damaging thing to remove.
What does a larger budget add to a first build?
More user roles and the permissions model they require, deeper product logic, payments, admin environments, richer integrations, more testing, and a more robust launch foundation. Structural things rather than visible ones, which is why the number rarely matches what a founder can picture.
Related pages
Useful next step
Decide the exclusions deliberately, before a deadline decides them for you.
The first version is cheaper, faster, and more useful when everyone agreed in advance what it was never going to contain.