Custom software can transform how a business operates — or become an expensive project that never quite lands. The difference is usually decided early, in how the problem is defined and how the work is set up. This checklist covers the decisions worth making before development starts.
1. Define the problem, not the solution
Write one paragraph describing the problem in business terms: who is affected, what it costs today, and what would be different if it were solved. “Our sales team spends Friday afternoons rebuilding the pipeline report from three spreadsheets” is a better starting point than “we need a CRM”.
2. Decide how you will measure success
Pick two or three measures you can check after launch — time saved per week, error rate, orders processed per person, customer self-service rate. They guide every prioritisation decision during the project.
3. Check whether you need custom software at all
Before commissioning a build, review established products. If an off-the-shelf tool covers most of your needs, configuring it — and building only the missing pieces — is usually faster and cheaper. Custom software earns its cost when your process is a genuine differentiator or nothing on the market fits without painful workarounds.
4. List users and their key journeys
For each type of user — staff, managers, customers, partners — write down the three to five things they must be able to do. These journeys become the backbone of design, development, and testing.
5. Map your data and integrations
- What data will the system hold, and where does it come from today?
- Which existing systems must it connect to — accounting, CRM, e-commerce, email, identity?
- Do those systems have APIs, and who owns them?
- Is there historical data to migrate, and how clean is it?
Integrations and data migration are the most commonly underestimated parts of a project. Surfacing them early protects the budget.
6. Separate must-haves from nice-to-haves
Agree a first release that solves the core problem for the core users. Everything else goes into a prioritised backlog for later releases. A smaller first release reaches users sooner and teaches you what really matters.
7. Consider security and compliance up front
Note any requirements for personal data, financial or health information, data residency, access control, and audit logs. These shape architecture and are expensive to add later.
8. Choose a delivery model
- Fixed scope suits well-defined projects: a clear price against a written scope, with changes estimated separately.
- Dedicated team suits products with an evolving roadmap: a stable team billed monthly, with priorities set sprint by sprint.
Either way, insist on working software demonstrated regularly — every two weeks is a good rhythm.
9. Agree on ownership and handover
Confirm in writing that you will own the source code, designs, and accounts, that code will live in a repository you control, and that documentation and a handover session are part of the deliverables.
10. Plan for life after launch
Software needs updates, monitoring, backups, and improvements. Budget for support from the start, and decide who will own the product internally.
A quick pre-project checklist
- Problem statement written and agreed
- Two or three success measures defined
- Build-versus-buy reviewed
- Users and key journeys listed
- Data sources and integrations mapped
- First-release scope agreed; backlog started
- Security and compliance needs noted
- Delivery model chosen
- Ownership, documentation, and handover confirmed
- Post-launch support planned and budgeted
Want a second opinion on your plan? Our custom software development team runs a short discovery phase that produces exactly these artefacts — with no obligation to continue with us.