Custom Software vs Off-the-Shelf: How SMEs Should Decide

Buy off-the-shelf software when your process works the same way as everyone else’s. Build custom software when the process is part of how you win, when integrations or data rules make standard tools awkward, or when per-user licenses at your scale cost more over five years than a build. Most SMEs end up in between: a standard tool, configured, plus a custom integration or module for the part that doesn’t fit. Below you’ll find a seven-point decision framework, a comparison table, a worked five-year cost example with labeled assumptions, and what a sensible first phase looks like.

What is the difference between custom and off-the-shelf software?

Off-the-shelf software is built once for many customers and rented or licensed: bexio or Abacus for accounting, HubSpot or Salesforce for CRM, Shopify for online shops. Custom software is built around one company’s processes, and the company owns the rights or holds a license. Off-the-shelf starts faster and costs less at first. Custom fits better and can cost less at scale.

The line is not sharp. Most standard tools can be configured, and most custom systems are assembled from standard components: a payment provider, an email service, an identity provider. The real question is where your own code starts.

Which factors decide between build and buy?

Seven factors decide it: how much the process differentiates you, how many systems it has to connect, how many users and transactions it serves, total cost over three to five years, lock-in, where the data must live and which compliance rules apply. Score each one for your case. A single strong factor, such as a unique process or a strict data-location clause, can outweigh the rest.

Process differentiation

If the process is standard, such as bookkeeping, payroll or sending newsletters, buy. Customers don’t care how you post invoices. If the process is how you compete (a quoting engine for configurable products, a service workflow with your own rules, a customer portal), standard software makes you work like everyone else, or you bend the tool until its upgrades break your changes.

Integration needs

Count the systems the process touches: website, CRM, accounting, e-banking, warehouse, shop. Check that each standard tool has a documented API. bexio, for example, publishes a REST API for contacts, sales documents and accounting, with OAuth 2.0 access. When a process runs across four or five systems, the integration is often the real project, whether you buy or build.

Scale

Per-user subscriptions grow in a straight line with headcount. Custom software has a high fixed cost and running costs that grow more slowly. At ten users the subscription usually wins; at a hundred the comparison can flip. Watch transaction volume as well, because some tools charge by contacts, orders or API calls.

Total cost over three to five years

Compare full costs, not a license fee against a build price. For standard software that means licenses, implementation, integrations, data migration, training, admin time and price increases. For custom software it means discovery, build, hosting, monitoring, security updates, small changes and an exit plan. The worked example below shows the arithmetic.

Lock-in

Both options lock you in, in different ways. With a SaaS tool, check export formats, API limits, contract length and what happens to your data when you leave. With custom software, the risk is dependence on one developer. Reduce it with the code in your own repository, documentation, a common technology stack and a clear rights clause: in Switzerland the employer rule for software (Art. 17 CopA) covers employees, not agencies.

Data location

The revised FADP does not require Swiss hosting. It allows disclosure abroad to countries on the Federal Council’s adequacy list, which includes the EU and EEA states, or with safeguards (Art. 16 FADP). Some customers and sectors require Swiss hosting by contract. AWS and Google Cloud both operate cloud regions in Zurich, and Swiss hosting providers exist, so data location alone rarely forces a custom build. It does rule out some SaaS tools.

Compliance

List the rules your data falls under before you choose: the FADP (data protection by design and by default in Art. 7, data portability in Art. 28), ten-year retention of accounting records (Art. 958f of the Code of Obligations), and any sector rules in finance or health. Standard tools often cover these out of the box. A custom system has to implement them, including audit logs, retention and deletion.

Is there a third option between build and buy?

Yes, and for most SMEs it is the right one: keep standard software for commodity functions and build only the missing piece. That piece is usually an integration between tools, a customer or partner portal, a workflow application on top of the standard system, or reporting that combines several sources. You get a close fit where it matters and keep vendor upgrades everywhere else.

We took this route for a software client whose affiliate program runs on an established affiliate-tracking platform. Instead of replacing the platform, we built a separate system that reads from it through the platform’s official API client and adds the win-back logic the client needed: activity metrics, segmentation, a reactivation score and a multi-step sequence. The integration is read-only by construction. It can call only an allow-list of read operations, and a test proves that a full import makes nothing but read calls. The affiliate reactivation case describes the pipeline.

How do the options compare?

The table summarizes the trade-offs. Read it row by row: the option that wins on the rows that matter most in your case is usually the answer, even if it loses elsewhere. Upfront cost is rarely the deciding row. Fit to the process and running cost over five years usually are.

Criterion	Off-the-shelf	Configure and integrate	Custom build
Time to first use	Days to weeks	Weeks to a few months	Months
Upfront cost	Low	Medium	High
Running cost	Grows with users	Licenses plus upkeep of the custom part	Hosting and maintenance; grows slowly with users
Fit to your process	You adapt to the tool	Standard where possible, custom where it matters	Built around your process
Integrations	Limited to the vendor’s API and connectors	Built for your systems	Built for your systems
Control of data location	Vendor’s options	Mixed	Your choice
Lock-in	Vendor and its data format	Vendor for the core, your code for the rest	Developer, reduced by ownership and documentation
Upgrades	Vendor ships them, including changes you didn’t ask for	Vendor for the core, you for the custom part	You plan and pay for them
Best when	The process is standard	One part of the process is special	The process is the product or the advantage

What does a five-year cost comparison look like?

The example compares the three options for the sales and order process of a hypothetical company, used by 20 people, then by 60. All figures are round assumptions chosen to show the method. They are not market prices and not a Sensaria quote. What matters is the shape of the result: which option is cheapest changes with the number of users.

Illustrative assumptions:

• Off-the-shelf: CHF 90 per user per month; CHF 25,000 for implementation; CHF 15,000 for an integration with the accounting system, plus CHF 3,000 a year to maintain it.
• Custom build: CHF 140,000 to build; running costs of 15% of the build cost per year (CHF 21,000) for hosting, monitoring, updates and small changes; CHF 5,000 a year of extra hosting at 60 users.
• Configure and integrate: a lower-tier standard tool at CHF 50 per user per month, because the special part of the process lives in a custom module; CHF 15,000 for implementation; CHF 60,000 for the module plus 15% a year (CHF 9,000) to run it.
• Not included: internal staff time, training, data migration and VAT.

Option (CHF, excl. VAT)	One-off	Per year, 20 users	5 years, 20 users	5 years, 60 users
Off-the-shelf	40,000	24,600	163,000	379,000
Configure and integrate	75,000	21,000	180,000	300,000
Custom build	140,000	21,000	245,000	270,000

At 20 users, buying is cheapest by a clear margin, and a custom build would need a strong fit argument. At 60 users the order reverses. Configure and integrate is never the cheapest here, but it stays close and is the only option that combines vendor upgrades with a fit for the special process. With your own numbers, also run the case where the vendor raises prices or headcount grows faster than planned.

When is each option the clear choice?

Off-the-shelf is the clear choice when the process is standard and a tool covers most of it without heavy customization. Custom is the clear choice when the software is your product or the core of your service, when no tool fits your data model, or when the license bill at your size exceeds building and running your own. In between, configure and integrate.

The same logic applies to CRM. Most SMEs are best served by a configured standard CRM with good integrations. A custom CRM makes sense when the sales process is unusual or the CRM has to live inside your own portal; CRM automation: where to start covers the integration side.

What does a sensible first phase look like?

Start with a short discovery, typically two to six weeks depending on how many processes and systems are involved, that ends in a decision per component: buy, configure or build. Then ship one process end to end to real users before committing to the rest. A first release that fully replaces one spreadsheet is worth more than a half-finished platform.

A useful discovery produces:

• a map of the process as it runs today, including the workarounds and spreadsheets;
• an inventory of the systems involved, their APIs and any gaps;
• a first data model: the main objects and which system holds the master record for each;
• a buy, configure or build decision for each component, with the reasons;
• a scoped first release with a fixed-price or phased proposal.

How Sensaria helps you decide

We don’t start from a default answer. In discovery we look at your process, systems and data, and recommend standard software where it fits, including tools we would neither build nor run for you. Where custom code is justified, we build it on a widely used stack such as TypeScript, Python and PostgreSQL, and document it for handover. After discovery you receive a fixed-price or phased proposal.

See custom software development for how we approach builds and integrations, or describe your process and we’ll tell you which option we would choose.