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 GUS (Statistics Poland, Główny Urząd Statystyczny), in 2025 ERP software was used by 32.9% of small enterprises (10–49 people) and CRM by 20.0%. Two thirds of small firms 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 PLN 720 a month that gets forgotten

For us, the fixed part of the TCO of a custom web application is PLN 720 a month: PLN 600 for maintenance and PLN 120 for the server. Proposals usually compare build prices, and those PLN 720 only show up on the first invoice after launch. Over five years that is 60 × PLN 720, or PLN 43,200 — almost as much as the MVP itself. You can work out both items for yourself in the maintenance cost calculator.

Our prices, and the market's prices

In our web application cost calculator the starting point for an MVP — a first version with one key path — is PLN 50,000, and for a full application PLN 145,000. Each integration with an external system (CRM, ERP, payments) costs at least PLN 8,000. The calculator shows its result with a range of ±15%, and the maintenance prices are quoted excluding VAT. The market looks somewhat different: in our study of web application pricing in Poland, based on 118 observations, the median quote for an MVP is PLN 30,000 (24 observations), and for large systems with integrations PLN 200,000 (43 observations). The difference tells you about the scope that different contractors fit into the word "MVP", so 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 PLN 720 of maintenance. For a build at PLN 50,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 PLN 50,000 plus PLN 43,200, or PLN 93,200 — 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. Where the differences in quotes for the build itself come from, we cover in the article on app development cost.

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

Under the Act on Copyright and Related Rights (ustawa o prawie autorskim i prawach pokrewnych), a computer program automatically belongs to the client only when it was written by an employee in the course of their duties under an employment relationship (Article 74(3)). Rights do not pass to you on their own from an outside contractor. They pass under a contract that must be made in writing, otherwise it is void (Article 53) and lists the fields of exploitation (pola eksploatacji) explicitly, because it covers only those that are listed in it (Article 41(2)). For software, the key field is the right to adapt and alter the program (Article 74(4)(2)). Without it, 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

If the contract does not say plainly that rights are transferred, the Act presumes that the contractor granted a licence (Article 65). A software licence with no other terms entitles you to use the program for five years, in the territory of the country where your company has its seat, and then it expires (Article 66). An indefinite licence can be terminated by the author, absent contractual terms, with one year's notice at the end of a calendar year (Article 68(1)). An exclusive licence also requires written form, otherwise it is void (Article 67(5)).

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 fields of exploitation and its term; the right to alter the program; and delivery of the source code, the documentation and access to the repository and the servers. 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.
• Market medians — our study of web application costs in Poland, 2026 edition: 118 price observations, with the number of observations given next to every median.
• Share of companies with ERP and CRM — GUS, "Information society in Poland in 2025" (Społeczeństwo informacyjne w Polsce w 2025 r.), small enterprises (10–49 people).
• Law — the Act on Copyright and Related Rights (consolidated text, Dz.U. 2025 poz. 24) and 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.