7 questions to ask before starting a software project

Before we scope any project, we ask our clients a set of questions. These aren't technical questions. They're business questions. They help us understand the real problem, not just the surface request.

We're sharing them here because they work with any software team, not just us. If you're about to start a project, sit down with these first. The answers will save you time, money, and frustration.

1. What problem are you actually trying to solve?

This sounds obvious, but it's the question people skip the fastest. They come in with a solution in mind. "We need an app." "We need a dashboard." "We need to automate this."

But the solution isn't the problem. The problem is the thing underneath. Why do you need the app? What breaks when the dashboard doesn't exist? What happens if this stays manual?

Start with the pain, not the prescription. When you can describe the problem clearly, the right solution often becomes obvious. And sometimes it's simpler than you expected.

2. Who is going to use this?

Not everyone in your company. Who specifically? The warehouse team? The sales reps? The owner pulling reports on Sunday night?

Different users have different needs. The interface for a shop floor worker using a tablet is different from the interface for an office manager on a desktop. If you don't know who's using it, you can't build the right thing.

We also ask: how comfortable are these people with technology? Because software that's too complex for the people using it doesn't get used, no matter how good the features are.

3. What are you using now?

Almost nobody starts from nothing. There's always a spreadsheet, an old system, a whiteboard, or a notebook that's doing the job today. Understanding what exists helps us understand what's working, what's not, and where the gaps are.

It also helps us plan the transition. People have habits. They know the old system. If we understand what they're used to, we can build something that feels familiar enough to adopt without a fight.

4. What does success look like?

If we build this and it works perfectly, what's different? Be specific. "Things are better" isn't good enough. What's faster? What error goes away? What report can you pull that you can't today? What decision becomes easier?

This matters because it's how you'll know if the project was worth it. If you can't define success before you start, you can't measure it after you finish. And you'll always wonder if you got your money's worth.

We've found that the best answers are concrete. "Our team spends 10 hours a week on data entry. I want that to be 2." "We miss one out of every 20 orders because of manual errors. I want that to be zero." Numbers are better than feelings.

5. What's your timeline, and is it real?

Some deadlines are real. A regulatory change takes effect on a specific date. A contract starts on a specific date. A busy season hits at a specific time of year.

Some deadlines are wishes. "I'd like it done by Q3" might mean "sooner is better but later is fine." That's OK, but we need to know the difference.

Real deadlines shape the project. They determine what we build first, what we skip, and how much we can include in phase one. A firm deadline doesn't mean we rush. It means we focus.

6. What's your budget range?

Nobody likes this question. But it's one of the most important ones.

We don't ask because we want to charge you the maximum. We ask because budget shapes scope. If you have $20,000, we can build something focused and valuable. If you have $100,000, we can build something bigger. Both can be the right answer. But we need to know which one we're designing for.

When someone says "just tell me what it costs," without giving us a range, we have to guess what they're comfortable with. And guessing leads to proposals that don't match reality, wasted time on both sides, and sometimes a deal that falls apart over money when it didn't have to.

Be honest about your budget. A good partner will tell you what's possible within it, and what would require more.

7. Who on your team will own this project?

Every project needs one person on the client side who makes decisions, answers questions, and keeps things moving. Not a committee. One person.

When a software team needs a decision and has to wait for a meeting with six people to get it, the project slows down. When that one person can say "yes, do that" in an email, the project stays on track.

This person doesn't need to be technical. They need to understand the business, have the authority to make decisions, and be available. The biggest predictor of a project's success isn't the technology. It's how fast decisions get made.

Use these with anyone

We shared these questions because they work no matter who you hire. If you're talking to us, great, we'll ask them anyway. If you're talking to someone else, bring this list. The answers will make every conversation more productive and every proposal more accurate.

The best software projects start with clarity. These seven questions get you there.