The most expensive thing you can do with a first version is build all of it. The second most expensive is cutting the wrong half.
Cut by workflow, not by feature
The usual mistake is shipping a bit of everything: a partial booking flow, a partial dashboard, a partial admin. Nobody can use any of it, so nobody does, and you learn nothing.
Pick one workflow that somebody performs regularly and build it end to end, including the boring parts: login, the error case, the confirmation email. One complete path beats five incomplete ones.
The data model is not a first-version decision
Screens can be redesigned cheaply. The data model cannot. Get the entities and their relationships wrong and every feature built on top becomes a workaround, until eventually the workarounds are the system.
So the model gets designed properly even when the first version is small. It is the one place where cutting corners compounds. More on how that is scoped under web application development.
What is safe to leave out
- Fine-grained permissions, if three roles will do for now
- Reporting, until there is data worth reporting on
- Bulk operations, until somebody is doing something fifty times a day
- A second language, unless the first users need it
- Anything requested as "it would be nice if"
What is never safe to leave out: audit trails, backups, and an error path that tells the user what happened.
Ship it to real users early
Ten real users for two weeks will teach you more than two months of internal review. They will also request things nobody in the room predicted, which is precisely the point of shipping a first version rather than a complete one.