Almost every company that comes to us has the same file. A spreadsheet someone maintains “on the side” because two systems refuse to talk to each other. Everyone knows about it, nobody likes it, and its author has accidentally become the most important person in the process — because they’re the only one who knows why column H contains that one strange formula.
That file is usually the first sign that an off-the-shelf tool is no longer enough. But the sign alone settles nothing. Frustration isn’t a good enough reason to spend a hundred thousand, and “our competitors have their own system” is an even worse one.
This guide gives you a calculation you can run on your own numbers in about fifteen minutes — plus published cost and timeline ranges, so you know what to expect before you start talking to vendors.
Key takeaways
A custom system pays off when the annual cost of licenses, manual workarounds, and processes your off-the-shelf tool can’t handle starts to exceed the cost of building and maintaining your own solution. It’s a calculation, not a matter of taste.
Published price ranges on the Polish market run from 15–35k PLN for a simple web app to 80–200k PLN for a complex B2B platform (WaspIT, 2026).
Maintenance is a separate, recurring budget line — in published examples, around 15% of the build cost per year.
Project scope is the risk factor you control. Start with the one process that hurts the most, and only then expand.
What custom software actually is
Custom software is a system built for a specific process in a specific company. Unlike an off-the-shelf product bought on a subscription, you don’t adapt to the tool — the tool adapts to you.
There’s no direct data on the custom software market in Poland, but ERP adoption is a reasonable proxy — it shows how many companies have moved beyond spreadsheets at all. According to Statistics Poland (GUS), 40.5% of Polish enterprises used ERP systems in 2025, 4.5 percentage points more than in 2023. Over the same period, the share of companies using CRM fell to 25% (CRN Polska, 2026, in Polish).
For comparison, across the European Union 53% of enterprises used specialized e-business software (ERP, CRM, or BI) in 2025 — 73% each in Denmark and Finland (Eurostat, May 2026). The same data shows that 41% of small EU companies use ERP, compared with 89% of large ones.
The takeaway: if you’re considering a custom system, you’re neither a pioneer nor a latecomer. You’re in the part of the market that’s just moving from spreadsheets to systems — and that’s exactly when the “off-the-shelf or custom” decision matters most. If you recognize the symptom described above, we explore it further in our article on why ready-made applications block business growth.
Three models that are easy to confuse
The difference between them determines cost, flexibility, and who owns the solution.
Off-the-shelf product (SaaS)
A subscription, identical for every customer. Implementation in days, predictable cost, minimal flexibility.
Configured off-the-shelf product
An ERP or CRM adapted with fields, workflows, and integrations. Still someone else’s product, but bent to fit your processes. Implementation costs can be comparable to a small custom project.
Custom system
Built around your process. You decide on the scope and own the code — but you also carry the cost of maintenance and further development.
What it costs to leave everything as it is
A custom system pays off when the annual cost of the status quo exceeds the annual cost of your own solution. Most companies only count the first of these four items:
Licenses — Every subscription for the tools that support the process, including the ones another department pays for. WaspIT points to total SaaS licenses above 2–3k PLN per month as the point where it’s worth calculating an alternative.
Work spent on workarounds — Manually moving data around, exporting to Excel, fixing what got out of sync. Calculate it: number of people × hours per week × 52 weeks × cost per hour of work.
Processes you don’t carry out — The report nobody prepares because it takes two days. The customer you couldn’t serve because the system wouldn’t allow it. The hardest item to quantify, and usually larger than licenses.
Knowledge concentration risk — A spreadsheet only one person understands. A real operational risk, even if it’s hard to put a number on it.
What it costs to own your system
There are four items here too, but they’re distributed differently over time:
Build — A one-off cost, within the ranges described below.
Maintenance — Every year. In an example described by Devstock, a system worth 200k PLN generates about 30k PLN in annual maintenance costs — around 15% of the build cost.
Hosting and infrastructure — From a few hundred zlotys a month for a simple app to significantly more under heavy traffic.
Further development — A system nobody develops becomes yet another problem to solve within two years.
Where the two calculations cross
The mechanics are always the same: the cost of an off-the-shelf solution grows linearly and never ends, while the cost of your own system has a high entry threshold and a gentler slope. Let’s look at an example. This is an illustrative model, not measured data — plug in your own numbers.
Assumptions: licenses of 4k PLN per month (48k PLN per year) and workarounds taking two people 5 hours a week at 115 PLN per hour (about 60k PLN per year). On the other side, a build costing 200k PLN and maintenance of 30k PLN per year — figures close to the example from Devstock (in Polish).
- After one year: the status quo costs 108k PLN, your own system 230k PLN
- After two years: 216k PLN versus 260k PLN
- After three years: 324k PLN versus 290k PLN — your own system is already cheaper
- After five years: 540k PLN versus 350k PLN
In this model the break-even point comes after roughly two and a half years. For you, it could be one year or seven — which is why the calculation matters more than gut feeling. It’s worth spreading the build cost over at least three years of use; over a shorter horizon a custom system rarely wins.
If your own system comes out ahead by only a small margin, wait. With a thin margin, project risk eats up the entire advantage.
Three control questions before you decide
Even a good result means nothing if any of the answers is “no”:
Is the process stable? — If it changes every quarter, you’re building on shifting ground.
Do you have a project owner on your side? — This isn’t about technical skills — it’s about decision-making authority and time.
Can you afford the build and two years of maintenance? — If the budget ends at implementation, the result of the calculation doesn’t matter.
Published cost ranges
Ranges from the price list of one Polish vendor (WaspIT, 2026), net amounts. This is a vendor, not an independent researcher, so treat them as a reference point for the conversation, not the result of market research:
What a quote includes — and what it leaves out
Two figures help you understand the structure of any quote. A team’s hourly rate on the Polish market is roughly 150–180 PLN net per hour (Devstock, 2026, in Polish) — if a quote is given in hours, it lets you check whether the scope estimate is realistic. Maintenance is around 15% of the build cost per year in published examples.
What usually isn’t in the quoted amount but will show up on the invoice: hosting and infrastructure, integrations with external systems that the provider charges for separately, data migration, team training, and changes requested after acceptance. The question “what exactly does this amount include?” matters more than the amount itself.
The pricing model also affects the price: with a fixed price, the vendor has to add a risk buffer, while with time-based billing the risk is visible but sits on your side. We compare both models in detail in fixed price vs. time & materials. You’ll find more about which types of systems fall into each range in our article on custom applications for your company.
Want to check your break-even point?
Describe the process you want to improve. We’ll help you verify the assumptions behind the calculation — even if the conclusion is that you’re better off staying with an off-the-shelf tool.
How long it takes — and why estimates differ so much
Let’s put side by side what Polish vendors publicly state for the same type of project — a “simple app”:
- MadeByRogal (in Polish): 2–3 months
- WaspIT (in Polish): 4–8 weeks
- Just Site: a first working MVP, usually within a month
Even comparing like with like, the spread is two- to threefold: from one month to three for a project described with the same word.
It’s easy to make an even bigger mistake here. We also state that a simple website can be ready in as little as 7 days — and if you compared those 7 days with three months for an app, you’d get a more than tenfold difference. That comparison would make no sense, though: a brochure website and an app with business logic are two different products.
The most common source of misunderstanding when comparing offers isn’t price — it’s undefined terms. First, establish whether you’re talking about the same product. Then, whether the deadline refers to a working MVP or a production version. Only then do the numbers in the offers share a common unit. We break down timelines in detail in how long custom software takes.
Four variables that determine the timeline
Practically all of the difference between offers comes down to the same four factors:
Scope
A “simple app” can mean a single form or a panel with roles, permissions, and reports. Two different worlds under one name.
Integrations
Every external system means someone else’s API documentation, limits, error handling, and tests in an environment you don’t control. One integration can double the timeline of a simple project.
Visual design
A quote that assumes ready-made mockups and one that includes workshops, UX, and a design system can differ by several weeks.
The definition of “done”
An MVP you can show the board comes together quickly. A production version with monitoring, backups, and edge-case handling is a completely different timeline.
What the process looks like, from first conversation to launch
The stages are similar at most vendors. The differences lie in how much of your time each one requires:
Analysis and strategy
A conversation about the process, not the technology. A good vendor tries to reduce the scope at this stage. On your side: a few hours and access to the people who know the process.
Design and UX
Mockups and screen flows before any code is written. The cheapest moment to change your mind. On your side: decisions, not opinions.
Iterative build
Short cycles, each ending with a working version. The more often you see results, the sooner you can change direction before the cost of change grows.
Testing and launch
Data migration, team training, go-live. The stage where things nobody thought of earlier most often come to light.
Maintenance and development
It starts on launch day and lasts as long as the system is in use.
IT project outcomes: a decade without change
Share of projects in each category in 2020–2024, according to an analysis published in PM World Journal (January 2026) based on Standish Group CHAOS data. In 2015–2017, around 29% of projects succeeded:
The biggest risk: too much scope at the start
This data comes with two caveats. First, the methodology of the CHAOS reports is sometimes questioned in the literature, so the figures are best treated as an indication of direction rather than a precise measurement. Second, the definition of success is narrow — a project delivered a month late that brought the company real value lands in the “challenged” category.
More important than the percentages themselves is an observation about scale. The author of the analysis (PM World Journal, January 2026), citing research by Flyvbjerg and Gardner from 2023, points out that while average rates have remained stable, the severity of failure in large projects has increased. Scope creep in IT projects stays invisible until it becomes financially painful.
The conclusion runs counter to many boards’ intuition: don’t start with a “system that does everything.” Start with one process, measure the effect, and only then expand. A smaller scope isn’t a smaller ambition, just a smaller risk surface. That’s how, for example, the Bezuma online store was built — its first working version was ready in three weeks.
The same applies to AI implementations: according to analyses cited in the same paper, most generative AI projects never make it past the pilot stage. The author notes that the main causes of failure have shifted from execution itself to alignment with business goals and data quality — which in practice means the same thing: first a specific process and a measurable effect, then the technology.
What happens after launch
Launch isn’t the last invoice, and budgeting as if it were is the most common financial mistake in these projects.
Maintenance — around 15% of the build cost per year in published examples. It covers dependency updates, patching vulnerabilities, and responding to failures. Without maintenance, a system becomes a security risk within two years.
Hosting and infrastructure — agree at the outset who owns the cloud provider account. The answer “the vendor” can lead to very unpleasant conversations when you part ways.
Code ownership — ask directly and get the answer in writing: after payment, does the code belong to you, or do you receive a license? Do you have access to the repository, and can you hand the project over to another vendor? We cover the clauses worth having in your contract in what a software development contract must include.
Further development — a good system looks different a year after acceptance than on day one, because the company changes. Budget for it, or make a conscious decision to keep the system frozen.
When NOT to commission custom software
There are situations where the honest answer is “buy a ready-made solution” — and it’s better to hear it before signing a contract than after.
Your process is standard
Accounting, HR, invoicing, and basic CRM all have mature, affordable products. Building your own means paying tens of thousands to recreate something that costs a small subscription.
The scale is too small
If a process involves two people and takes them an hour a week, the calculation will never work in your favor. Automation in an off-the-shelf tool will do.
You don’t have a project owner
Without someone who makes decisions and has time for it, the project will get stuck at “we still need to think this through,” and costs will keep growing.
The process hasn’t stabilized yet
Building a system around a way of working that will look different in six months is the most expensive way to learn.
The budget covers the build, but not maintenance
A system with no maintenance budget becomes, within two years, exactly the problem it was supposed to solve.
Summary
- The decision is a calculation. Add up licenses, hours lost on workarounds, and the cost of processes you don’t carry out. On the other side, put the build and maintenance.
- Published ranges exist: from 15–35k PLN for a simple app to 80–200k PLN for a B2B platform, plus maintenance of around 15% of the build cost per year.
- Diverging timelines don’t mean someone is lying — they mean “simple” and “done” haven’t been defined. Ask for the timeline broken down into stages, each with a concrete outcome.
- Scope is your main risk lever. One process, a measured effect, and only then expansion.
- Sometimes the answer is “buy off the shelf” — and that’s a good decision too.
If you’re planning a mobile app, you’ll find a similar cost breakdown in how much does a mobile app cost.
Frequently asked questions
How much does custom software cost?+
When does a custom system pay off better than off-the-shelf SaaS?+
Will I own the code after the project ends?+
How long does it take to build a business system?+
Where do I start if I don’t know exactly what I need?+
Have a project in mind?
We’ll help you design and deliver it — from strategy to a finished solution.
