A software need rarely begins with a complete specification. It starts with a task that takes too long, approvals handled by email or a spreadsheet that has become difficult to maintain. Choosing immediately between SaaS and custom development means selecting a solution before describing the work.
We propose comparing the options against the same process: its users, exceptions, data and operation after delivery. Custom software needs to justify the ongoing responsibility it creates. SaaS needs to demonstrate that its way of working fits the business.
Describe what needs to change for the user
Start with a concrete journey. Who initiates a request? What information is missing today? Who decides? What happens outside the normal case? Which output needs to reach another system?
Separate essential constraints from habits that can change. An access rule or a traceability requirement may determine the choice. The exact layout of an old spreadsheet is not necessarily a requirement. This distinction avoids asking a vendor to reproduce every feature of the current process.
Compare three options against the same criteria
| Criterion | SaaS | Custom software | Combination |
|---|---|---|---|
| Process | Check the fit with real journeys and exceptions. | Identify the specific rules that justify building. | Define what belongs to the product and to the extension. |
| Data | Test imports, APIs, exports and limits for the proposed plan. | Define interfaces, ownership and data quality. | Avoid ambiguous responsibilities across systems. |
| Change | Examine configuration, extensions and dependence on the vendor roadmap. | Plan the budget, skills and prioritisation of changes. | Anticipate how updates affect extensions. |
| Operations | Clarify support, permissions and contractual responsibilities. | Assign maintenance, monitoring and incident handling. | Name an owner for the complete journey. |
| Exit | Verify which data and formats can be retrieved. | Plan for code, documentation, access and handover. | Test whether each component can be replaced separately. |
A combination is worth examining when a standard core fits but a limited journey remains specific. It is not automatically simpler: the interface between components becomes part of the product to operate.
Compare the cost of delivering the service
Comparing an annual licence with the initial development bill is incomplete. Over a common horizon, for example three years, chosen for your decision, include configuration or construction, integrations, migration, training, operations, support, change and exit.
Write down the assumptions that change the cost: users, volumes, interfaces, criticality, availability and frequency of change. Test a more demanding scenario than the initial need. A comparison remains useful without final quotations when unknowns are identified rather than filled with arbitrary amounts.
Microsoft also recommends including development, infrastructure, maintenance and support when evaluating whether to build or buy. That total-cost principle does not, on its own, identify the best option for your business.
Test the issue that could invalidate the choice
Illustrative example. A team wants to manage pricing exception requests. The usual journey looks standard, but some requests combine a margin rule, regional approval and ERP data.
A generic form demonstration does not distinguish the options. A useful test processes a normal request, an exception and missing source data, then retrieves the decision and its history. If the SaaS product handles those cases without disproportionate workarounds, that is concrete evidence in its favour. If a central rule cannot be represented, document that limitation precisely before considering an extension or a custom build.
Decide who will own the product after delivery
Custom software needs an owner who can prioritise its evolution. SaaS also needs someone to manage configuration, permissions and adoption. In both cases, ask who responds when an interface fails and how a new business rule becomes a controlled change.
The scoping output can be a clear decision note: target process, constraints, options considered, cost assumptions, decisive test, decision and conditions for revisiting it. Our Software & AI practice follows this approach. Where planning is involved, the Anaplan/Pigment comparison and data foundations offer complementary perspectives.
