Custom Software
How should a charity compare software development suppliers?
Compare software suppliers against the same operational brief, acceptance criteria and ownership requirements. Ask for relevant evidence, explicit exclusions and recurring costs before comparing estimates. A proposal should make uncertainty and responsibility easy to inspect.
April 4, 2026 • 2 min read • FSS Growth Team
Published · Updated
For Charity leaders, Faith organisation operations teams, Software buyers.
Sources and evidence
First-party scope and product information. Workflow examples are illustrative; no measured customer outcomes are claimed.
What evidence should a supplier show?
Ask for work relevant to your workflows and a clear statement of what the supplier actually built. Distinguish a product demonstration from a customer reference and a measured result. FSS-built NexSteps documents product capabilities; it does not establish savings or a delivery estimate for your organisation.
A charity referral process and a church volunteer rota have different access and operating needs. Ask how the supplier would investigate these differences without sending personal records in an initial brief.
How do we compare proposals fairly?
Give every supplier the same essential tasks, systems, user roles and constraints. Ask each to separate discovery, design, implementation, migration, training and support. Record assumptions and exclusions alongside the price.
The Software Investment Framework provides a structure for recording options and uncertainty. Proposals are not equivalent when one includes data cleanup and another assumes your team will provide clean records.
Who owns the system after launch?
Ask who controls the code repository, hosting accounts, domains and backups. Request a written explanation of licensing, handover and how another provider could take over. Confirm which responsibilities remain with your organisation.
A support agreement should state how issues are reported, assessed and handled, including what is outside the agreement. Do not infer a response commitment from a sales conversation.
What should discovery produce?
Expect a problem statement, an agreed first release, acceptance criteria, dependencies and unresolved questions. FSS’s custom software development service sets out the kind of engagement to discuss.
Nominate a decision maker who can resolve scope questions and involve people doing the daily work. An illustrative church project might ask administrators and occasional volunteers to test the same registration task so unfamiliar users are represented.
What is the next decision?
Use the Software Project Readiness Kit to prepare one brief. Shortlist suppliers on evidence and fit, then ask how they would resolve the largest uncertainty before committing to a full build.
