Questions to Ask Before Starting a Software Project
Before starting, clarify the business problem and its sponsor, ask about users, data and existing tools it needs to work alongside, resolve budget and timing assumptions, and agree who owns the system after launch. Turning honest answers to these into a short brief tells you whether to proceed.
Clarify the Business Problem and Who's Actually Sponsoring It
The first question isn't about the software at all: what specific business problem is this meant to solve, and who in the business is accountable for that problem being solved? A project with a clear problem but no accountable sponsor tends to lose momentum the first time it competes with something more urgent.
It's worth being honest here about whether the problem is real or assumed. "A competitor has an app" is not the same as "customers are asking us for something we can't provide," and the two lead to very different projects, budgets and levels of urgency.
Ask About Users, Data and the Tools Already in Place
Who will actually use this day to day, and how comfortable are they with new tools generally — a system that assumes tech-savvy users will struggle with a team that isn't, regardless of how well it's built. Ask where the data will come from: does it already exist somewhere, in what condition, and who's responsible for getting it into a usable state before the new system goes live.
List every existing tool the new system needs to work alongside, even ones that feel minor — an accounting package, a WhatsApp-based ordering habit, a supplier's own portal. Systems that ignore what's already in daily use tend to get worked around rather than adopted, however good they are on their own.
Resolve Budget, Timing and Scope Assumptions Before You Start
Get a real budget range on the table early, even a rough one, because it shapes every other decision — custom versus packaged, how many features fit in a first release, whether to phase the work. A project that starts without this tends to discover the real budget only after a vendor's quote arrives, which wastes everyone's time comparing options that were never affordable.
Timing assumptions deserve the same treatment: is there a real external deadline (a licence expiring, a seasonal peak, a contractual commitment) or is the timeline simply aspirational? The two require very different levels of urgency and risk tolerance in how the project gets planned.
Agree Who Owns the System, and Supports It, After Launch
A surprising number of SMB software projects get planned in detail up to launch day and no further. Decide upfront who owns the system afterward — who fixes a bug, who trains a new staff member, who decides on the next round of changes — and whether that's an internal role or an ongoing arrangement with whoever built it.
This question is uncomfortable to raise early because it sounds like planning for problems before the project has even started. It's precisely the opposite: agreeing it upfront is what prevents the system from being abandoned six months after launch because nobody was clearly responsible for keeping it running.
Turn the Answers Into a Go or No-Go Brief
Imagine a wholesale distributor approached by a software vendor offering to build a custom CRM after a chance conversation at a trade event. Before agreeing to anything, the owner works through these questions honestly: the sponsor turns out to be the owner alone, with sales staff unconvinced there's a real problem; the budget is undefined; and no one has thought about who'd support the system after launch.
Written down as a short brief, those honest answers are themselves the decision — not a reason to abandon the idea outright, but a clear list of what needs to be resolved (a sales-team buy-in conversation, a defined budget, a support plan) before it makes sense to proceed. A vendor worth working with should welcome this brief, not push to skip past it.
Project-start questionnaire
A one-page questionnaire covering business problem and sponsor, users and their comfort with new tools, data readiness, existing systems to connect with, budget range, timing drivers, and post-launch ownership, designed to be filled in honestly before any vendor conversation begins.
Frequently asked questions
What if requirements are unclear?
Unclear requirements are normal at this stage and not a reason to stop — the point of these questions is to surface what's unclear so it can be resolved before money is committed, not to have every answer ready in advance. A vendor worth choosing will help clarify requirements as part of discovery, not expect a finished specification upfront.
Which questions should vendors answer?
How they'll handle unclear or changing requirements, what their testing and support process looks like, and who owns the code and data once the project is delivered. These are the questions that predict how the relationship holds up after the contract is signed, more than a quoted price does.
Have a specific situation to work through?
This article covers the general case. Tell us what you're actually dealing with and we'll respond directly.