6 decisions to make before a developer can build the right software

A lot of software projects go sideways before a single line of code is written. Not because the developer is bad, but because the business hasn’t decided what game it’s actually playing.

That’s like hiring a builder and saying, “We need a structure,” without deciding whether it’s a garage, a warehouse, or a chicken coop. If you want software that actually helps, here are the six decisions to make first.

1. Decide what problem you are solving

Don’t start with features. Start with the pain. If you can’t describe the business problem in one or two plain-English sentences, you’re not ready to build.

“Need a dashboard” is not a problem. “Managers wait until Friday to see job status, so they miss issues during the week” is a problem. That distinction matters because software should remove a bottleneck, not just add another screen.

If you’re not sure where the real issue is, read Before You Buy New Software, Find the Bottleneck You Actually Have. It’s cheaper to diagnose first than rebuild later.

2. Decide what success looks like

Before anyone talks about tech stack, decide how you’ll know the project worked. Faster turnaround? Fewer mistakes? Less re-entry? Better visibility? Pick one or two outcomes and write them down.

I’m opinionated about this: if success is vague, scope will explode. Teams can recover from a technical misstep more easily than they can recover from never agreeing on the target. This lines up with what the Standish Group and PMI have reported for years — unclear requirements and weak decision-making sink projects early.

A simple test: if two people in your company would give two different answers to “why are we building this,” stop and settle that first.

3. Decide what belongs in version one — and what does not

Most businesses ask for too much in the first round. That’s normal. You’re imagining the finished house when what you really need first is a solid foundation, a roof, and working plumbing.

McKinsey has pointed out that a lot of software features go unused, and I believe it. The most important scope decision is often what not to build. Version one should solve one painful problem well, not five problems halfway.

If you need help trimming the list, How to decide what belongs in version one of custom software is worth reading. And if you’re exploring a first build, an MVP or prototype is often smarter than trying to launch the final form on day one.

4. Decide who owns the decisions

This one gets ignored all the time. Who can approve scope changes? Who breaks ties when operations wants one thing and sales wants another? Who decides whether “good enough for now” is acceptable?

If the answer is “the team will figure it out,” don’t do that. Software projects stall when nobody owns the trade-offs. A developer can build what you decide, but a developer should not be forced to become the referee for your internal politics.

If this is already feeling familiar, read If no one owns the decision, your software project will stall.

5. Decide how your data will work

Every software project is a data project whether people admit it or not. What data do you need, where does it come from, who is responsible for it, and how messy is it right now?

Imagine a service business in Northwest Arkansas with customer info in QuickBooks, job details in spreadsheets, and scheduling in a separate app. The hard part may not be building the interface. The hard part may be connecting the pipes without leaks. That’s why I push businesses to think through integrations early, especially if they’re considering custom software development or work across multiple systems in places like Fayetteville and the broader region.

For a deeper look, What a Software Integration Actually Is—and Why Vendors Oversimplify It covers the trap pretty well.

6. Decide how the software will be used after launch

Launch is not the finish line. Who trains the team? Who answers questions? Who handles bugs, change requests, user permissions, and the “this worked differently in my head” conversations?

This is where good projects can still fail. IBM and NIST have both helped make the point over the years that catching problems late is far more expensive than catching them early. The same is true operationally: if you wait until go-live to think about support, security, and maintenance, you’re fixing the airplane after takeoff.

You don’t need a giant policy binder. You do need a basic plan for ownership, support, and ongoing changes.

Good software starts with good decisions. When a project feels confusing, it usually isn’t because coding is mysterious. It’s because the business is still pointing at a blank lot, calling it a building, and hoping the contractor can read minds.