Custom software cost starts with a defined scope.
There is no single useful price for custom software without knowing what it must do. For UK charities and faith organisations, a budget should account for workflows, user roles, integrations, migration and ongoing operation. This guide explains scope drivers; it is not a price list or quotation.
By Faithful Software Solutions · Updated
Give budget holders a decision they can assess.
A list of features rarely explains the full work involved. Describe the operational problem, who will use the system and what must happen in the first release so trustees and budget holders can compare proposals on the same basis.
Separate essential scope from later work.
A useful brief defines what must be accepted before launch and what can wait.
- Essential workflows and the people responsible for them
- User roles, access boundaries and reporting needs
- Existing systems, migration and integration requirements
- A first release with explicit acceptance criteria
What changes the amount of work?
A form feeding one reviewed queue differs from a portal with several roles, account recovery, historical records and external integrations. Unclear data, undocumented systems and complex exceptions increase the work needed to establish and deliver a reliable scope.
Budget beyond the initial build.
Ask proposals to distinguish discovery, design, implementation, migration and launch from hosting, licences, maintenance, support and later changes. Confirm what is included, how changes are priced and who owns ongoing operation.
Use a real product to make the questions concrete.
FSS-built NexSteps includes role-scoped access, parent onboarding and billing workflows. Each illustrates a scope question a buyer should ask. NexSteps is not used here as a price benchmark for your project.
Compare like-for-like proposals.
Ask each supplier to state assumptions, exclusions, acceptance criteria, responsibilities and recurring costs. Compare the same first release across proposals, including migration, training and handover.
Watch for work hidden outside the estimate.
Unassigned data cleanup, vague support terms and integrations that have not been examined can leave gaps in a budget. Resolve those responsibilities before making a delivery commitment.
A clear path from problem to working software.
Understand and scope
Map the people, workflows and constraints. Agree what success looks like before committing to a build.
Build and review
Work through a defined scope with working updates, explicit decisions and review points for your team.
Launch and hand over
Plan migration, testing, documentation and support so the software can be operated and maintained.
Frequently asked questions
Can you give a fixed price before discovery?
A defensible price needs an agreed scope and assumptions. An initial discussion can establish what must be examined before a proposal is prepared.
How can a charity control the scope?
Define the essential first release, nominate a decision maker and assess proposed changes against the agreed acceptance criteria. Keep later ideas separate from launch requirements.
Should we include a recurring budget?
Yes. Ask about hosting, licences, maintenance, support and future changes so the organisation understands the cost of operating the software after launch.