Web app, SaaS or custom: which route fits?

A web app, SaaS and a custom platform aren’t three mutually exclusive product types. A web app describes how you use software, SaaS describes how it’s delivered as a service, and custom development describes the need it is built for. A purpose-built platform can therefore be both a web app and a SaaS product. The useful choice is whether to use existing software, extend it or commission something of your own. Our custom software guide covers delivery; here we compare those routes.

Sources checked in September 2026. Check the current terms of the service you are considering.

Which question does each term answer?

You use a web app through a browser. That says nothing about a maximum number of users or the complexity of the application. AWS’s web app examples include collaboration tools, online shops and online banking. A browser window doesn’t automatically make an application small or suitable only for internal use.

SaaS means Software as a Service. You use software that a provider makes available and manages as a service. Subscription or usage-based payment is common, as AWS describes in its SaaS explanation. Buying SaaS for your business and commissioning a SaaS product to offer yourself are different decisions.

“Custom platform” isn’t a fixed technical category either. Ask which tasks, users and systems it refers to. A platform can support internal work, give customers access or be offered as a product. The word doesn’t establish who may change the code or who resolves incidents.

Which routes can you actually compare?

Start with the outcome you need. Do you want staff to process a quotation, or do you want to sell software that helps other businesses prepare quotations? The screens might look similar. The responsibilities differ.

Route	What do you buy or build?	What should you investigate?
Use existing SaaS	Access to a managed product	Does the process fit its functions, settings and terms?
Extend existing software	A connection or defined extra application	Which task is missing, and which system remains authoritative?
Build custom software for your own use	Software for your agreed business process	Who defines the scope and arranges development, operation and handover?
Offer your own SaaS product	A service for external customers	Which recurring problem do you solve, and how will you deliver the service over time?

These routes can coexist. You can build a customer portal and buy accounting software as SaaS. A SaaS provider can also use external services for parts of its product. Assess the boundaries between those parts rather than choosing one label for the whole business.

When does an existing package fit?

An existing package is a candidate if your team can perform the required process with it and you can accept the product and operational arrangements. Demonstrate an ordinary task and an exception. For a quotation process, that might be a price amendment after a proposal has already been approved.

Ask how far settings and available modules get you. A different way of working needn’t be a reason for custom development; sometimes adapting to the package is sensible. But make the remaining manual work visible. If someone must copy data into several files after every approval, include that in the comparison.

Look beyond the demonstration. What access does a new employee receive? What changes if you cancel a module? Which data can you export, and what remains usable only within the product? Those are questions about the particular service and agreement, not SaaS in general.

A low subscription price doesn’t automatically make a package suitable. An elaborate development proposal doesn’t prove you need that either. Our AFAS and custom software comparison explains how to investigate configuration and an addition first.

When is an addition enough?

When the existing package supports the core work well and one defined task is missing. Perhaps customers need to add information to a request without accessing your internal administration. A separate screen may help while pricing agreements and invoicing stay in the existing system.

Make the boundary explicit. Which data does the addition read, what may it change and where does a request become final? An API only provides capabilities the supplier actually exposes. Ask for the required actions to be demonstrated, including an error or correction. Our explanation of connecting software explores this further.

When should you build custom software for your business?

When you need to support a specific task that existing options don’t adequately address after assessment. Explain what users must complete and which exception isn’t currently handled well. “Our business is unique” is too broad for that.

Consider a fictional quotation process. Staff combine data from existing systems, apply an agreed calculation and ask an authorised colleague to approve an exception. The request is only useful if rejection, missing information and a later correction are handled too. That could be a defined custom project without replacing the whole business administration.

Custom development gives you room to shape behaviour around the assignment. It comes with decisions and maintenance. Who decides which request takes priority? Who checks a changed calculation rule? And who remains responsible if the original sponsor leaves your business?

Also ask which parts rely on existing services or libraries. Custom software doesn’t mean everything is developed from scratch. Nor does it mean subscriptions or supplier dependencies disappear after handover.

What changes when you offer SaaS yourself?

You then deliver an ongoing service to other organisations or users. You need to understand which problem they solve with it, who makes the buying decision and why they keep using it. An internal application that works for your team doesn’t answer those questions yet.

Explore the proposed process with intended customers. Let them perform a representative task and discuss what adoption would take. There isn’t a universal minimum number of paying customers or revenue threshold that proves every idea. Describe the evidence you need to justify the next investment.

Work beyond the core function includes bringing customers on board, managing access, releasing changes, support and ending use. Not every service needs self-registration or automatic subscription payments. A provider can also onboard customers with assistance and invoice them. Choose the service you intend to deliver and budget for the work involved.

Examine what happens when customers want different things. Can settings accommodate them, or do separate product variants emerge? Agree on who decides and how changes are tested. An extra customer is only well served if you can continue operating the service you’ve promised.

Must SaaS always use one shared database?

No. AWS distinguishes SaaS models with shared resources, resources dedicated to each customer and combinations. Dedicated resources can still sit within a common operational and delivery approach. The number of databases therefore doesn’t determine whether you offer software as a service.

The decision belongs with your requirements and operations, not an arbitrary user threshold. Ask how access to customer data is bounded and how updates, recovery and capacity problems are handled. A separate database doesn’t replace checking who may request a file or report.

Adding a customer identifier isn’t complete separation either. Ask the developer to demonstrate that a user can’t read or change another customer’s data, including outside the normal screen flow. Derive the required checks from the application rather than fixing on one database pattern as the default answer.

Who handles maintenance, access and handover?

With SaaS, the provider operates the offered service, but your organisation retains tasks of its own. Microsoft’s shared responsibility explanation identifies areas including data, settings and user management. Establish who withdraws accounts, investigates errors and checks changes for your particular service.

You can outsource technical operations for software you commission too. You’ll want the same clarity about updates, availability of support and recovery. Commissioning software doesn’t mean your staff must manage servers; a maintenance agreement doesn’t mean every future change is included.

Record which rights and materials you receive for each component. Ask about source files, documentation, configuration and dependencies, and rehearse a handover. Our code ownership guide explores this. Ownership, a licence to use software and the practical ability to run it elsewhere are different questions.

Also check a data export containing real relationships and attachments. Seeing a download button isn’t enough to establish whether a successor can use the result. This applies to a SaaS package and to an application you’ve commissioned.

How do you compare cost and timing fairly?

Use the same task, amount of data and operational expectations. Separate one-off and ongoing work: selection, configuration or development, migration, connections, training and use after launch. Include your own staff’s time.

For SaaS packages, users, modules or usage units may affect the bill. With commissioned software, scope, existing data and dependencies matter. If you offer SaaS yourself, you must also budget for delivering it to customers. None of these routes has a fixed price or payback period determined by its label alone.

Ask for a schedule with stated assumptions and decision points. What can start, what depends on access to a source and which trial could still change the scope? A package may require implementation work; a defined custom application may be smaller than the word “platform” suggests. Our software cost guide helps compare proposals against the same items.

How do you actually get started?

Write down who will use the software and which task they must complete. Then distinguish a solution for your business from a service you intend to deliver to external customers. That determines which questions to answer first.

Ask existing software and a custom software development proposal to handle the same example. Compare the remaining manual work, operational tasks and dependencies before deciding how much to build yourself.

Want to assess those routes together? Book a call and bring your process and current systems.