Custom software or SaaS: how do you make the right choice?

You have identified a need: track field visits, centralise requests, produce quotes or give customers better visibility. Several software products promise to cover it. Meanwhile, a custom application could match your terminology and rules precisely.

The choice is not simply between paying a subscription and owning your software. A SaaS product can require substantial integration work. Custom software needs operations and ongoing development. A hybrid approach can avoid rebuilding functions that existing tools already handle well.

Compare the options against the work to be done, their actual limitations and their full cost. A preference for a particular technology or pricing model comes later.

Separate standard requirements from what makes your business different

A company can have specific habits without needing specific software. Before asking for an exact reproduction of the current process, ask whether each particularity improves the service or reflects a historical constraint.

A twelve-step form may exist because three older tools did not communicate well. Reproducing those steps in a new application would preserve the problem.

Other rules really are essential: a contractual calculation method, access rights organised by location, an approval sequence or information that must remain available to staff in the field. A product listing “customisation” as a feature does not establish that it can support these requirements properly.

Separate your requirements into three categories:

• Essential: their absence prevents the service from working or creates an unacceptable risk.
• Useful: they improve efficiency, but a workaround remains possible.
• Habits to reconsider: they deserve a discussion before becoming specifications.

Review the list with users and the person responsible for the process. A requirement that seems minor in a management meeting can represent twenty extra actions for the team working in the tool every day.

Evaluate SaaS products with your own scenarios

A sales demonstration follows the journey the vendor has prepared. To assess the fit with your business, prepare a representative case and ask to work through it from start to finish.

Consider a fictional example: a maintenance company is looking for a system to track field visits. The scenario should not stop at creating a ticket. It could include:

1. a request from a customer responsible for several sites;
2. assignment to a technician with limited access rights;
3. adding photos and a report from a mobile device;
4. postponing a visit because a spare part is unavailable;
5. approval by the site manager;
6. exporting the information needed for invoicing.

Observe what works immediately, what requires configuration and what needs external code. Check error handling too: a wrongly selected site, a duplicate record or a job closed too early.

Ask which features are included in the plan you would actually buy. An API, advanced permissions, a test environment or a complete export may depend on the subscription tier. Your budget needs to reflect that configuration, not the entry-level price.

Compare total costs over the same period

Choose a common time horizon, such as three years, and use the same volume assumptions for every option. The goal is not to predict the future perfectly, but to make the differences visible.

For SaaS

Add up subscriptions, any usage-based charges, configuration, data migration, integrations and user onboarding.

Include the internal costs that will remain: checking synchronisation, processing exports, administering access or working around missing features. A daily manual workaround can matter more than the price difference between two subscriptions.

For custom software

Include discovery, design, development, testing and deployment. Then account for hosting, monitoring, backups, updates, support and changes to business requirements.

Clarify what the maintenance offer covers. Fixing a defect, adapting to a changed integration and developing a new feature are different services. A line saying “maintenance included” is not enough to distinguish them.

For both options

Vary the assumptions: twice as many users, more cases, a new subsidiary or another integration. Consider a less favourable scenario in which adoption is slow, too.

A high per-user price does not automatically make custom software more economical. Developing a tool that people do not use remains a poor investment, even if the marginal cost of adding an account is low.

Examine integrations before signing

The existence of an API is a starting point, not a guarantee that your workflow will be straightforward. Check the operations you actually need: reading, creating, updating, exporting and receiving changes.

A few questions can prevent surprises:

• Can you retrieve records using stable identifiers?
• Are changes sent through webhooks, or do you need to poll the API regularly?
• What rate limits and subscription restrictions apply?
• How can you detect an incomplete synchronisation or rerun a process?
• Is a test environment available?
• Who handles a change to the API?

The same questions apply to custom software. A bespoke interface does not remove the constraints of the systems it connects to.

If your main need is to move information between existing tools, a targeted business automation may be more appropriate than a complete new application.

Plan your exit from the start

With SaaS, check the format and scope of exports. Can you retrieve attachments, history, relationships between records and permissions? Ask what remains accessible when the subscription ends and when the data will be deleted.

With custom software, establish the rights to the code and deliverables, but also how they can be accessed in practice. The repository, hosting accounts, configuration, deployment procedures and backups need to be transferable under the agreed terms.

Having the code does not automatically mean being able to operate the product. Documentation, knowledge of the business and the condition of its dependencies matter too. Ask how another team would diagnose an incident or deliver a change.

The ability to switch providers needs to be organised. It is not an exclusive property of either approach.

Consider a hybrid solution

You rarely need to rebuild email, a calendar or payment processing to solve an operational tracking problem. A custom application can rely on existing services while concentrating development on the business-specific journey.

In the maintenance example, the invoicing system can remain in place. Custom development can focus on the customer portal and job tracking, with a controlled transfer of information into invoicing.

This reduces the scope you need to build. It still carries integration costs and a dependency on each provider, so it also needs to be assessed as a complete operating setup.

Make a decision you can explain

Choose SaaS when your essential requirements are covered, the adaptations remain reasonable and the operating conditions suit your organisation.

Consider custom software when the gaps affect a genuinely important process, workarounds are expensive and the business can fund the product’s upkeep over time.

If the use case itself is uncertain, do not decide solely on the strength of a long feature list. A narrowly scoped MVP can help validate the need before a larger investment: choose one complete journey, a few relevant users and an observable outcome.

To prepare the decision, gather three things: your business scenarios, the full cost of each option and the points that remain unverified. We can help you compare those options, including when an existing product is sufficient.