Software project checklist: 25 questions before you start
The twenty-five questions to answer before commissioning custom software, covering the problem, the users, the data, the build, the running and the money.
The short answer
Custom software fails before the first line of code more often than during the build: the problem was never stated precisely, the users were assumed, the data turned out to live in five places in five formats, nobody owned the result, and the cost of running it was never budgeted. The twenty-five questions below surface those failures while they are still cheap to fix. They cover six areas: the problem, the users, the data, the build, the running and the money. You do not need perfect answers, you need honest ones, and a partner who helps you find the missing ones before anyone writes code. A project that cannot answer most of them should begin with a discovery phase or a clickable prototype, not a build.
The twenty-five questions
| # | Area | Question | Why it matters |
|---|---|---|---|
| 1 | Problem | What specific problem does this solve, in one sentence? | If it cannot be stated, it cannot be built |
| 2 | Problem | How is it handled today, and what does that cost in time, errors or money? | The baseline the software must beat |
| 3 | Problem | What would success look like in six months, in numbers? | The measure of whether it worked |
| 4 | Problem | Why custom rather than a product you can buy? | Custom is right when the process is your advantage or nothing fits |
| 5 | Users | Who exactly will use it, how often, on what device? | Design and platform follow from this |
| 6 | Users | What would make them switch from how they work now? | Adoption is the real risk |
| 7 | Users | Who will not use it, and does that matter? | Scope and change management |
| 8 | Users | Have the actual users been asked? | Assumptions about users are the most expensive kind |
| 9 | Data | What data does it need, where does that live today, and in what state? | Data readiness decides timelines |
| 10 | Data | Which system is the source of truth for each kind of data? | Integrations depend on this |
| 11 | Data | What personal data is involved, and what are the retention and privacy obligations? | Compliance designed in, not added |
| 12 | Data | What must be migrated from the old system, and who owns cleaning it? | Migration is a project inside the project |
| 13 | Build | What is the smallest version that would deliver real value? | The MVP, and the first thing to build |
| 14 | Build | What is explicitly out of scope for the first version? | The list that keeps the first version small |
| 15 | Build | Which systems must it integrate with, and are their APIs available? | Integrations decide feasibility |
| 16 | Build | Who decides, and how quickly, when a question arises? | Decision speed is the schedule |
| 17 | Build | How will you see progress: previews, sprint reviews, working software? | No big reveal |
| 18 | Running | Who owns the software after launch, on your side? | Software without an owner decays |
| 19 | Running | Where will it be hosted, in whose account, in which region? | Ownership and compliance |
| 20 | Running | Who handles support, maintenance, updates and incidents, at what response times? | Software is never finished |
| 21 | Running | What is the plan for backups, monitoring and recovery? | The questions asked after the first incident, better asked now |
| 22 | Running | What happens if the partner disappears: code, documentation, hand-over? | Ownership in practice |
| 23 | Money | What is the budget for the build, and is it phased? | Phasing protects the budget |
| 24 | Money | What are the running costs: hosting, services, licences, maintenance, per year? | The line most often forgotten |
| 25 | Money | What is the cost of not doing it, or of doing it a year later? | The other side of the decision |
Working through them
- Answer alone first, honestly, marking each as confident, uncertain or unknown.
- Involve the users for questions five to eight; do not guess on their behalf.
- Involve whoever owns the data for nine to twelve; look at the actual data, not the description of it.
- Work through the build and running questions with the partner; they know what is feasible and what running software requires.
- Count the unknowns: a few is normal; many means discovery or a prototype first.
- Write the answers into the brief; they are its substance.
- Revisit at each phase, because answers change as the project teaches you things.
What the answers produce
A brief that a partner can price honestly. An MVP scope that can be built in weeks rather than months. A data plan with owners. A named internal owner and a running-cost line in the budget. A hosting and ownership arrangement in the business’s name. And a shared understanding, before any code, of what success looks like and how everyone will know.
What this means for you
Answer twenty-five questions about the problem, the users, the data, the build, the running and the money before commissioning software. Honest answers, including unknowns, produce a brief that can be priced, a first version that can be built quickly and a plan for running it. Many unknowns mean discovery or a prototype first, and knowing that before the build is the cheapest insight a software project ever gets.
Frequently asked questions
We have a clear idea. Do we still need all these questions?
A clear idea is the first answer, not the last. Projects with clear ideas still fail on who will use it and why they would switch, on data that lives in five places, on who owns it after launch, and on running costs nobody budgeted. The questions take an afternoon with your partner, and the ones you cannot answer are the ones that would have cost months.
What if we cannot answer many of them?
Then the project is not ready to be built, and that is useful to know. The answer is a short discovery phase, a prototype people can click, or a smaller first version that tests the riskiest assumption. Building the full thing on unanswered questions is how software ends up unused.
Who should answer them?
The business owner or sponsor, the people who will actually use the software, whoever owns the data it will touch, and the partner who will build it, together. Answers from the sponsor alone miss what users need; answers from users alone miss the business case; answers without the partner miss what is feasible.