Custom software or off-the-shelf — how to decide in a company

Custom software is neither better nor worse than off-the-shelf software. It answers a different question — and most bad decisions on this subject come from a company asking it once, for everything at the same time.

In fact the question is settled separately for each function. Email, accounting or the calendar belong to a completely different category from the process that sets your company apart from its competitors, or the one that pulls together data from several places. In a typical company, some tools are worth renting for years, while one or two pieces are worth building.

We write this from both sides of the decision. We build custom business software for clients, but the site you are reading is itself an example of that split: part of it runs on services we pay a subscription for, and part of it we wrote ourselves. Below we show what went where and why, and then turn it into criteria you can apply to your own company — with a five-year total cost of ownership calculation and with how not to become dependent on a supplier, whichever road you take.

What custom software is, and what off-the-shelf software is

Off-the-shelf software is a tool that already exists and is sold to many companies at once — most often as a subscription service (SaaS), sometimes under a one-off licence. You log in and use it. A CRM, an invoicing system, an appointment booking tool, an e-commerce platform. The vendor decides how it develops, and you get what all of its customers get.

Custom software — also called bespoke software, or, for single tools, simply a custom app — is a system built around the way one company works. It can be:

• a system for taking orders and tracking their fulfilment,
• an app for planning the work of crews in the field,
• a customer portal with the history of the relationship,
• a product configurator that makes unusual orders easier to sell,
• a small module that does one thing no off-the-shelf tool does the way it needs to be done.

Between these poles there are two middle roads worth keeping in mind from the start. The first is low-code tools and automations (Make, Zapier, Airtable), which let you glue ready-made services together without writing a full system. The second is the hybrid approach: off-the-shelf tools for whatever is standard, plus a module of your own where the standard ends. We will come back to both.

One thing proposals rarely mention: "custom" does not automatically mean "yours". Whether the code will belong to you depends on the contract — and that has its own section below.

How we split it ourselves

We start with our own case, because here we know not only the outcome but also the reasons.

The table shows the criterion we applied, even though we could not name it straight away: we rent what is the same in every company, and we build where our own data and processes meet. A calendar is a commodity. But the moment someone books a call is, for us, part of that contact's history: where they came from, what they worked out in the calculator beforehand, which ad they clicked. An off-the-shelf booking tool would give us the appointment, and that record would have to be stitched together by hand.

Our own CRM — and what we deliberately did not build into it

Our CRM stores attribution — the ad click identifier, the campaign parameters, the first and the last visit — as well as consents and the path for deleting data on request. From it we export to Google Ads the conversions that happened off the site, such as a phone call after an ad click. That connection could not be made if the contact data sat in someone else's system and the click data in ours.

Just as instructive is what we did not build. The first version had a separate layer for companies — and we removed it, because nothing used it. It came back only when the mailbox synchronisation started recognising the company from the domain of the email address, in other words when a real reason appeared. Custom software tempts you to build everything that might come in handy straight away — and that is the most expensive way to use it.

A decision in which price played no part

The most interesting decision was how to connect our mailboxes to the CRM. There are intermediary companies on the market that offer one API for Gmail and Outlook. At our scale their subscription would have been negligible. Even so, we built the connection ourselves, and in the note on that decision we wrote it down plainly: price was never the argument. The arguments were:

• the intermediary becomes a processor of our correspondence with clients — with a data processing agreement, an entry in the privacy notice and, for providers outside the EU, an assessment of the data transfer;
• the reach of access — the intermediary holds the key to the whole company mailbox, quotes and negotiations included, not to "a bit of metadata";
• dependence on a small supplier on a critical path of the system;
• a ceiling on our own logic — our rules for filtering out automated messages rely on headers that the intermediary's layer can simply hide.

And one line that we consider the most important: the condition under which the decision has to be reopened. If we ever had to synchronise our clients' mailboxes rather than our own, every one of those arguments would turn in the intermediary's favour. A good build-or-buy decision has such a condition written down from the start.

When off-the-shelf software is enough — and the better choice

Off-the-shelf tools have an advantage nothing can replace: they work straight away, someone else takes care of updates, backups and security, and if a tool does not work out, you switch it without losing an investment. And there is still a lot to do with ready-made systems alone. In the European survey that measures it, the smaller the company, the less often it uses even an off-the-shelf ERP or CRM; Switzerland is not covered by that survey, so we give no Swiss percentage, but the lesson does not depend on the number — before you start building, check whether what you are missing is simply a system off the shelf.

In three situations building anything of your own is simply the wrong move.

You are at a very early stage. If the offer changes every few months and the business model is still being tested, a system of your own will write into code assumptions that will be out of date in six months.

Your process is standard for the industry. Invoicing, a simple CRM, team communication, selling through a typical shop — the market is full of tools that do this well and develop faster than any single company would develop its own equivalent.

There is nobody to maintain it, and the processes are not settled. A system of your own needs a caretaker, on the team or at the contractor's. And if everyone in the company does the same thing slightly differently, that has to be put in order first — custom software sets a process in stone, a bad one included.

In these situations, rather than building, reach for:

• a set of simple tools: Notion, Google Workspace, Trello, ClickUp,
• automations that connect ready-made services: Zapier, Make, Airtable,
• off-the-shelf industry systems — CRM, ERP, booking systems for a specific industry,
• a prototype made of a form and a spreadsheet, which lets you test the flow before anyone writes a line of code.

The last point is underrated. An order form connected to a spreadsheet and used for a few months shows which steps are really needed and which only seemed important at the planning stage. If the time to build comes later, you commission it with knowledge rather than a hunch.

When does off-the-shelf software stop being enough?

Off-the-shelf software stops being enough when working around its limits costs more time and money than using it. It usually shows in three symptoms: someone retypes data between systems by hand, the team keeps spreadsheets of workarounds next to the system, and the company pays for licences and features it does not use, because the one it needs is not in any plan.

Spelled out as signals:

• the same data is entered in two or three places — the order in the shop, then in a spreadsheet, then in the accounting system,
• the team works around the system, because the process does not fit the tool's assumptions, and spreadsheets come back "just in case",
• you pay for licences you do not use — a higher plan bought for one feature, or seats for people who log in once a month,
• every department knows something different, because sales work in one tool, delivery in another, and the customer writes on a third channel,
• a new idea for an improvement bounces off the tool's limits, not off the budget or the calendar.

The typical picture is an owner who has "everything sorted": a CRM, invoicing, a ticketing system. Except that each of these tools comes from a different world, there are several logins and several places where something can slip, and the owner spends more time holding the systems together than running the company. That is not an argument for throwing everything out. It is a signal that it is worth looking for the place where the data drifts apart — and that is usually where the first piece worth building lies.

Build or buy software: four questions that decide it

Instead of the general "do we need custom software?", ask four questions — separately for each function you are considering.

Is this process your industry's, or yours?

If you do something the way the whole industry does it, an off-the-shelf tool will almost certainly handle it. If the way you take an order, price an unusual product or serve a customer is what sets you apart, an off-the-shelf tool will force you to adapt to the average. The test is simple: would a customer notice the difference if you did it the way everyone else does? If not, it is an industry process.

Does this function combine data from several places?

For us this was the question that decided things most often. If a function lives on its own, rent it. If its value lies in combining information from several places — the order with the stock, the lead with the ad, the ticket with the customer's history — then that very connection is the candidate for building.

What will the subscription cost for the team you are planning?

Most off-the-shelf tools charge per user or per feature tier. With five people that is immaterial; with thirty it is not. Work out the subscription for the team you expect in three years, not for the one you have today.

Who will maintain it — and what will you take with you when you leave?

A system of your own needs someone who looks after the server, the updates and the security — on your team or at the contractor's. An off-the-shelf system needs an exit plan: in what format you will take the data out and what will stay on the vendor's side. If nobody in the company can answer this, note it down as a risk — we come back to it under vendor lock-in.

If you are still unsure after these questions, try the quiz "Off-the-shelf SaaS or custom software?". Seven questions about competitive advantage, budget, time, team and integrations lead to one of several recommendations — from off-the-shelf SaaS, through SaaS with integrations and the hybrid approach, to building.

Total cost of ownership over five years

The most common mistake in this decision is comparing a monthly subscription with a one-off build price. They are two different numbers describing different periods. What has to be compared is the total cost of ownership, TCO for short — everything you will spend on a given function over the same horizon, not only the price at the start.

On the off-the-shelf side, TCO is made up of the subscription multiplied by the number of users and months, surcharges for higher plans and add-on modules, the cost of automations that patch the gaps, and the cost of leaving — moving the data when the tool stops being enough.

On the custom software side: the build, then ongoing maintenance — the server, updates, fixes — and further development, because a system meant to serve for years will be changed.

The CHF 360 a month that gets forgotten

For us, the fixed part of the TCO of a custom web application is CHF 360 a month: CHF 300 for maintenance and CHF 60 for the server. Proposals usually compare build prices, and those CHF 360 only show up on the first invoice after launch. Over five years that is 60 × CHF 360, or CHF 21,600 — not far short of what the MVP itself costs. You can work out both items for yourself in the maintenance cost calculator.

Our prices, and why we don't quote a market median

In our web application cost calculator the starting point for an MVP — a first version with one key path — is CHF 25,000, and for a full application CHF 72,500. Each integration with an external system (CRM, ERP, payments) costs at least CHF 4,000. The calculator shows its result with a range of ±15%, and the maintenance prices are quoted excluding VAT.

We do not set these against a "market median" for Switzerland, because we have not measured one, and converting another country's figure into francs would produce a number that sounds precise and measures nothing. What we did learn from our study of web application pricing in Poland travels to any market: the same word "MVP" covered very different scopes from one contractor to the next. A median is not a price. When you compare quotes, ask for the list of features, not the name of the package.

The break-even point

The simplest calculation: the build cost divided by the monthly saving, that is, the difference between the subscription and the CHF 360 of maintenance. For a build at CHF 25,000 (the subscription spend is an assumption to replace with your own figure, not market data):

For comparison, the TCO of your own MVP over the same five years is CHF 25,000 plus CHF 21,600, or CHF 46,600 — without any further development. When the subscription spend is small, a build practically never pays back, even if it feels like "an investment for years". It starts to pay only once subscriptions have grown with the team, or when it is about something an off-the-shelf tool does not do at all.

The calculation makes two simplifications. It assumes your own system replaces the whole tool — in practice it often replaces only part of it. And it leaves out the time the team gets back when it stops retyping data; value that separately and cautiously. Why quotes for the build itself differ so much is a subject of its own — and the best defence against it is a written list of requirements.

Hybrid: off-the-shelf where things are standard, your own where the advantage is

In practice, the middle road wins most often. Custom apps do not have to replace anything wholesale: you keep the off-the-shelf tool for what it does well, and build one module where the standard ends. You connect the whole through an API, an automation or a thin intermediate layer.

Two examples from our conversations with clients. A training company used an off-the-shelf course platform that handled materials and payments well, but did not send certificates or remind participants about their assignments the way the company needed. Instead of changing platforms, a small module was added that did only those two things. A Shopify store wanted every customer to receive, after a purchase, a personalised plan for using the product, prepared from a short quiz. A separate service was built that generated the plan as a PDF and sent it by email — while everything else carried on running on Shopify.

Our own case is of the same kind. Email stays on subscription and remains the source of truth about correspondence — the CRM takes only the metadata, a short snippet and a link to the message from it, never the full content or the attachments. The calendar stays with Google, and our module only reads free slots and writes new meetings.

A hybrid makes the most sense when the budget is limited but one process is not handled well by anything; when you want to test one unique function before building more around it; and when the problem is connecting several tools rather than the tools themselves. In that last case, start with the article on business process automation — automation often solves the problem before anything has to be built.

Code, data and the way out — vendor lock-in in both directions

Vendor lock-in is the situation in which changing supplier costs so much that it practically stops being possible. It is usually discussed in the context of SaaS: the data is with the provider, the export is thin and the price list keeps rising. Yet the risk of dependence runs both ways. What protects you is the question that matters — and for a Swiss company the answer is the same on both sides: the contract. The EU has written exit rights for cloud customers into law; in Switzerland you have to negotiate them.

Against a SaaS provider: the EU Data Act, and why it does not cover you

Since 12 September 2025 the EU Data Act, Regulation 2023/2854, has given customers of data processing services — recital 81 names software as a service (SaaS) among them — exit rights that the contract has to reflect:

• a notice period for starting the switch of no more than two months (Article 25(2)(d)),
• a transitional period of no more than 30 calendar days, during which the contract remains in force and the provider helps with the move (Article 25(2)(a)),
• an exhaustive specification of the data that can be ported, including at a minimum all exportable data (Article 25(2)(e)),
• no switching charges from 12 January 2027, and until then only reduced ones, no higher than the provider's own costs of the switch (Article 29).

The regulation applies to providers "irrespective of their place of establishment, providing such services to customers in the Union" (Article 1(3)(f)). A Swiss company buying for its Swiss business is not a customer in the Union — whether the provider is Swiss, American or European — and Swiss law has no equivalent for business customers: the right to data portability in the revised Data Protection Act (Article 28) belongs to individuals, for the personal data they have disclosed themselves, not to a company for its business data.

So in Switzerland, read the list above as a checklist rather than as protection. Ask for those four terms in the contract before you sign: how much notice, how long a transition, which data comes out in which format, and what the move will cost. A provider that already serves customers in the EU has to offer these terms there, which makes it a fair question to put; whether it agrees to them in a Swiss contract is something to find out before you depend on it, not after. And if a custom system is delivered to you as a service in the contractor's cloud, write the exit terms down with the same care.

Source code ownership: against a software house, only the contract protects you

Swiss law settles one case automatically. Under the Copyright Act, where a computer program is created under an employment contract in the course of professional duties, "the employer alone shall be entitled to exercise the exclusive rights of use" (Article 17). For an outside contractor there is no such rule. The rights stay with whoever wrote the code until a contract transfers them.

Swiss copyright can be assigned (Article 16(1)) — but the assignment of one right does not include the others unless that was agreed (Article 16(2)), and acquiring a copy of a work does not carry the right to exploit it (Article 16(3)). A contract that says "the contractor hands over the application" without naming what passes may give you considerably less than you think.

For software, the key right is the right to change the program. The author has the exclusive right to decide "whether, when and how the work may be altered" (Article 11(1)(a)). Without that right in your contract, another contractor cannot lawfully develop your system — and that is vendor lock-in in its purest form, just on the other side.

Software licence or assignment of rights

The Copyright Act sets no default term or territory for a licence, and it does not itself prescribe a form for the contract. That is a reason to be precise in writing, not a reason to skip it: whatever the contract leaves out is exactly what you will be arguing about on the day you want to change contractors.

A licence is not necessarily bad — it is often cheaper and is enough for a module that is meant to work rather than to evolve. But choose it deliberately. Insist that the contract sets out: either the assignment of the rights you need — to use, to alter, to develop further and to let another contractor do so — or a licence that lists those same uses together with its territory and its term; delivery of the source code, the documentation and access to the repository and the servers; and the law that governs the contract. The open-source libraries every system stands on — ours, for example, on Payload CMS, Next.js and React, under the MIT licence — stay under their own licences; the contractor should be able to list them.

How to start if the answer is to build

Pick the smallest module that brings data together — one function that solves the most important problem, instead of a full system. The best candidate is usually the place where someone retypes data by hand today: there the effect is visible from day one and the risk is smallest. Treat that module as a first version with one key path, and resist adding anything that is not on it.

Write down the requirements in plain language and try two or three off-the-shelf tools. The list of what is missing from them is the best specification you can give a contractor.

Write the way out into the contract before you start. Rights or a licence, the permitted uses, the source code, the documentation — and the condition under which you will revisit the decision.

Ask for a quote against a list of requirements, not "how much does an app cost". Without a scope you will get numbers that cannot be compared. You can work out an indicative cost in the web application calculator; ask each contractor to walk you through their process, from discovery to launch, before you compare the prices.

If you are looking for a contractor, see how we approach custom software development — internal systems, integrations, customer portals. And if what you lack is someone to take responsibility for the decisions themselves, we help through technology consulting.

Where these numbers come from

• Build and maintenance prices — our own, from the configuration of the web application cost and maintenance cost calculators, as of 22 September 2026 (maintenance prices excluding VAT); the calculator gives its result with a range of ±15%.
• Break-even point and TCO — arithmetic on assumed subscription spending, described in the text as assumptions, not market data.
• Companies with ERP and CRM — no Swiss figure: Switzerland is not covered by Eurostat's "E-business integration" survey, which is the source of the pattern described in the text.
• Law — the Swiss Copyright Act (SR 231.1, status 1 July 2025) and, as a reference point for contract terms, Regulation (EU) 2023/2854, read at source on 22 September 2026.
• Our split of tools — the state of the system this site runs on, and our notes from design decisions.