What your first release should include, and what it should not

The most common way a software project goes wrong is not bad code. It is a first release that tries to do everything. It takes four months instead of four weeks, and by the time it launches, the problem has moved.

A first release has one job: put a working tool in real hands and prove people will use it. Here is how we decide what makes the cut.

Must have on day one

• The one workflow that causes the most pain today, working end to end
• Sign in, with the right people seeing the right things
• The data you already have, brought across so nobody starts from zero
• A way to see what is happening, even if it is one simple screen
• Works on a phone, because that is where half your team will open it

Can wait for version two

• Every edge case the team can imagine
• Custom themes, animations and settings pages
• Integrations with systems that only one person uses
• Advanced reports nobody has asked for yet
• Features that exist because a competitor has them

None of these are bad ideas. They are simply better decided after launch, when real use tells you which ones matter.

Ship the smallest thing that removes the biggest headache. Then listen.

A quick test

For every feature on the list, ask: if this was missing on launch day, would people stop using the app? If the honest answer is no, it goes on the version two list. That list is not a graveyard. It is the plan for the next few weeks, informed by people actually using the thing.