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 buy vs build 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: according to Eurostat, in 2025 ERP software was used by 41.08% of small EU enterprises (10–49 people) and CRM by 24.69%. Almost three small companies in five do not use even an off-the-shelf ERP — so 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.

Buy vs build: four questions that decide the choice

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 €468 a month that gets forgotten

For us, the fixed part of the TCO of a custom web application is €468 a month: €390 for maintenance and €78 for the server. Proposals usually compare build prices, and those €468 only show up on the first invoice after launch. Over five years that is 60 × €468, or €28,080 — 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 €32,500, and for a full application €94,250. Each integration with an external system (CRM, ERP, payments) costs at least €5,200. 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 Europe, because we have not measured one, and we are not going to borrow a single country's figure and call it European. 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 €468 of maintenance. For a build at €32,500 (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 €32,500 plus €28,080, or €60,580 — 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. The difference lies in what protects you: against a SaaS provider the law partly protects you; against a contractor who builds software to order, only the contract does.

Against a SaaS provider, the Data Act protects you

Since 12 September 2025 the EU Data Act, Regulation 2023/2854, has applied (Article 50). It covers data processing services, and recital 81 names software as a service (SaaS) among them explicitly. The contract with the provider has to include, among other things:

• 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)).

Until 12 January 2027, charges for the switch itself may only be reduced ones, no higher than the provider's costs directly linked to the switch, and from that date they disappear (Article 29). One exception: the rule on charges does not apply to services whose main features have mostly been custom-built for one customer and which the provider does not offer at broad commercial scale from its catalogue (Article 31(1)). So if a custom system is delivered to you as a service in the contractor's cloud, write the exit terms into the contract yourselves.

Against a software house, only the contract protects you

EU law settles one case automatically. Under the Computer Programs Directive (2009/24/EC), where a program is written by an employee in the course of their duties or on the employer's instructions, the employer alone may exercise all the economic rights in it, unless a contract says otherwise (Article 2(3)). For an outside contractor the directive says nothing of the kind. Rights do not pass to you on their own: how they pass, in what form the contract has to be made and what happens when it is silent are all matters of national law, and they differ between member states. In some countries copyright itself cannot be transferred at all — only rights of use can be granted.

For software, the key right is the right to change the program. The directive reserves to the rightholder "the translation, adaptation, arrangement and any other alteration" of a program (Article 4(1)(b)). A lawful user may do what is necessary to use the program for its intended purpose, including correcting errors, unless the contract says otherwise (Article 5(1)) — but developing it further, adding features or handing it to another firm to rework is something else. Without a right to alter the program 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

What a contract means when it does not say plainly whether rights are transferred or licensed depends on the law that governs it — and so does how long a silent licence lasts, where it applies and whether it can be terminated. The only safe assumption is not to rely on any default.

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 transfer of rights or a licence that lists the permitted uses, its territory and its term; the right to alter the program; 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.
• Share of companies with ERP and CRM — Eurostat, "E-business integration", 2025 data (extracted May 2026), small enterprises (10–49 people) in the EU.
• Law — Regulation (EU) 2023/2854 and Directive 2009/24/EC, 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.