# Custom software or SaaS? Start with the work.

> A practical way to compare workflow fit, ownership, and long-term responsibility before choosing what to build or buy.

- Published: Sep 25, 2026
- Topic: Software decisions
- Author: RDR Digital
- Original: https://rdr.digital/blog/custom-software-or-saas

Choosing software often starts with a demo. A better starting point is a normal working day: an order comes in, someone checks it, another person approves it, and a customer waits for an answer. What needs to happen between those moments?

The comparison becomes more useful when you can describe that work. A long feature list tells you what a product includes. It does not tell you whether your team can complete its most important task comfortably.

## Write down one complete workflow

Pick a recurring task that matters to the business. Describe who starts it, what information they need, who makes the next decision, and what a successful result looks like. Include an exception: a cancellation, an incorrect address, an approval that never arrives.

For an illustrative wholesale ordering process, the sequence might be: a customer requests stock, a sales representative checks their agreed prices, a manager approves an exception, and the warehouse receives the order. Bring that example to a vendor demonstration. Ask to follow it from beginning to end.

Separate requirements into three groups:

- **Essential:** the workflow cannot function without it.
- **Flexible:** the team can reasonably change how it works.
- **Later:** useful, but unnecessary for the first release.

This is a discussion aid, not a score that automatically chooses the right product.

## Test a product before assuming you need a build

An existing product deserves a fair trial against your requirements. Ask which parts are configuration, which require an add-on, and which need custom development. Request a demonstration with representative sample data rather than accepting a promise based on a checkbox.

The UK Government Digital Service's [build-or-buy guidance](https://technology.blog.gov.uk/2021/02/03/to-build-or-to-buy-thats-the-technology-question/) makes a useful distinction: common needs may suit existing products, while a combined approach can make sense for other requirements. It also stresses the need to oversee the service over its lifetime. These are useful decision principles, rather than procurement rules for every business.

A product can fit most of the workflow while leaving a valuable gap. That gap is worth naming precisely. “We need flexibility” is difficult to evaluate. “A sales manager must approve an exception before an order reaches the warehouse” is something you can test.

## Compare the responsibilities, too

Use the same questions for both proposals. Avoid assuming that a subscription covers every operational task, or that commissioning software automatically includes every ownership right.

| Question to ask                        | Product or SaaS proposal                                    | Custom development proposal                                           |
| -------------------------------------- | ----------------------------------------------------------- | --------------------------------------------------------------------- |
| Who can change the workflow?           | Confirm configuration limits and available extensions.      | Confirm what is included and how changes are scoped.                  |
| How does information leave the system? | Test the export formats and check contract terms.           | Specify exports, documentation, and access in the delivery agreement. |
| Who handles an incident?               | Check support scope and escalation arrangements.            | Agree monitoring, support ownership, and response arrangements.       |
| What costs continue after launch?      | Identify subscriptions, add-ons, usage, and administration. | Identify hosting, maintenance, support, and third-party services.     |

The answers belong in the comparison, not in a conversation you hope someone remembers later.

## Look for the smallest useful custom layer

A decision does not have to replace everything. For example, a business might keep its existing accounting tool and add a customer portal around a missing approval process. This is an illustrative possibility, subject to the accounting tool's integration capabilities and terms.

Before accepting that approach, ask where information is entered, which system owns it, and how the team will resolve a failed update. A useful connection has a clear operational owner.

## Leave the decision meeting with evidence

A strong decision record can be one page: the workflow, options tried, important gaps, continuing responsibilities, and the reason for the chosen approach. Record assumptions that still need testing and who will test them.

If the choice is still unclear, define a small trial around the riskiest question. A working example of the approval flow may teach you more than another general presentation.

When you are ready to compare proposals, use the same scope for each. Our guide to [software project costs](https://rdr.digital/blog/what-drives-software-project-cost) explains how to make those comparisons more useful.

## Sources

- [UK Government Digital Service: To build or to buy](https://technology.blog.gov.uk/2021/02/03/to-build-or-to-buy-thats-the-technology-question/)