Part I The decision: does it make sense?
Chapter 2: Buy off the shelf, build custom, or assemble?
You have four paths: off-the-shelf software, a low-code platform, an off-the-shelf core with customizations, and custom development. This applies to a web or mobile app just as much as to an internal information system. Do not build accounting, payroll, or a standard CRM yourself; off-the-shelf is cheaper, and the vendor keeps track of legislation and security for you. Custom software development makes sense where your own process gives you a competitive advantage or where nothing off the shelf exists.
Buy record keeping, build what sets you apart
Gartner divides enterprise systems into layers based on how quickly they change and how much they differentiate the business Gartner, 2012. For the decision, three are enough:
- Record keeping: accounting, payroll, HR, warehouse, records management system. These are common processes for which an off-the-shelf product is usually enough.
- Differentiating processes: your know-how, industry portals, specific procedures. An off-the-shelf core with extensions often works best.
- Innovation: new services nobody else has. This is where you build.
The same type of system can sit in a different layer at two companies. For an office of twenty people, shift scheduling is record keeping: an off-the-shelf app is enough. A delivery company, however, makes its money precisely by planning shifts and routes better than its competitors. For that company, it is a differentiating process, and its own solution may pay off.
Why your own CRM is rarely cheaper
The typical reasoning goes: licenses for five years cost more than a one-off development. But with off-the-shelf software, the vendor takes care of maintenance, legislative changes, and security patches, and spreads those costs across thousands of customers. With your own system, you pay them yourself every year. It is like building your own car because leasing is expensive. So compare the total costs over 5 years, not just the license price against the development price (chapter 4).
And if you do buy off the shelf, adopt most of its processes. Every customization makes upgrades and maintenance more expensive. Before every customization request, ask: is this our advantage, or just a habit?
Low-code: a fast start, an expensive old age
Platforms such as Power Apps, OutSystems, or Mendix let you quickly create internal forms and approval workflows with dozens to a few hundred users. For thousands of external users and a core system meant to last ten or more years, however, they usually do not pay off. The platforms can handle it technically; what decides is the cost and the dependency on the vendor.
You pay continuously, per user, and the vendor sets the price list. Power Apps Premium costs USD 20 per user per month Microsoft, price list 2026; from January 1, 2027, it will be USD 22 for new purchases and renewals Microsoft, 2027 price increase. For 500 users, that comes to CZK 2.5–2.8 million a year for licenses alone (a rough conversion at CZK 21/USD). Mendix publishes only starting prices for its Standard tier; Premium and OutSystems are priced on request.
The application code stays on the vendor’s platform. From January 12, 2027, the EU Data Act bans fees for switching between cloud services Data Act, Art. 29, but it will not move an app built on a platform for you. Leaving means rewriting the app. So secure data export in the contract and have an exit plan.
Low-code also needs rules: a separate environment for testing and for production, an owner for each app, and an overview of how many apps are running in the organization. Without these rules, two years from now you may find that part of your operations depends on dozens of small apps and nobody knows who manages them.
Off-the-shelf core: customizations beside it, not inside
For differentiating processes, it is often best to buy a robust core and build your own features beside it through an interface (API). This only works if customizations stay separate. A heavily rewritten core is hard to upgrade and ties you to a single integrator. This is how the State Agricultural Interventional Fund (SZIF) paid a single SAP platform vendor an average of CZK 514 million a year in 2016–2019, and the Supreme Audit Office (NKÚ) described it as heavily dependent NKÚ, audit conclusion KZ 20/07.
| Path | When it fits | When it does not | Who holds the rights to the code | Main risk |
|---|---|---|---|---|
| Off-the-shelf software (SaaS, boxed) | Record keeping and standard processes: accounting, payroll, HR, CRM, records management system | A process that sets you apart and that the software cannot handle | the vendor | You adapt the organization more than you want to; price list changes |
| Low-code platform | Internal forms and approvals, dozens to hundreds of users, validating an idea | Thousands of external users, a core system for 10+ years | the platform vendor | Platform dependency, rising license costs, untracked apps |
| Off-the-shelf core with customizations | Differentiating processes on a standard foundation, industry portals | When customizations would outgrow the core | core: the vendor; customizations: you (per the contract) | Customizations block upgrades, dependency on the integrator |
| Custom development | Competitive advantage, a unique process, nothing off the shelf exists | Standard record keeping that an off-the-shelf product can handle | you, if the contract ensures it | Underestimated maintenance, vendor dependency without a license and the code |
When custom development makes sense
Custom development pays off if you meet all of the following conditions:
- the process is your competitive advantage or unique to you,
- nothing off the shelf exists, or customizing it would cost more than custom development,
- you need full control over the data, integrations, and changes,
- you have a product owner on your side and a budget for years of operations.
Without the last point, even a well-built system will age. If you do not know what is available off the shelf, do market research before you start development (chapter 8).
Central government purchasing (NKÚ, KZ 17/24)
Alongside a functioning ministry-level centralized procurement system, the government introduced central government purchasing without checking who would use it. Participation was voluntary and the commodities overlapped. In four years, it handled a single contract, for office paper, and it was not cheaper NKÚ, audit conclusion KZ 17/24. The lesson: the first question is not “how do we build it” but “do we need it at all, and does someone already have it?”
Source: NKÚ, audit conclusion KZ 17/24
| How it goes wrong | How to do it right |
|---|---|
| How it goes wrong“Licenses are expensive, we will write our own.” | How to do it rightA 5-year cost comparison including maintenance, legislative changes, and internal time. |
| How it goes wrongOff-the-shelf software is rewritten to copy today’s processes. | How to do it rightAdopting the standard process, with customizations only where you differ. |
| How it goes wrongLow-code is chosen based on the license price for the first year. | How to do it rightLicenses calculated over 5–10 years, including user growth and announced price increases. |
| How it goes wrongA low-code prototype becomes the production system “out of necessity.” | How to do it rightThe prototype is for validation; the production solution is decided separately. |
| How it goes wrongCustomizations made directly in the off-the-shelf core’s code. | How to do it rightExtensions via an API; the core stays upgradable. |
| How it goes wrongCustom development “because we are special,” without proof. | How to do it rightMarket research shows what exists off the shelf and what customizations would cost. |
- Under Section 18(2)(c) of Decree No. 360/2023 Coll., the technical administrator must publish code created during the project, to the extent that it cannot be misused to compromise the system Decree No. 360/2023 Coll..
- For custom development, requiring the source code and a license is standard. For off-the-shelf software, the Regional Court in Brno (2024) and the Supreme Administrative Court (NSS, 2025) rejected a blanket requirement for source code as unrealistic for the market epravo.cz, 2026. With an off-the-shelf product, you protect yourself differently: through data export, an exit plan, and open standards.
- Repeated license purchases for a single low-code platform must be procured under the Public Procurement Act (ZZVZ) and create dependency. For designated information systems, the Office of the Chief Architect of eGovernment (OHA) also reviews the choice (chapter 12).