How to decide what belongs in version one of custom software

If your first software version already has a wishlist, a “nice-to-have” pile, and three departments making promises about it, you’re already in trouble.

Version one is where good software projects either get traction or get buried under their own ambition. I’ve seen business owners treat V1 like pouring the whole foundation, framing the house, and picking out backsplash tile all at once. Don’t do that. The goal is to build the smallest useful thing that solves a real problem end to end.

The research backs this up. Smaller projects are far more likely to succeed than big ones, and that lines up with what I see in the real world: tight scope ships, bloated scope stalls. Here’s the checklist I’d use if you’re deciding what actually belongs in version one.

1. Start with one painful business problem, not a feature list

If you begin with features, you’ll end up collecting requests like a restaurant menu with no idea what meal you’re actually serving. Start with the problem: invoices take too long, customer data is scattered, scheduling is a mess, reporting eats half a day every week.

Write one sentence: “Version one exists to fix this specific bottleneck.” If a feature doesn’t directly help that sentence come true, it probably stays out. This is the same idea behind why your first software version should solve one problem, not five.

2. Pick one user first

“Everyone will use it” is not a user definition. That’s how you get software that kind of works for everybody and really works for nobody.

Choose the first person who must win with this system. Maybe it’s the dispatcher, office manager, estimator, billing person, or owner. If you don’t know whose day gets easier first, your scope is still mush.

3. Map the core workflow from start to finish

Version one should complete a real job, not just build pieces of one. A dashboard with no data entry, or a form with no approval flow, is like installing a front door with no house behind it.

Take the main task and map it step by step. What starts the process, what happens in the middle, and what counts as done? V1 should cover that whole path, even if it ignores ten side roads.

4. Separate must-have from emotionally satisfying

Business owners and teams love features that feel impressive in a demo. Search filters, custom themes, advanced exports, mobile apps, AI summaries — all fun, all easy to oversell.

Ask a harder question: if we remove this, does the workflow break? If the answer is no, it’s probably not V1. Useful beats impressive every time.

5. Be honest about whether you even need custom software yet

Sometimes the right version one is not custom software at all. A spreadsheet, a form tool, a no-code workflow, or a couple of connected off-the-shelf tools may be enough to prove the process before you pay to build it.

I’m pretty opinionated here: don’t custom-build what you haven’t even validated. If you’re still figuring out the process itself, read when a spreadsheet beats software—and when it starts costing you.

6. Include the boring stuff if the business actually needs it

This is where a lot of “lean” advice gets sloppy. Sometimes the minimum really does include permissions, audit trails, basic reporting, or an integration, because without those the software is unusable in a real company.

If you run a business in Northwest Arkansas and the surrounding region, you don’t need a toy app — you need something people can use on a Tuesday when phones are ringing and work is stacked up. Boring requirements are still requirements.

7. Decide whether your goal is learning, adoption, or revenue

People throw around MVP like it means one thing. It doesn’t. A true MVP is about learning. A marketable first release is about getting people to buy. A more polished first release may be about team adoption.

Those are different goals, and they change what belongs in scope. If you’re unclear on that, what an MVP actually is and why you probably need one is worth reading.

8. Protect version one from sales promises and internal politics

A lot of bad scope decisions are not technical at all. They happen because someone promised a feature in a meeting, or one department doesn’t want to be left out, or the owner wants to “future-proof” everything.

You need one person making final scope calls, and the rule should be simple: if it delays solving the core problem, it waits. Scope creep is usually just indecision wearing a nicer shirt.

9. Think about what is expensive to change later

I’m all for keeping V1 lean, but not careless. Some things are cheap to add later. Some are miserable to retrofit later, especially around data structure, integrations, security, and compliance.

That doesn’t mean overbuilding. It means making a few smart structural decisions early, especially if you’re planning custom software development that will grow into a bigger internal system.

10. Define what success looks like before anyone starts building

If success is vague, scope will keep growing because nobody knows when enough is enough. Decide what evidence will prove version one worked: faster task completion, fewer handoffs, cleaner reporting, fewer duplicate entries, better follow-through.

This is the part people skip, then wonder why the project keeps drifting. Before development starts, you should be able to say, “If V1 does these two or three things well, it was worth building.”

Version one should not be your dream system — it should be your first working piece of proof.