How to commission custom software. A guide from A to Z.

Overruns are not bad luck but the rule

McKinsey and the University of Oxford collected data on more than 5,400 IT projects. For large projects with an initial budget above USD 15 million, costs were 45% higher on average, delivery took 7% longer, and benefits were 56% lower than the business case promised. Every additional year of duration adds another 15% to the cost overrun. The average also hides extreme cases: 17% of IT projects go so badly that they threaten the very existence of the company. The authors call a budget overrun of more than 200% a “black swan” McKinsey and Oxford, 2012.

For planning, this leads to an unpleasant but useful conclusion: assume your project will not be the exception. What goes up for approval should be an estimate range and a contingency, not a single number. A four-year project is also riskier than four one-year stages, after each of which you decide whether to continue.

Why the first estimate can be off by a factor of four

At the idea phase (“we need a system for…”), the real cost can end up anywhere between a quarter and four times the first estimate. The upper bound is sixteen times the lower one. Once requirements are complete, the range is still 0.67× to 1.5×, and you only get to roughly ±10% after detailed design McConnell, 2006 and 2010. And that applies to experienced estimators. The cone below shows the best achievable accuracy. A real estimate can be even less accurate.

Imagine asking over the phone for a fixed price to renovate a house nobody has seen. You will get either a lowball quote followed by add-ons, or a price with a large buffer. Software is no different. It only makes sense to ask for a fixed price after analysis and a prototype (chapter 10).

Four traps customers set for themselves

Most problems are not caused by developers. In a 2014 PMI survey, 37% of organizations named inaccurate requirements as the main cause of project failure PMI, 2014. For Czech projects, the Supreme Audit Office (NKÚ) writes that the common denominator of failed eGovernment projects is underestimated business analysis NKÚ, 2026. Watch out above all for these four traps:

• A lowball estimate. The budget is fitted to what will get approved instead of being based on an estimate of the work. Test: does the internal estimate match exactly the money you have available? Then it is a wish, not an estimate.
• Absent management and users. IT writes the brief on its own and management only shows up at handover. Test: who from the business side will sign the brief and attend the demos?
• Ignored warnings. An architect or users warn about the deadline or complexity, and the warning disappears from the report. Test: do you know who raised a warning and who answered it?
• Not knowing your own processes and data. The data migration assumes clean data that nobody has seen. Test: are your processes documented, and have you seen a data sample?

The good news: you can prevent all four traps yourself. Start by asking yourself the questions above early.

How to narrow the cone before you sign

• Start with paid discovery: a small engagement that clarifies goals, scope, and risks and sharpens the estimate (chapter 14).
• Have a clickable prototype built and try it out with future users.
• Before issuing an RFP, prepare a sample of the data to be migrated and look at it.
• Ask for the estimate as a range, for example “most likely CZK 6 million, with 80% confidence under CZK 9 million,” and have the contingency approved separately.
• Compare the estimate with similar completed projects. Asking “how did others do?” is more honest than “it will be different for us.”
• Split a large project into stages. After each one, decide: continue, adjust, or stop.

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.

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

What AI really speeds up, and what it does not

Study results vary with the type of task and the developers’ experience. In a lab experiment with a single simple task, developers using GitHub Copilot finished 55.8% faster Peng et al., 2023. In three experiments in real workplaces, 4,867 developers using AI completed 26% more tasks. Less experienced developers saw a bigger benefit Cui et al., 2025.

A 2025 randomized controlled trial by METR, however, showed the opposite for experienced developers working on open-source projects they knew well: with AI they were 19% slower, while they themselves believed they had been 20% faster METR, 2025. The feeling of speed may not match reality.

DORA describes AI as an amplifier: it strengthens both the strengths and the weaknesses of an organization DORA, 2025. Without tests, reviews, and rules, it can also speed up the creation of bugs.

The capabilities of models and AI agents are growing fast. We are writing this section in October 2026, and in a few months it may look different. One thing still holds, though: as soon as an app works with sensitive data or signs users in, an expert should oversee it.

Writing the code is the smaller part

A significant share of the costs over a software system’s whole lifecycle is maintenance: fixes, updates, and changes. A classic reference work puts it at 40–80% of all costs Glass, 2002 (chapter 4). An app built “for free over a weekend” has years of work ahead of it that nobody is talking about yet.

On top of that, a layperson cannot spot a bug in AI-generated code. Even professionals do not trust the output blindly: 46% of developers distrust its accuracy, up from 31% a year earlier Stack Overflow, 2025.

Shadow IT and security holes

Employees build tools without IT knowing. The result is untracked apps containing personal data, with nobody to stand in for the author and with unclear responsibility for GDPR and cybersecurity. The organization bears the responsibility, not the colleague.

In 2025, IBM found that 97% of organizations that had an AI-related security incident lacked proper AI access controls. One in five organizations had an incident caused by an AI tool IT did not know about, and the damage was then up to USD 670,000 higher, roughly CZK 14 million at CZK 21/USD IBM, 2025.

Quickly written apps typically lack access management, reliable sign-in, and event logs. Apps with AI add prompt injection, excessive AI agent permissions, and leaks of sensitive data OWASP, 2025. Even a single shared account with access to a production database can cause a serious problem.

An AI model on your own hardware

A language model does not have to run at a cloud provider. An organization can run an open-weight model (one with published weights) on its own server or in a private cloud. Documents then never leave the organization, and it has full control over the data and the model. This, however, requires powerful hardware and experts EDPB SPE, 2025.

Where it fits:

• anonymizing or pseudonymizing a document before you send it to a commercial AI: the local model replaces names, addresses, or contract numbers with placeholders,
• summarizing and sorting sensitive documents, such as contracts or personnel files,
• search and answers over internal documents.

Advantages:

• the data stays inside the organization, making it easier to comply with GDPR and NDAs,
• you do not depend on the provider’s terms and prices,
• with a large volume of work, costs are more predictable.

Disadvantages:

• even the best open models lag behind top commercial ones by several months Epoch AI, 2026, and your own server will usually run a smaller, weaker model,
• buying a server with graphics cards (GPUs) and running it,
• updates, security, and monitoring are up to you, not the provider,
• anonymization by a model is not fully reliable, so a person checks the result before it is sent.

And one more trap: according to the Municipal Court in Prague, AI output is not a copyrighted work; only a human can be an author Prague Municipal Court, 10 C 13/2023. The court dealt with an image, not code, but purely generated code may not be protected. How to handle this with a vendor is covered in chapter 11.

The best use: a prototype as the brief

A product owner or analyst builds a clickable prototype in a few days, tries it out with colleagues, and hands it to the vendor. The prototype narrows the cone of uncertainty even before the RFP (chapter 1). But it is a brief, not the foundation of the production system. Add a short description: who uses the app, what they do in it, what data it works with, and what the prototype deliberately leaves out. The vendor then does not have to guess, and you get a more accurate proposal (chapter 6).

Do not ban AI across the organization. A ban can lead employees to use it in secret. The AI literacy obligation under the AI Act has applied since February 2, 2025; from July 27, 2026, Regulation (EU) 2026/1744 relaxed it Regulation (EU) 2026/1744. One page of rules is enough:

• approved tools and tools you must not use,
• what does not go into AI: personal data, trade secrets, passwords, and access keys,
• traffic lights: green, do it yourself; amber, report it to IT; red, a proper project,
• where apps are registered and who their owner and deputy are,
• training and contacts for IT and security.

The tip of the iceberg: what the proposal does not show

The contract price is what you see. Below the surface are items missing from the proposal, because you pay for them elsewhere or later:

• migrating and cleaning data from the old system,
• integration with other systems, third-party licenses, cloud, and hosting,
• security testing and user training,
• the time of the product owner and key users,
• parallel running of the old and new systems,
• operations, maintenance, and further development after launch,
• handing the system over to another vendor when the time comes.

After launch, you will spend more than on development

Maintenance consumes 40–80% of all software costs, and roughly 60% of it is enhancements, not bug fixes Glass, 2002. A budget that ends on launch day therefore covers only part of the real spending.

For a first estimate of operations and maintenance, plan 10–20% of the purchase price per year. Czech government systems offer a rough benchmark: the basic registers cost almost CZK 1.8 billion to acquire, and their operation averages CZK 220 million a year, about 12%, or around 17% including further development and renewal NKÚ, audit conclusion KZ 23/05. The new travel document system of the Ministry of Foreign Affairs (MZV) has support at about 8% of its price per year NKÚ, audit conclusion KZ 24/26. The often-quoted range of 15–25% a year comes only from vendor blogs. What matters, though, is the content, not the percentage itself: a support proposal well below 10% that does not describe what it includes is probably leaving something out, such as backups, updates, or restore tests.

Split the money after launch into three envelopes:

1. operations and support: hosting, monitoring, incident handling,
2. maintenance: updates of libraries and platforms, security patches, paying down technical debt,
3. further development: new features and changes driven by the business or legislation.

If you merge them, new features can use up the maintenance money and the system starts to age (chapter 22).

The rate per person-day is not the project price

Software development is priced in person-days: one person-day is one day of work by one person (8 hours). The commercial market has no public price list. Government data can serve as a rough guide: twice a year, the Ministry of the Interior (MV) publishes an overview of the prices public authorities actually pay for IT work.

Medians are around CZK 9,000–14,000 per person-day MV, overview of ICT rates, July 2026. A programmer’s median hourly rate is thus roughly CZK 1,250 excl. VAT (CZK 10,000 per person-day divided by 8 hours). The differences between ministries are huge, though: a programmer cost a median of CZK 5,900 at the Ministry of Agriculture (MZe) and CZK 18,000 at MZV. Often, however, only a handful of contracts are involved MV, ministry benchmarking, July 2026. A lower day rate can mean a more expensive project if more person-days are needed. Compare the total price for the delivery, the breakdown by role, and the seniority of the people.

Enter ranges into the calculator, not a single number: calculate a variant with 10% and with 20% maintenance. Calculate existing software you pay licenses for in the same way: implementation, licenses for all users over 5 years with announced price increases, customizations by a partner, and internal administration. With existing software, you have no rights to the code. With custom development, you can have the code and a license to it, but only with the right contract (chapter 11).

Your people’s time costs money

During development, the product owner needs 50–100% FTE, key users 5–10%, and 30–50% during testing (rough values, details in chapter 16). On an eight-month project, internal costs run into hundreds of thousands of CZK. Include them in the budget and free people from other work. A project that key people only have time for “in the evenings” is like a building site the site manager visits once a month.

Also plan for rising prices. License prices change over a system’s lifecycle (Power Apps Premium goes up from USD 20 to USD 22 from 2027 Microsoft, 2027 price increase), and with custom development, rates go up. A calculation with zero growth is optimistic.

Benefits are overestimated more than costs

The costs of large IT projects overrun the plan by 45% on average, while benefits fall short by 56% McKinsey and Oxford, 2012. The weakest part of a business case can therefore be the very benefits meant to justify the investment. For each benefit, write down who will measure it, how, and when. The calculation should use the total costs over 5 years from chapter 4, not the contract price. Otherwise, your payback period will come out years shorter than it really is.

A goal you cannot measure is not a goal

“Modernize and streamline our processes” sounds good, but you will never find out whether it worked. “Cut application processing time from 12 to 5 days by the end of 2027” is something you can measure. Set 3–5 metrics, and for each one state:

• the baseline value today (measure it before development starts),
• the target value and date,
• who measures it and where the data comes from.

Judge success by the metric values after 6 and 12 months of operation, not just by whether you launched the system on time.

Five types of benefits and how to calculate them

• Time saved: number of people × hours saved per week × number of working weeks × hourly cost. Count only part of the result as a benefit. Not every hour saved turns into other useful work.
• Fewer errors: number of errors per year × cost of one error (correction, complaint, fine) × expected reduction.
• Higher revenue: additional sales × margin, not total sales.
• Lower risk: probability of an event × its impact × how much the system reduces it.
• Legislation: the cost of the cheapest alternative way to meet the obligation. Not the amount of the fine.

Example: 20 people each save 2 hours a week. With a gross salary of CZK 80,000, an hour of work costs the employer about CZK 670 (salary × 1.338 for contributions, divided by 160 hours). Over 46 working weeks, that comes to CZK 1.23 million, and if only half of the time saved can be put to use, roughly CZK 615,000 a year. That is a number you can take to the finance director.

Add the savings from the old solution: licenses, support, and operations that will really go away. Then ask the key question: does the project pay off even if the benefits are halved and the costs are a quarter higher? If so, you have a strong business case.

Always compare with the “do nothing” option

Keeping the current state also costs money. The old system ages, its support gets more expensive, and outages loom. At the Ministry of Foreign Affairs (MZV), for example, the cost of supporting the old system rose from CZK 1.2 million to CZK 15.3 million a year NKÚ, audit conclusion KZ 24/26 (chapter 4). Without putting a number on the do-nothing option, you cannot judge whether the change pays off. So compare three options: keep the current state, buy or customize an off-the-shelf solution, and develop custom software (chapter 2).

A business case is not a one-off document. After discovery and after the first stage, you will know more. Recalculate it at both points. Submit every reduction in scope for approval again, together with its impact on the benefits. Otherwise the project may stay within budget but fail to serve its purpose.

Who is responsible for the benefits

A single sponsor from the business should be responsible for the benefits, also after launch. Do not shift this responsibility to the head of IT or to the vendor. The benefits are estimated and signed off by the process owner on your side.

The decision to continue should not rest only with the person who pushed the project through. A classic experiment showed that the most money is added to a failing choice by people who are personally responsible for the original decision Staw, 1976. So separate the person who runs the project from the person who assesses its status, and agree on stop criteria in advance.

ONE-PAGE BUSINESS CASE
Project: …
Date and version: …

1. PROBLEM
What does not work today, whose work it complicates, and how we know (data, not impressions):
…

2. GOAL AND METRICS (3–5)
Metric | Today | Target | By when | Who measures | Data source
Example: Time to process an application | 12 days | 5 days | 12/2027 | head of department | timestamps in the system
…

3. OPTIONS
A) Do nothing: what it costs us to keep the current state (support, licenses, risks, outages)
B) Buy or customize an off-the-shelf solution
C) Build custom software

4. BENEFITS IN CZK PER YEAR
Time saved: …
Fewer errors: …
Higher revenue: …
Lower risk: …
Legal compliance (cheapest alternative way to comply): …

5. COSTS
Total costs over 5 years (acquisition, operations, maintenance, further development, internal time): …

6. RETURN ON INVESTMENT
Payback period: …
Does it pay off even with half the benefits? yes / no

7. RISKS AND ASSUMPTIONS
What must hold for the benefits to materialize (people learn the system, the process changes, the data is of good quality):
…

8. WHO IS RESPONSIBLE
Sponsor (responsible for benefits, also after launch): …
Product owner (decides on scope): …
Who independently assesses project status: …

9. STOP CRITERIA (agreed in advance)
E.g.: if after discovery the costs come out more than 50% above the approved budget, we go back for approval.
…

10. WHEN WE RECALCULATE
After discovery · after the first stage · 6 and 12 months after launch

FOR PUBLIC AUTHORITIES, ADD
Link to the information strategy · 3E (sound financial management) · cost-benefit analysis (CBA) · source of funding · OHA opinion yes/no

A brief for vendor selection describes the problem, not the solution

In a PMI survey, 37% of organizations named inaccurate requirements as the main cause of project failure PMI, 2014. For government projects, the Supreme Audit Office (NKÚ) describes underestimated business analysis as the common denominator of failures NKÚ, 2026. Time spent on the brief is therefore not a delay. It is the cheapest insurance you have.

For vendor selection, however, you do not need hundreds of pages of documentation. 3–6 pages are enough, answering these questions:

• What problem are we solving, and what does it cost us today?
• Which 2–4 measurable goals will tell us we have succeeded?
• Who will use the system, how many users will it have, and what tasks will they handle in it most often?
• What data do we have, where is it, and what must the system integrate with?
• What constraints do we have (security, accessibility, hosting, legislation), and what are the deadline and the budget range?

Screen designs and the choice of technology do not belong in the brief as a binding solution. List only the technical constraints that follow from your existing environment, such as required integrations with an accounting or warehouse system. If you prescribe a solution instead of describing the problem, you leave less room for better ideas and may get proposals that are hard to compare. A detailed specification with acceptance criteria is only created during analysis with the selected vendor (chapter 14).

Who will make decisions on your side?

The product owner should be your employee, not someone supplied by the vendor Česko.Digital, 2022. They decide on priorities, answer questions, and accept finished parts. The most common thing that holds a project back is a customer with no time for it.

As a rough guide, assume that the product owner needs 50–100% FTE during analysis, and practically full time during development with a team of 5–9 people. On top of that, you need 3–8 key users who devote 20–30% of their time to analysis. Name them before you issue the RFP, and confirm their involvement and reserved time in writing. A product owner who is just a name in a document but does not actively spend time on the project is like a captain who never boarded the ship.

Know your data before the vendor does

Data migration from the old system is the most commonly underestimated part of a project. A vendor who has not seen the data will either price the risk in as a buffer or underestimate it and ask for add-ons later. In the tender for the digital building permit system, seven vendors wrote to the Office for the Protection of Competition (ÚOHS) that the migration could not be reliably priced without further information ÚOHS, S0321/2023 (more in chapter 12).

So attach an anonymized data sample to your RFP, along with a description of the source systems, record counts, and known data quality problems (duplicates, missing data).

A clickable prototype can illustrate a written brief even better. Your analyst or product owner can build one with an AI tool or in low-code in a few days and try it out with colleagues (chapter 3). This narrows the cone of uncertainty (chapter 1) even before the tender. But the prototype is an illustration of the need for the vendor, not a prescribed solution or a production system.

What gets cut when the money runs out?

Give every requirement a MoSCoW priority:

• Must: without it, the system makes no sense,
• Should: important, but you can work around it for a while,
• Could: we add it if time and money are left,
• Won't: not this time.

Must should be a minority. If everything is “necessary,” you will not know what you can postpone when complications arise. The Digital and Information Agency (DIA) evaluation cards divide requirements in a similar way: mandatory ones are a condition, optional ones are scored DIA, Optional requirements card.

Are you ready to approach the market? Before you send out your first RFP, answer yes or no:

• Can we describe the problem in one sentence and put a number on what it costs us?
• Do we have 2–4 measurable goals with a baseline?
• Is there a named product owner with a mandate and time freed up?
• Do we know who the users are, how many there are, and what the key scenarios are?
• Do we know the data sources, volumes, and quality, and do we have an anonymized sample?
• Do we have a list of systems to integrate with and MoSCoW priorities?
• Do we have a budget range including 5 years of operations (chapter 4), and have we verified that an off-the-shelf solution is not enough (chapter 2)?

As a first rule of thumb: if you answer yes to everything, you can start requesting proposals. If two or three answers are missing, fill them in first, or order a discovery phase. With more unanswered questions, start with discovery or an internal prototype.

BRIEF FOR VENDOR SELECTION
Project: …
Product owner: …
Date and version: …

1. PROBLEM
What does not work today and what it costs (time, errors, money). Do not describe a solution.
Example: We retype orders by hand from 3 systems, 2 full-time people, 4% errors.
…

2. GOALS AND METRICS (2–4)
Goal | Today | Target value | By when
Example: Order processing time | 2 days | 4 hours | 6 months after launch
…

3. USERS
Group | Number | Internal / external | Device
Example: sales reps | 40 | internal | desktop and mobile
…

4. KEY SCENARIOS (5–15, one sentence = one scenario)
Example: A sales rep creates a quote from a template and sends it for approval.
…

5. DATA
Sources, volumes, quality, what will be migrated from the old system.
Example: 120,000 customers in the CRM, an estimated 10% duplicates.
Anonymized data sample: attached / provided after signing an NDA
…

6. INTEGRATION WITH OTHER SYSTEMS
System | Method (API, file, other)
Example: ERP (API), accounting (CSV), sign-in via Microsoft 365
…

7. CONSTRAINTS
Security (regulated service under the Cybersecurity Act, GDPR), accessibility, hosting, technology, legislation.
Example: data only in the EU, accessibility per WCAG 2.1 AA.
…

8. PRIORITIES (MoSCoW)
Must (must have, a minority of requirements): …
Should (should have): …
Could (could have, if time and money are left): …
Won't (not this time): …

9. DEADLINE
Fixed dates and why (legislation, season): …

10. BUDGET RANGE
Development from–to, CZK excl. VAT: …
Operations and further development per year: …

11. PEOPLE ON OUR SIDE
Product owner (days per week): …
Key users (who, hours per week): …
IT, security, lawyer: …

12. OWNERSHIP AND INDEPENDENCE
License with the right to modifications by a third party, source code continuously in our repository, documentation, data export, exit plan.

13. OUT OF SCOPE
Example: We are not replacing accounting.
…

ATTACHMENTS
Data sample · prototype · process description · list of systems

First decide who is responsible for the result

You can order a deliverable: the vendor promises a result and is responsible for it. Or you can rent capacity: you pay for person-days and you are responsible for the result. Both options can work, but you must know which one you are buying.

With staff augmentation (a body shop) and with a remote team, you need a product owner on your side and an architect. Management, design, and testing remain your job. If you do not have them, order a deliverable. The contract must match what you are buying (chapter 10). Renting four developers and expecting a finished system is like hiring bricklayers without a site manager and being surprised that the house was not built according to plan.

The size of the vendor should match the size of the project

As a rough guide: a small studio (up to about 20 people) suits web and mobile apps and projects up to a few million CZK. A mid-sized company (about 20–250 people) suits enterprise applications and integrations worth a few million to tens of millions. A large systems integrator has the capacity for extensive and critical systems.

Both extremes have their trap. A small vendor may lack capacity or the back office for 24×7 support. With a large one, you may be a small customer, and you risk the well-known “A-team in the proposal, B-team on the project”: seniors at the presentation, juniors or subcontractors on the project. So ask what share of the vendor’s revenue your project will represent and who exactly will work on it. Key personnel belong in the contract by name, and replacing them should only be possible with your consent.

A senior team with a higher rate often costs less in total than a junior team with a low rate, because it needs fewer person-days and makes fewer mistakes that you then pay for in maintenance. And verify claims about size: a studio that promises “a team of 15 people” but has three in the Commercial Register and on LinkedIn is only now trying to hire your team (vendor due diligence in chapter 9).

You will find median rates for individual roles in chapter 4 MV, overview of ICT rates, July 2026.

Three questions make it easier to choose the right type of vendor:

• Do you have a product owner on your side with dedicated time? If not, rule out staff augmentation and a remote team.
• Do you have your own architect or a technically skilled person? If not, order a turnkey deliverable, not capacity.
• Do you need 24×7 support and high availability? Then neither a freelancer nor a small studio should be your only vendor.

Where the risk hides with small and remote vendors

With a freelancer or a small studio, the project may depend on a single person. Illness or the departure of a key person stops the project. Agree on cover for absences, daily commits of the code to your repository, and documentation written continuously, not “at the end.”

Offshore and nearshore can offer a lower rate, but the total cost does not have to fall. You pay more for management, communication across time zones, and knowledge transfer. Always find out where the data and code physically reside, and for personal data, have a data processing agreement (Article 28 GDPR).

Require subcontractors to be named in the proposal, including their share of the delivery and the country they will work from. If you provide a regulated service under the Cybersecurity Act, you must reflect the security requirements in your contracts with vendors Act No. 264/2025 Coll.. The mandatory elements of a contract with a significant supplier are set by a decree Decree No. 409/2025 Coll.. Use the contract to prohibit subcontracting chains without your consent.

An in-house development team makes sense for a system that is the core of the business and will be developed for years. The most common and sensible combination: the product owner and architect inside the organization, development outsourced. Knowledge of the system then stays with you, even if the vendor leaves.

Ask first, request proposals later

A request for information (RFI) is a non-binding question to the market: how would you solve our problem, is there an off-the-shelf solution, and roughly how much would it cost? You find out whether the schedule is realistic, which off-the-shelf or open-source components can be used, and where the risks are, for example in data migration. Only the request for proposal (RFP) asks for a binding proposal.

Indicative recommendations for companies:

• Send the RFI to 6–10 companies; 1–2 pages and a 60–90 minute meeting are enough.
• Send the RFP only to 3–5 companies that came out of the RFI as relevant. You will not be able to evaluate more proposals properly, and a small chance of success puts good companies off.
• The deadline for proposals for a project worth millions of CZK is 3–4 weeks. A shorter deadline means a risk premium, or a refusal.
• Accept questions until a set date, and send the answer to everyone at once.

Treat vendors’ questions as an early warning, not a nuisance. A vendor who asks nothing has probably not read the brief properly. When several companies ask about the same thing, the brief is not clear enough at that point. Clarify it for everyone before proposals are submitted.

Paid discovery pays off

When the brief is unclear, first order discovery as a separate small engagement. It typically takes 2–8 weeks, and its output is a brief, an estimate, and a prototype. Secure the rights to the outputs in the contract, including the right to pass them on to other vendors. You can then request proposals for the implementation itself based on a more precise brief.

Free analysis looks like a saving, but the vendor expects it to be followed by the implementation contract. It is like having a house designed for free by a company that then wants to build it: the plan fits mainly that company.

Plan for the time, too. The whole vendor selection at a company takes roughly 2.5–6 months:

If you need to start development in September, you must start vendor selection in June at the latest, and ideally in spring to leave a buffer.

What belongs in an RFP

Describe the problem, not the solution. Also state the budget, at least as a range or an order of magnitude. Vendors can then say early on whether they can deliver the project for that money and propose a scope that fits the budget. A good RFP contains:

• the problem, goals with metrics, users, and key scenarios (from the brief in chapter 6),
• data, integrations, and non-functional requirements: security, accessibility, performance, availability,
• the budget range and the deadline,
• requirements for the license and for handing over source code and documentation,
• evaluation criteria with weights (chapter 9),
• a prescribed proposal structure, including an effort breakdown by role and a list of assumptions,
• a draft contract, or at least the key contractual principles.

Deal with the license and code already in the RFP. After you select a vendor, your negotiating position is weaker (chapter 11).

How to compare proposals that cannot be compared

A prescribed structure has a single purpose: to make proposals comparable. Ask for an effort breakdown by role and stage (analysis, design, development, testing, security, management, deployment, data migration) and a list of assumptions and items the proposal does not include. A fixed price without them is a red flag, because every ambiguity then becomes additional work. Chapter 4 explains why the rate alone does not decide. You will find how to score proposals in chapter 9.

Quality should outweigh price

According to the vendor association, the Ministry of Culture (MK) weighted price at 30%, the quality of the solution at 50%, and the technical arrangements for development at 20% in the Kreativní Česko contract Lupa.cz, 2026 (chapter 8). The Best Value method gives price 30% and quality 70%, of which the interview with key team members can account for 20–30% AIR, Best Value. As a rough guide, with a price weight of 80% or more, quality has little effect on the result, and an underpriced proposal wins, which is then made up for with additional work (chapter 10).

A higher weight for quality does not mean a more expensive contract. In one of the cases the association described, the best-rated proposal was also the cheapest Lupa.cz, 2026. Evaluate the total price, including operations and support for 5 years (chapter 4), not just the day rate.

Score against described levels, not by eye

A criterion such as “solution design: 0–40 points” with no further description leaves too much room for subjective evaluation. So for each quality criterion, write down in advance what 0, 1, 3, and 5 points mean. For example, for the solution design: 0 = generic text, 1 = repeats the brief, 3 = a specific design and some risks, 5 = named risks with solutions and realistic stages.

Evaluate quality before you open the prices (two-envelope method). Do not reward the length of the proposal itself. For price, watch out for simple linear price scoring: according to the Digital and Information Agency (DIA), it leads to extreme proposals being selected DIA, ISSS 2025. Ask for an explanation of an abnormally low price.

Before you start scoring, check three things in each proposal. The first is the effort breakdown: does it show analysis, testing, security, and management separately, or just “development”? The second is the assumptions: what the vendor takes for granted, for example that the data is clean or that you will provide interfaces to other systems. The third is the list of what the price does not include: licenses, operations, data migration, or training. Two proposals with the same price can have a completely different scope.

The team, references, and a trial sprint

Evaluate the people who will actually work on the project, not just the sales pitch. Invite the architect and the team lead to an interview or a workshop. If different people sit at the presentation than those named in the proposal, that is your first red flag.

Verify references yourself, not through the vendor. Call the contact person at the customer and ask:

• Did they deliver on time and on budget? If not, by how much, and why?
• Did the same team work on the project as the one being offered to us?
• How did they handle changes and problems?
• Did you receive the source code and documentation?
• Would you choose them again?

Also ask for contacts at two customers who stopped working with the vendor. Logos on a website are not references.

A paid trial sprint will show you the most. As a rough guide, plan for 1–2 weeks of work with 2–3 finalists on a real brief, with criteria known in advance. You will see how the team communicates, asks questions, and delivers. According to the cited article by the vendor association, the town of Žďár nad Sázavou required a demo of the key processes before signing the contract for an information system worth CZK 15 million Lupa.cz, 2026.

Vendor due diligence takes twenty minutes

Public registers reveal the worst risks before you sign. Check the financial statements for at least 3 years.

Since December 17, 2025, the Czech Register of Beneficial Owners has not been accessible to the public BusinessInfo.cz, 2025. So ask the vendor directly for an extract. Treat an ISO certificate as a signal, not a guarantee, and always check its scope: a certificate “for business activities at the company’s registered office” says nothing about development. Small studios often do not have one.

For a project lasting several years, the vendor’s stability is as important as its technical capabilities. For a large contract, attach the due diligence results to the evaluation report so it is clear that someone did it.

The risk of uncertainty does not disappear; it only moves

In the idea phase, an estimate can be 0.25× to 4× the actual figure; you only get to about ±10% after a detailed design McConnell, 2006 and 2010 (chapter 1).

If you want a fixed price for a whole system based on a two-page brief, you will get one of two kinds of proposal. Either it will contain a high risk premium, or it will be underestimated and the vendor will make up the difference later with additional work. Neither is a good deal.

Each model just distributes the risk differently. With a fixed price, the vendor formally carries it, but in reality you pay for it in the premium. With time and materials (T&M), you carry it, but you only pay for work actually done. Combined models share the risk: the vendor is responsible for a stage, and you decide what comes next.

Time works against you: each additional year of duration increases cost overruns by 15% McKinsey and Oxford, 2012. So split the project into smaller stages, roughly up to 3 months each. After each one, decide whether to continue.

Hybrid: a fixed frame, flexible content

For most companies and public authorities, a combined model makes sense: a fixed budget cap, stages that end with a decision on the next steps, and agile development with a backlog within them. Priorities (MoSCoW, chapter 6) decide the content of a stage, and the price stays under control. The Czech adaptation of the 18F handbook recommends “continuous payments for time and costs (with a cap on total spending)” Česko.Digital, 2022.

It works like renovating an apartment with a fixed budget: you know how much you can spend, and after each room you decide whether to continue the same way or differently.

But time and materials without rules is an open budget. Watch four things:

• a cap that the vendor will not exceed without your consent,
• a monthly overview of budget spend in relation to what has been delivered and accepted,
• the right to stop ordering at any time,
• a product owner who has time to decide on priorities.

Where you have a clear Definition of Done, you can pay per accepted increment: the vendor invoices only the parts you have tested and accepted. This works only if acceptance on your side does not stall. Otherwise, you delay payments and damage the collaboration.

What a person-day and a whole team cost

In the first half of 2026, the median rate per person-day in government contracts ranged from CZK 9,220 for a tester to CZK 13,600 for an architect, excluding VAT MV, overview of ICT rates, July 2026. You will find the table by role in chapter 4. Work with quartiles, not the average, and check whether you are comparing prices including or excluding VAT.

According to Česko.Digital, a team of 5–9 people costs roughly CZK 12–20 million a year, and a single contract should not exceed CZK 40 million a year and 3 years Česko.Digital, 2022. An indicative check: 5 people × 20 PD × CZK 10,500 × 12 months = CZK 12.6 million a year.

Pay only for accepted work

Acceptance is the last moment when you have leverage. So agree on payments only after a stage has been accepted, and retention (retainage) until the end of the warranty, roughly 5–10% of the price. Contractual penalties for missed milestones are typically around 0.05–0.2% of the stage price per day, always with a cap (rule of thumb). Chapter 20 describes how to carry out acceptance. Chapter 18 covers changes during a stage.

The author is always a person; you get a license

Only a natural person can be the author of a program, and they cannot transfer their copyright Act No. 121/2000 Coll.. A company or a customer can exercise the economic rights or obtain a license to use the work. So do not write “transfer of ownership” in the contract; write a license and its scope. Anglo-American templates such as “work made for hire” may not work under Czech law.

What is protected is the code, not the idea, the algorithm, or the functionality (Section 65 of the Czech Copyright Act). What matters, then, is what you are allowed to do with the specific code.

The § 58(7) trap: a freelancer yes, a company no

The law says that a program created to order is considered an employee work, and the customer is considered the employer. That sounds as if the customer automatically exercises the rights. But according to the prevailing interpretation in legal literature, this only applies if you conclude the contract directly with the author, that is, with a natural person epravo.cz, 2009. When a company delivers, it exercises the rights, and you need a license or an assignment of the exercise of economic rights.

No case law of the Supreme Court that would settle the question has been found. So do not rely on the interpretation, even with a freelancer, and always agree on a license.

Custom development is usually agreed in a contract for work (smlouva o dílo). On its own, however, it does not give you the right to modifications: without an explicit license, the vendor is deemed to have provided the work for the purpose that follows from the contract § 2634, Civil Code. So you may use the system, but not have another company modify it. This is where most vendor dependency begins (chapter 24).

How broad the license should be

The license should be:

• exclusive, unlimited in territory and time, for all forms of use, even after the contract ends,
• with the right to modify and combine with other works, including through another company,
• with the right to sublicense and assign, for example to another vendor for further development,
• paid for in the contract price, with a statement by the vendor that it has secured the necessary rights from all authors and subcontractors.

An exclusive license usually covers only the parts created for you. For the vendor’s earlier components and third-party parts, you get a non-exclusive license; have a lawyer define the scope of both. Red flag: “the license is governed by our terms and conditions” or “we’ll sort out the license later.” You will find the full list in the checklist at the end of the chapter.

Code, documentation, and data continuously, not at the end

Ask for the code with build scripts and documentation in your repository after every sprint. The test is simple: can another company build, deploy, and change the system from what was delivered? Include documentation in the acceptance conditions. Without it, a delivery is not ready to be invoiced.

Source code escrow suits parts whose code you do not receive directly, typically the vendor’s own components. The code is released upon events defined in the contract, such as insolvency, cessation of business, or long-term non-performance. Deposited code without a license to modify it and without documentation tends to be outdated and unusable.

Ask for free access to the data at any time, in an open and machine-readable format. The Supreme Audit Office (NKÚ) showed the consequences of the opposite approach: a ministry would have had to pay the vendor for its own data from its own system NKÚ, audit conclusion KZ 17/24 (more in chapter 24). The EU Data Act will not protect you with a custom system: its rules on switching providers target cloud services, and some obligations do not apply to services custom-built for a single customer (Article 31).

Agree on the exit plan, acceptance, and penalties at signing

The best time to negotiate a breakup is while you are still in love. The exit plan sets out how the vendor will help hand the system over to a successor, how long parallel running will last, how the data will be migrated, and what the price and deadlines will be. Regulated entities under the Cybersecurity Act are required to have an exit strategy in their contract with a significant supplier Decree No. 409/2025 Coll..

Agree on acceptance in stages, fixed deadlines for both parties, and a classification of defects. Set penalties proportionately and with a cap; a court can reduce a disproportionate penalty (Section 2051 of the Civil Code). Also define your own obligations in the collaboration. If you do not meet them on time, the vendor’s deadline may move too. A one-sided contract does not pay off: the Office for the Protection of Competition (ÚOHS) canceled the tender for the digitalization of building permits partly because of missing acceptance deadlines ÚOHS, S0321/2023(chapter 12).

Code from AI and open-source components

The Municipal Court in Prague stated that an image created by AI is not a copyrighted work, because it is not the result of a person’s creative activity Prague Municipal Court, 10 C 13/2023. The case concerned graphics and the reasoning of a first-instance court. But similar arguments may also apply to code: purely generated code may not be protected, and you have no exclusivity over it. Code that a person creatively modifies can be protected.

So the contract should include rules for AI and an inventory of all components and their licenses (SBOM). Check especially for copyleft (“viral”) licenses, which could oblige you to publish your own code as well.

Ask for the OHA opinion before the tender

When acquiring a designated information system or changing its architecture, a public authority may not carry out the project without a positive opinion from the Digital and Information Agency (DIA), or a government decision. The obligation “is no longer tied to any financial threshold” DIA, OHA approval. A system is designated if it uses the basic registers or provides services to them, is linked to such a system, or serves at least 5,000 users a year with a verified electronic identity Act No. 365/2000 Coll..

Central government bodies must also inform OHA about ICT expenditure over CZK 20 million under Government Resolution No. 86/2020 DIA, OHA approval. The opinion usually arrives within 30 days, or within 60 days for complex requests, and you must complete and submit the request within 90 days of creating it in ISDŘ, the state register for long-term management of public administration information systems DIA, ISSS 2026. The most common mistake: requesting the opinion only after the contract has been announced.

A piece of the state puzzle, not a standalone house

OHA assesses consistency with the Information Strategy of the Czech Republic (Informační koncepce ČR) and the national architecture. In practice, this means your system must fit in among the state’s other systems. It should use shared services, such as the registers and electronic identity, instead of creating its own copies. This is exactly what the Supreme Audit Office (NKÚ) criticized: 2,923 of 5,118 line-of-business systems create local copies of data from the basic registers NKÚ, audit conclusion KZ 23/05. Involve your authority’s architect in the brief from day one.

Plan the budget for the system’s entire lifetime, including operations. This is required by the 3E principle, from January 1, 2027, in Act No. 231/2025 Coll. Act No. 231/2025 Coll.(chapter 5).

The type of procedure depends on the threshold and the clarity of the requirements

The threshold determines how strict a procedure you must use. Depending on how clear the requirements are, you then choose a suitable procedure from those the law allows:

• clear requirements: an open procedure, or for smaller contracts a simplified below-threshold procedure,
• an unclear solution: a competitive procedure with negotiation or a competitive dialogue,
• a large modular system: a framework agreement with several vendors and mini-competitions (chapter 10).

You can award discovery separately as a small contract and use the results in the next tender. But watch out: the Public Procurement Act (ZZVZ) bans splitting a contract (Section 35).

Amounts under the Public Procurement Act and Government Regulation No. 541/2025 Coll. ZZVZ and Government Regulation No. 541/2025 Coll..

JŘBU will not save you if you caused the dependency yourself

A negotiated procedure without prior publication (JŘBU) on the grounds of exclusive rights holds up only if the exclusivity objectively exists and the contracting authority did not cause it itself NSS, 5 Afs 42/2012. In 2025, the Court of Justice of the EU (CJEU) added that the contracting authority is also responsible for the exclusivity if it had “real and financially reasonable means” to end it CJEU, C-578/23. The case concerned ADIS, the Czech tax administration’s information system, for which the Office for the Protection of Competition (ÚOHS) imposed a final fine in May 2026 (chapter 24).

Likewise, extreme urgency that the contracting authority caused itself does not hold up. How do you prevent this? Secure the rights and the code already in the first contract (chapter 11). For a legacy system, document the steps toward ending the dependency and prepare the tender in time.

Tender conditions must withstand objections

Unclear or impossible conditions can lead to objections and subsequently to proceedings before ÚOHS. A vendor can file objections against the tender conditions until the end of the deadline for bids (Section 242 of ZZVZ), and until you decide on them, you may not conclude the contract (Section 246). After the objections are rejected, the vendor has 10 days to file a petition with ÚOHS (Section 251).

The best prevention is thorough preparation: a preliminary market consultation (chapter 8), factual answers to questions sent to all bidders, and quality in the evaluation based on DIA evaluation cards (chapter 9).

Twelve mistakes that keep recurring

This chapter summarizes the first two parts of the guide. For each mistake, you will learn how to recognize it and how to fix it. The details are in the chapter the last column links to.

Not all mistakes cost the same. The ones in the contract are the hardest to fix, because after signing you have a weaker negotiating position. Mistakes in the decision and the budget, on the other hand, stay hidden the longest: the project proceeds according to plan, but the plan itself rests on wrong assumptions. It is like following a navigation system with the wrong destination entered. You drive smoothly and on schedule, and you only find out at the end of the trip that you are somewhere other than where you wanted to be.

Which mistake should you fix first?

If you checked several items in the self-test, do not simply go through them in order. Start with the ones that are hardest to fix after the contract is signed:

• The contract (mistakes 10–12). Secure the license, code handover, access to data, and the exit plan before signing. After that, your position is weaker and every change costs money.
• The product owner (mistake 2). Without a person who makes decisions, even a project with an excellent vendor grinds to a halt.
• The pricing model and the data (mistakes 4 and 6). Both determine whether the proposals can be compared at all.

Selection mistakes (7–9) can still be mitigated along the way, for example with a paid trial sprint or by replacing key personnel. And if it turned out that you are building a standard business function (mistake 1), stop completely: the cheapest project is the one you do not have to do.

Ministries make the same mistakes

Companies do not publish their failed projects, but for the state, audit results are available. Audit conclusions of the Supreme Audit Office (NKÚ) and decisions of the Office for the Protection of Competition (ÚOHS) are therefore the best public textbook: even an institution with a legal department and a budget of hundreds of millions can make the mistakes in the table. The table draws mainly on audit conclusions and decisions. Two good examples rely on secondary sources (an article by the vendor association and a legal analysis). The chapters in the last column discuss the cases in detail.

First the problem and the users, then the features

The brief for vendor selection (chapter 6) describes what you need and why. Analysis with the selected vendor turns it into a specification: who will use the system, in what situations, and how you will tell that it works. The UK and Australian governments call this discovery, and the New South Wales government usually sets aside 4–8 weeks for it NSW Government, 2026. For a smaller, clearer system, a shorter discovery is enough, which is why chapter 8 gives a range of 2–8 weeks. The result can even be a decision that developing a new system makes no sense.

The most common mistake is to turn a paper form into a screen 1:1. The Supreme Audit Office (NKÚ) criticizes the state for “digitalization at the level of forms”: after investments of more than CZK 50 billion in 2020–2024, only 18% of services were fully digital NKÚ, 2026. Simplify the process first, then digitalize it.

Talk to the people who will use the system every day, not just to management. In the digital building permit system project, according to the technical audit, the requirements were drawn up without involving the key future users DSŘ audit, technical part, 2025 (chapter 20 describes how the launch went).

The cheapest test is a clickable prototype. For a first check, try it out with 5–8 people who do the day-to-day work. That way you can find most process errors before the first line of code is written. Rewriting a screen in a prototype takes hours; in a finished system, it takes weeks.

Every requirement must be verifiable

According to a PMI survey from 2014, 47% of unsuccessful projects failed to meet their goals because of poor requirements management PMI, 2014. This is a share of projects, not of organizations as with the 37% in chapter 6. The basic unit of a specification is therefore the user story: As a [role], I want [what] so that [why]. It comes with acceptance criteria in the form Given / When / Then. The vendor prepares tests based on them. At acceptance, instead of arguing about impressions, you then verify whether the system meets the criteria. Do not let a user story without criteria into development.

The numbers in the examples are illustrative; set your own values based on the number of users and the impact of an outage. ASVS is a catalog of verifiable security requirements OWASP ASVS 5.0, 2025; the deadlines for reporting incidents are set by the Cybersecurity Act Act No. 264/2025 Coll.. Chapter 15 discusses both.

USER STORY
Title: [short title]
As a [user role]
I want [what I need to do]
so that [what benefit it brings].

ACCEPTANCE CRITERIA (at least 2)
1. Given [initial state], when [action], then [expected result].
2. Given …, when …, then …

Example:
As a case officer, I want to see a list of new applications sorted by submission date
so that I can process them within the statutory deadline.
1. Given: 3 new applications from different days. When: I open the overview.
   Then: I see them from the oldest, each with the number of days left until the deadline.
2. Given: an application past the deadline. When: I open the overview. Then: it is marked "Overdue" in red.

Link to non-functional requirements: [performance, security, accessibility…]
Priority (MoSCoW): Must / Should / Could / Won't
Out of scope for this story: […]
Approved by: [product owner], date, version

READY FOR DEVELOPMENT WHEN IT
[ ] has a role and a benefit
[ ] has at least 2 Given / When / Then acceptance criteria
[ ] states its link to non-functional requirements
[ ] has a priority
[ ] has been approved by the product owner

“Fast and secure” gets translated into numbers

Non-functional requirements say how well the system must work. You will find it hard to verify and enforce general words such as “fast” or “reliable.” Specific values and standards make it possible. The specification should cover at least these areas:

An MVP is the smallest useful version, not half of everything

An MVP is the smallest version that real users will actually use. Only requirements with Must priority belong in the MVP (chapter 6). Plan the stages according to when they will deliver value: a pilot at one site, an expansion, full deployment. Short stages are the best insurance against cost overruns, because overruns grow with every year a project lasts (chapter 10).

It is just as important to write down what will not be delivered. The out-of-scope list is a separate part of the specification and is signed together with it. For example:

• migration of data older than 2015,
• integration with the attendance system,
• a mobile app (a website that also works on a phone is enough),
• an English version.

A specification works like an order at a building supply store: what is not on it will not be delivered, and what you add at the checkout you pay for separately. Anything left unclear will later turn into a dispute over additional work (chapter 18).

Who approves the specification?

Your product owner is responsible for the specification. The vendor helps them formulate and verify it. Each party approves its own part:

• user stories, priorities, and the MVP: the product owner,
• security, operations, and architecture: IT, the architect, and the cybersecurity manager,
• personal data: the data protection officer,
• changes to goals, budget, or deadline: the steering committee.

Document the approval with a version number or minutes.

Five things you must watch

1. Transferability. The code, the build procedure, the documentation, and the rights to make modifications are with you on an ongoing basis, not “when the cooperation ends” (chapter 11).
2. Widely used technology with a support period. A common language and framework, with an end-of-life date for every key component.
3. A simple modular architecture. Modules with documented interfaces (APIs) and open data formats.
4. Hosting with a way out. Accounts, domains, and the cloud in your name, and an exit plan with a cost estimate.
5. Measurable security and accessibility. Specific standards, an independent test, and for AI, a classification under the AI Act.

Transferability is mainly a matter for the contract; the rest of the chapter covers points 2–5.

Boring technology is an advantage

In proposals, you will most often see these widely used technologies: the languages Java (with Spring Boot), C# (.NET), Python, PHP, and JavaScript or TypeScript with the React or Next.js frameworks, the PostgreSQL database, Docker and Kubernetes containers, and the Azure, AWS, or Google Cloud public clouds. Do not take this as a recommendation, only as a point of reference. Wide use is an advantage: you will find developers more easily, the technologies have long support, and hundreds of companies can take over a system built on them. An exotic technology that only one person at the vendor knows will tie you to that vendor. There is no data on the number of developers by language in the Czech Republic, so ask the vendor which other Czech companies use the technology.

For every component, ask for the version and the end-of-life date. After that date, the maker stops releasing fixes, and an expensive migration awaits you (chapter 23).

Architecture: a house with rooms, not a housing development

Microservices are fashionable, but for a typical business system with one team they are more of a burden. They shift part of the complexity from development to operations and make a takeover by another vendor more expensive. From 2015 to 2018, the consultancy Thoughtworks placed “microservice envy” in the Hold category, meaning do not use Thoughtworks, 2018, and it recommends starting with a well-structured monolith Thoughtworks, 2023.

Ask for an architecture document describing the modules, interfaces documented in the OpenAPI standard, and short records of technical decisions (ADRs). With these, a new vendor can find their way around in weeks, not months.

For a mobile app, first ask whether you need one at all:

The App Store and Google Play accounts and the app signing keys should be in your name.

Hosting: the way out matters, not the cloud brand

There is no independent comparison of cloud and on-premises server costs in CZK. As a rough guide, the cloud pays off with fluctuating load and a small IT team, while running your own servers pays off with stable load and an existing team. The way out matters more than the choice: applications in containers, a standard database, proprietary cloud services only after considering the consequences, accounts and domains in your name, and an exit plan with a price.

Security and accessibility by the standards

Security can be specified as precisely as the dimensions of a kitchen unit. The OWASP ASVS 5.0 standard has 345 verifiable requirements at three levels OWASP ASVS 5.0, 2025. For a typical business system, level 2 is usually required. Have compliance with it verified independently; a penetration test alone will not prove it. But also require a penetration test as a condition of acceptance, together with a list of all components (SBOM) for every release. Software supply chain failures, such as a vulnerability in a third-party library, rank 3rd in the OWASP Top 10:2025 OWASP Top 10:2025.

The Cybersecurity Act (Act No. 264/2025 Coll.) has applied since November 1, 2025. Regulated entities must carry the security requirements over into their contracts with vendors. The system must log events so that you can meet the statutory deadlines for reporting incidents: an initial report within 24 h, a notification within 72 h, and a final report within 30 days Act No. 264/2025 Coll.. Check with your cybersecurity manager which incidents you report and under which regime. By February 2026, 4,825 organizations had reported providing a regulated service NÚKIB, 2026. Check whether the obligations also apply to your organization.

The EU Cyber Resilience Act (CRA) does not explicitly exclude custom software. Whether it applies to your project depends, among other things, on whether the software is “made available on the market” Regulation (EU) 2024/2847. Leave the conclusion for a specific project to a lawyer (chapter 11).

Accessibility has three layers:

• Public authorities are required to provide it under Act No. 99/2019 Coll. Act No. 99/2019 Coll.. The legal reference today is the EN 301 549 V3.2.1 standard, that is, WCAG 2.1 AA DIA, accessibility guideline.
• Companies have had to meet it since June 28, 2025, for listed consumer services such as online stores, banking, or transport (Act No. 424/2023 Coll.) Act No. 424/2023 Coll..
• The new standard EN 301 549 V4.1.1 adopts WCAG 2.2 and was published on September 2, 2026. It is still awaiting publication in the Official Journal of the EU EN 301 549 V4.1.1, 2026.

So write WCAG 2.2 AA into the brief W3C, WCAG 2.2; that way you meet both the current and the expected state. A plugin that promises “100% accessibility” with a single script is not enough. The condition for acceptance should be an audit that includes manual testing with a screen reader.

AI in the application: classification and replaceability

If the system is to include artificial intelligence, decide three things in the brief:

• where exactly the AI is and which risk category it falls into under the AI Act,
• how you will replace the model provider (your own abstraction layer and a test suite for comparison),
• that the provider must not train on your data.

As of October 2026, following the amendment by Regulation 2026/1744, the transparency obligations have applied to new systems since August 2, 2026. They include, for example, informing people that they are talking to a machine. AI that makes decisions about people in recruitment, assessment, or access to services and loans is high-risk, and its obligations apply from December 2, 2027 Regulation (EU) 2026/1744. The deadlines have already shifted once, so check them before you sign the contract.

The difference is when you hear the bad news

With the waterfall approach, the whole system is first described, then developed, and finally handed over. You are most involved at the beginning and at the end, and a problem often only shows up at acceptance. The UK government’s guidance warns that this way you can spend 18 months building a service that no longer matches policy, technology, or user needs GDS, agile development.

With agile development, you see a piece of working software after every short cycle, roughly every 1–4 weeks. You uncover risks early, but you have to make decisions and try out the software on an ongoing basis.

Watch out for an agile label on a waterfall

The most common trap is “agile development” with a fixed two-hundred-page brief and a fixed price. Or an agile contract without a product owner on the customer’s side. The Czech adaptation of the guide by 18F, the US federal government’s digital team, says that when a vendor claims an agile approach but handles every change with an additional order, “a red light should go on in your head” Česko.Digital, 2022.

Agile development can be reconciled with a fixed contractual framework in four ways:

1. fixed budget and deadline, variable scope,
2. payment for time worked, with a cap,
3. a fixed price for the MVP, further stages as options,
4. payment per accepted increment that meets the Definition of Done.

Chapter 10 discusses which approach suits your project and how to set the price.

How much of your time it will take

The product owner should be your employee, not someone from the vendor Česko.Digital, 2022. They decide on priorities, answer questions, and accept finished parts. They are like a homeowner who visits the building site every day: when they are missing, the builders either wait or build as they see fit. Decision-making by committee and a product owner working “10% alongside their regular job” are typical brakes. A fixed price does not replace your own management: in the digital building permit system project, the contract had a fixed price and deadline, and yet, according to the legal part of the audit, the projects did not have some of the roles required by the ministry’s methodology filled DSŘ audit, legal part, 2025 (more in chapter 20).

Appoint the product owner before you sign the contract, confirm in writing how much of their time you will free up from other work for the project, and give them a mandate: what they decide on their own and what they must submit to the steering committee. Choose key users from the people who actually do the work, not from those who happen to have time.

The hours given are rough estimates based on a 40-hour week, not measurement results. For key users, they are per person, so the total load is several times higher.

Cooperation is an obligation, not goodwill. Write the roles, hours, and deadlines for your answers into the contract, and ask the vendor to keep a record of what it is waiting for from you. Also watch the stability of priorities: when they change every week, team productivity drops and the risk of burnout rises DORA, 2024.

From day one, you need access to the backlog, the code repository, and the test environment. Only then can you see the real state of things (chapter 17).

What the team needs from you in every sprint

An agile project is more a series of small decisions than one big one. In every sprint, you are expected to provide:

• an ordered backlog: what comes next and why,
• quick answers to questions, so the team does not have to wait,
• participation of the product owner and key users in the demo,
• acceptance of finished work, or a clear “not like this” with a reason,
• data, access, and people from other departments when the team needs them.

Larger projects are also divided into phases. The UK government calls them discovery, alpha, beta, and live: exploring the problem, testing the solution on prototypes, development for a limited and later a wider group of users, and finally production GDS, agile development. At the end of each phase, there is a decision on whether to continue. These are exactly the gates of the hybrid model.

Agree on the meeting rhythm at signing

The meeting calendar belongs in the contract or in the project plan you sign. An indicative plan for two-week sprints:

Holding meetings is not enough on its own. The participants must work with data and make decisions. In the digital building permit system project, the steering committees met, but according to the audit, nobody responded effectively to the warnings from independent technical oversight, and regular status reporting was missing DSŘ audit, technical part, 2025 (more in chapter 20).

A demo means running software, not a presentation

The demo runs in your test environment, not on a developer’s laptop or in PowerPoint. The product owner, key users, and IT attend it, not just the project managers. A canceled or “local” demo is a red flag.

Prepare your own review plan. The 18F guide recommends checking quality indicators at every demo, usually every two weeks, as part of accepting the work 18F, 2024. One page is enough:

What to ask to see every sprint:

• running software in your test environment,
• which user stories are done according to the Definition of Done and which are not,
• results of automated tests and the security scan,
• open defects by severity and how they are developing,
• an updated backlog with estimates,
• what input or decisions the vendor needs from you.

What to ask to see every month at the steering committee:

• what percentage of the budget has been spent and what percentage of the MVP has been accepted,
• an estimated MVP completion date based on the team’s actual velocity, not just the original plan,
• the risk register and the status of the measures to address the risks,
• change requests: approved, rejected, pending, and their impact on the price.

Access from day one, written into the contract

Without access, you only check what the vendor chooses to show you. Ask for:

• the code repository, ideally administered by your organization,
• the task tool with the backlog,
• continuous integration and the results of tests and scans,
• the test and staging environments,
• documentation and records of technical decisions,
• cloud accounts in your name.

The Czech adaptation of 18F puts it directly: all outputs, from software to graphic designs, belong to the contracting authority and are handed over at the end of every sprint Česko.Digital, 2022. The answer “you don’t have access to the code for security reasons” means that you have no control.

A few numbers every manager understands

• Value: how many user stories you have accepted compared with the plan. A chart where the line of finished work rises toward the scope line is called a burn-up chart.
• Money: X% of the budget spent against Y% of the MVP accepted. If the share of the budget spent exceeds the share of scope accepted by 15–20 percentage points, it is time to intervene. This is an indicative threshold.
• Quality: open defects by severity and their trend.
• Forecast: the MVP date calculated from the team’s actual velocity.

The technical team can also track the five DORA metrics: how often the team deploys, how long it takes for a change to reach production, how often deployments fail, how quickly the team restores service, and what share of deployments are unplanned fixes DORA, metrics. You do not need to understand them in detail; it is enough to ask to see them and watch whether they improve.

The “90% done” syndrome

When a vendor reports 90% for several months in a row, it is a red flag, not evidence of progress. The last 10% usually contains integrations, data migration, performance, and security, which is the hardest part. It is like a painter who has finished all the walls, and only the ceiling, the windows, and the cleanup are missing. So measure accepted scope, not percentages estimated by the vendor. An indicative threshold for escalation: 4–6 weeks without a new result that could be deployed (chapter 19).

Scope grows, even when nobody wants it to

Scope creep usually has ordinary causes:

• an unfinished analysis and unclear scope boundaries,
• several people with different requirements on the customer’s side and no product owner,
• a change in legislation during the project,
• shifting management priorities. DORA research has shown that unstable priorities reduce team productivity and increase the risk of burnout DORA, 2024.

Changes in themselves are not a mistake. Something new always comes up during development. The mistake is uncontrolled changes: agreed in the hallway, not priced, and not written down anywhere. Each one on its own is a trifle; together they add up to a stage that nobody ordered. You can prevent most of the causes with an analysis that includes a list of what is out of scope (chapter 14) and with a single product owner (chapter 16).

Change control: five steps instead of “just add that in too”

Change control sounds bureaucratic, but it is just a procedure agreed in advance. It applies to companies and public authorities alike, and it fits on one page of the contract.

Follow two more rules. First, a defect fix is not a change: the vendor fixes a defect free of charge under warranty, but charges for a change, and the contract must clearly separate the two (chapter 11). Second, additional work without a signed change order is not paid for. Agree on this in the contract; then approval by email or “verbally at the demo” is not enough.

The process pays off with every pricing model (chapter 10). With a fixed price, it protects the budget from additional work. With payment for time worked, a change is not invoiced separately, but it draws on the agreed budget cap and pushes back the deadline, so the same person should decide on it with the same information. Be alert when:

• there are many change orders and each one is small,
• additional work is approved by email or phone,
• nobody can say how much of the contingency is left.

CHANGE REQUEST No.: CR-___        Date: ____
Requested by (name, department): ____
Description of the change (what the system should do differently): ____
Reason (why, what happens if we don't do it): ____
Type: [ ] new feature  [ ] feature modification  [ ] change in legislation  [ ] defect fix (not a change!)
Priority (MoSCoW): ____

--- completed by the vendor (within 5 business days) ---
Effort estimate (PD) and price (CZK excl. VAT): ____
Impact on the schedule (stage, milestone): ____
Impact on other features and risks: ____
Proposal for what to remove from the backlog or postpone: ____

--- decision ---
[ ] approved  [ ] rejected  [ ] postponed to the backlog
Decided by (product owner / steering committee), signature, date: ____
Contingency used after this change (CZK and %): ____

--- public authorities only ---
Classification under Section 222(__) of ZZVZ, justification: ____
Publication (Register of Contracts / buyer profile), date: ____

Something in, something out

With a fixed budget, the main tool is trading requirements. For every change request, ask what will drop out of the backlog so that the new item fits. It works like a suitcase for a flight: if you pack extra shoes, something else stays at home.

How do you say no? The product owner needs a mandate and a criterion for making decisions: the project goal and the scope of the MVP. They do not reject what does not belong in the MVP forever, but postpone it to the backlog for the next stage. Be alert when the vendor itself pushes to expand the scope before the MVP is finished. More work for the vendor does not necessarily mean more value for you.

A contingency is necessary; short stages are stronger

A contingency is not an admission of incompetence, but insurance. As a rough guide, plan for these values:

• a well-prepared project: 10–15% of the budget and 15–20% of the time,
• a new system with unclear integrations with other systems: 20–30% of the budget.

The customer holds the contingency, not the vendor, and decides on every use of it the same way as on a change. For a multi-year project, even a large contingency may not be enough. Large IT projects exceed their budget by 45% on average, and each additional year of duration increases the cost overrun by 15% McKinsey and Oxford, 2012. Short stages, after which you can adjust the plan or end the project, are therefore stronger insurance. A public authority must also think about the contractual possibility of using the contingency: it must reserve it as an option or a change in the tender documentation.

You can read the red flags without knowing the code

The signals fall into four areas: time, budget, quality, and team. A single amber signal does not yet mean a crisis, but it is a reason to ask the vendor a question. A red one calls for action. Four signals tend to have the most expensive consequences: the vendor refuses access to the code or an audit, you keep hearing “90% done,” you see nothing new to deploy for 4–6 weeks, and the share of the budget spent exceeds the share of scope accepted by more than 15–20 percentage points (an indicative threshold).

Why not wait? Cost overruns grow with every year a project lasts (chapter 18). So respond to a red signal within 2 weeks (rule of thumb), not “when we see how it goes.” It is like the oil warning light in a car: you can keep driving, but the repair gets more expensive with every kilometer.

The escalation ladder: from braking to switching vendors

Respond to a problem according to how serious it is. Each further level of intervention costs more, so start with the first one unless the situation calls for a more drastic step.

Re-planning does not just mean a new deadline. It is a new plan built on the team’s actual velocity, with a smaller scope, checkpoints, and the signatures of both parties. If the team misses the next checkpoint too, do not move the plan again. Move on to the next level of intervention.

An independent audit is cheap insurance against an expensive decision made blind. Commission it from someone with no ties to the vendor and present the result to the steering committee with a clear choice: continue with a smaller scope, or stop. In the digitalization of building permits, the government decided in October 2024 not to develop the existing systems any further and to prepare a new tender Government, October 16, 2024. The forensic audit came only afterward, the legal part in April 2025 DSŘ audit, legal part, 2025 and the technical part in August 2025 DSŘ audit, technical part, 2025, and it served to establish accountability. The better order is the reverse: first the audit, then the decision. Chapter 20 describes how the launch itself turned out.

When to stop a project

Stopping a project is a legitimate decision, not a failure. In January 2025, Miloslav Kala, President of the Supreme Audit Office (NKÚ), said on television about the digitalization of building permits: “Knowing how it ended, it would probably have been better to stop it. But at the moment the decision was being made, it wasn’t that simple.” Aktuálně.cz (ČTK), 2025

The second sentence is the important one. Decisions are hard to make in a crisis: every day has already cost something, the deadline is pressing, and nobody wants to admit the money is lost. So agree on stop criteria in advance, at the start of the project, and write them into the plan or the contract. In a crisis, you then check whether any of them has been met.

STOP CRITERIA FOR THE PROJECT (agreed at the start)
Project: ____        Approved by (sponsor, steering committee), date: ____

We will stop the project, or fundamentally re-plan it, if at least one of the following occurs:
1. ___ weeks without a deployable increment (default suggestion: 6).
2. Budget spending is more than ___ percentage points ahead of the accepted scope (default suggestion: 20).
3. The estimated cost to completion exceeds ___% of the approved budget (fill in yourself).
4. The vendor refuses an independent audit or access to the code.
5. The business case no longer holds (goal, benefit, legislation, management priority).

Who evaluates the criteria and how often: ____
Who decides on stopping: ____
What happens on stopping (handover of code, documentation, access; payments): ____

The default values are indicative. Adjust them to the size of the project.

Switching vendors in the middle of a project

Without the code in your repository, documentation, access, and a license for modifications, a new vendor has to start from scratch, or cannot take over the work at all. So the contract should include stages with the option not to order the next one, an exit plan, and a mandatory duty to cooperate during the handover (chapter 11). Chapter 24 describes the system handover in detail.

Do not forget penalties either. A contractual penalty that you never enforce stops working: the vendor starts treating it as a formality. Enforce it, or justify in writing why not. An excessive penalty does not help either: a court can reduce a disproportionately high contractual penalty (Section 2051 of the Civil Code), so agree on a reasonable one with a cap. Also keep a record of your own delays in cooperation, because they push back the vendor’s deadline.

There are many kinds of tests, and you personally do only one

Each kind of test checks something different. Most are carried out by the vendor or a specialist. Ask for their results. But you do the user acceptance testing yourself: with key users, on real scenarios and anonymized real data. Made-up data will not reveal all the problems of real operation.

Commission the penetration test from a third party, not the software vendor. Nobody should test locks they installed themselves. Fixed findings from the test belong among the conditions of acceptance.

Acceptance has three possible outcomes

The vendor hands over a stage with a report on its own tests. You test within the agreed time limit. As a rough guide, plan for 10–15 business days for a stage and 3–5 days for a sprint. You record every defect you find and assign it to a category. The outcome is one of three:

• accepted,
• accepted with reservations: only minor defects remain, or a limited number of serious ones with a fix date,
• not accepted: the vendor fixes the defects and acceptance is repeated.

Signing the acceptance has major consequences. The vendor can invoice, the warranty starts to run (as a rule of thumb, 12–24 months), and from that moment defects are handled as warranty claims, not as unfinished work. So keep part of the price, roughly 5–10%, as retention (retainage) until the end of the warranty or hypercare.

Put the defect categories and their limits in the contract in advance. Otherwise, you will be arguing about whether a defect is “critical” at the moment when the vendor is pushing for a signature and you are pushing for the deadline.

Launch based on readiness, not on a date

Go/no-go is a decision shortly before launch: is the system ready? Approve the launch only when all of the following conditions are met:

• no open A defects, and B defects below the agreed limit,
• a successful trial data migration,
• a passed performance test,
• a penetration test with no critical findings,
• trained users,
• a prepared and tested rollback,
• approved security and, for a public authority, statutory obligations met.

Record the decision, including who made it. Launch gradually: first a pilot with one department or branch, then expansion. The UK Government Digital Service (GDS) first releases new services to a limited group of users, then to everyone in beta, and makes them live only after an assessment GDS, beta phase. A gradual launch limits risks that would otherwise affect all users at once.

Migrating data from the old system is a separate part of the delivery with its own acceptance: a trial migration on a copy of the production data, reconciled counts and checksums, and a tested rollback (see the checklist).

After launch: people and a period of increased support

A system is finished only when people know how to work in it. Run role-based training shortly before launch, not three months in advance, when people will forget much of it by launch day. Super users, a training environment, and short how-to guides help in the workplace. Expect a temporary drop in productivity, and make sure the old procedure really ends. In 2026, the Supreme Audit Office (NKÚ) pointed out that digitalizing forms has not yet sped up the work of public authority staff, because the internal processes remained manual NKÚ, 2026.

For the first 4–12 weeks after launch (rule of thumb), you need hypercare: a reinforced vendor team, shorter response times, and a short daily meeting on problems. The end of hypercare is determined by criteria set in advance, such as 2 weeks without an A defect, not by a date. Hypercare belongs in the development contract; regular operations then belong in the support contract (chapter 21).

A response is not a resolution

The most common trick is an SLA that covers only response time. The vendor “responds” within 15 minutes, confirms that it has received the ticket, but takes a week to deal with the bug itself. And it has not breached the contract. So for each priority, ask for three separate time limits:

• response: the vendor confirms the ticket and starts working on it,
• restoration: the system works again, possibly with a temporary workaround,
• resolution: the bug is fixed permanently.

The vendor does not set the priority according to its current workload. Impact and urgency decide, based on the definitions in an annex to the contract. Any dispute is resolved by an escalation procedure agreed in advance. Also distinguish between an incident, where operation needs to be restored, a problem, where you look for the cause of repeated incidents, and a change request. Each is handled differently. New features do not belong in the fixed monthly fee for support; they go through change control and the budget for further development (chapter 22).

Time limits run only within support hours

8×5 support covers 40 hours a week; round-the-clock 24×7 support covers all 168 hours, which is 4.2× more time. If you report an incident on Friday at 4 p.m., a 4-hour time limit under 8×5 support with business hours of 9 a.m.–5 p.m. ends at noon on Monday. The weekend does not count.

A common compromise is 24×7 only for P1 and 8×5 for everything else. Base the support hours on when people actually use the system, and include the option of tightening them later in the contract. Needs change: the basic registers were created for the office hours of public authorities, but the digitalization of services for citizens requires round-the-clock operation, and even more than 4 years after the deadline at the end of 2019, it had still not been ensured NKÚ, audit conclusion KZ 23/05 (chapter 23).

Convert availability percentages into hours

99% sounds great, but it allows up to 87.6 hours of outage a year. At 99.9%, it is about 8 hours and 46 minutes. Try it yourself:

The same percentage can mean a completely different promise. Ask:

• What is an outage? Only a complete failure, or also a response time longer than a few seconds?
• When is it measured? If availability is counted only within 8×5 support hours, a nighttime outage of any length does not breach the contract.
• How often? Monthly evaluation places stricter demands on the vendor than annual evaluation. That way, one long outage does not get “diluted” in the annual average.
• What is excluded from the measurement? Planned downtime, outages of subcontractors or the network.
• Who measures it? Ask for the methodology in the contract and access to the monitoring data.

Watch out for chaining, too. In the basic registers, the individual parts contractually have 99.9% or more, but taken together, the guarantee comes to only 99.68%, which means up to 28 hours a year that the contracts do not cover NKÚ, audit conclusion KZ 23/05. And availability that nobody measures is just a wish: the Ministry of Finance (MF) set it as a parameter of two projects and then was unable to evaluate it NKÚ, audit conclusion KZ 15/31.

Penalties that hurt, and a report you read

Token penalties and a missing report are among the most common mistakes. An SLA without them is like a car warranty that nobody enforces. The contract should include:

• contractual penalties or discounts on the fixed monthly fee, graduated by priority and repetition, with the right to terminate the contract for repeated breaches,
• a monthly report: incidents by priority, compliance with time limits, availability, open problems, hours used, plus a regular meeting,
• the report as a condition for invoicing the fixed monthly fee,
• the customer confirms the closing of an incident, and repeated P1 incidents lead to a root cause analysis.

Whether the servers are run by the vendor, by you, or in the public cloud, admin access, monitoring, and logs should be available to you. Without your own access and data, you remain dependent on the vendor (chapter 24).

Maintenance is not just fixing bugs

Software is like a car in a garage: even if you do not drive it, the tires age and the inspection certificate expires. The system does not change, but the world around it does. New versions of browsers and operating systems come out, vulnerabilities are discovered in libraries, and legislation changes. For each component, also keep an eye on its end of life, after which it no longer receives security patches.

Maintenance therefore includes:

• bug fixes and security patches,
• updates of libraries, platforms, and databases,
• adapting to new versions of browsers and operating systems and to legislation,
• paying down technical debt (chapter 23).

Update in small steps, every month or quarter. If you put off updates for years, small modifications turn into a separate and expensive project. Ask for a list of components and their versions (SBOM) with end-of-life dates, and agree in the contract on an obligation to keep the system on supported versions.

A warranty does not replace maintenance. It covers defects in the work, not the move to a new version of the platform. And most of the money after launch does not go into fixes: maintenance accounts for 40–80% of the cost of software over its whole lifecycle, and roughly 60% of it is enhancements Glass, 2002. A budget “just for fixes” is therefore not enough. The statistics count enhancements as maintenance; in the budget below, we separate them out as further development.

How much per year, and how to split it

The baseline estimate from chapter 4 applies: 10–20% of the purchase price per year for operations and maintenance, without new features. It is an indicative estimate derived from several audits by the Supreme Audit Office (NKÚ), not from a representative sample. Operating the basic registers comes to about 12% of the purchase price per year NKÚ, audit conclusion KZ 23/05, and support for the new travel document system of the Ministry of Foreign Affairs (MZV) to about 8% NKÚ, audit conclusion KZ 24/26. Further development cannot be estimated as a percentage; calculate it from the roadmap: the number of person-days times the rate.

Keep the money in three separate envelopes: operations and support, maintenance including technical debt, and further development. When everything is in one pot, maintenance always loses out to new features. But a percentage for technical debt alone is not enough; the reserved capacity must go to the parts of the debt that hold the system back the most McKinsey, 2023.

Once a year, also review licenses and servers. The State Agricultural Interventional Fund (SZIF) paid almost CZK 417 million for SAP licenses in 2016–2019 and did not track how they were used NKÚ, audit conclusion KZ 20/07. Paying for unused licenses is like paying rent for a warehouse that nobody goes into.

Fixed monthly fee or orders?

To keep the cost of comparable modifications from gradually rising:

• fix or index the rates by role,
• ask for an effort breakdown by activity and role with every proposal,
• track how much comparable changes cost over time,
• insist on automated tests, which make every further change cheaper,
• compare the total price of a change with the market, not just the rate per person-day.

By comparing unit prices at SZIF, NKÚ found that the fund was paying its main vendor many times more than comparable services from other vendors in the ministry’s sector cost NKÚ, audit conclusion KZ 20/07. Rising effort without an explanation is a measurable symptom of technical debt or vendor dependency (chapter 24).

A system needs an owner and a roadmap

After launch, the project team leaves, and the system often ends up without a clear owner. Appoint a product owner on your side who decides on priorities and is responsible for the system. The owner maintains a roadmap for 12–24 months with priorities based on benefit, not on who pushes their requirements the loudest. Once a year, go through the roadmap, the end-of-life dates of components, licenses, and infrastructure utilization with the vendor.

Think about the end of the old system, too. The MZV case in chapter 4 shows how expensive parallel running is when nobody switches off the old system.

Debt works like a loan

Technical debt is like buying on a credit card. You get the thing right away, but until you pay off the debt, you pay interest. In software, a shortcut might be a missing test, copied code, or a postponed update. The interest is the extra time needed for every further change.

Debt in itself is not a mistake. A deliberate shortcut to meet a deadline is a legitimate decision. The problem is debt that nobody knows about and nobody pays down. McKinsey describes the interest as a complexity tax that every project pays. In a survey, IT leaders of large companies estimated that 10–20% of the budget for new products is consumed by dealing with debt instead, and 60% of them feel that debt has grown over the past 3 years McKinsey, 2020. These are the respondents’ estimates, not direct measurements, but they still point to the scale of the problem.

How to recognize it without reading the code

The best yardstick is in your invoices: how much a comparable change costs today and how much it cost a year ago. Other symptoms are bugs after deployment in unrelated parts, modules that nobody wants to get into, and deployments “over the weekend.” Ask the vendor for DORA metrics DORA, metrics (chapter 17), static code analysis results, test coverage, and the age of components in the regular report. Do not track only the absolute values; also focus on how they develop over time.

How to pay down the debt

• Record: the vendor keeps a record of the debt as a list of tasks with an estimate of how much extra work the individual shortcomings cause.
• Permanent capacity: devote part of every sprint to paying it down, instead of a one-off cleanup campaign every few years. Concentrate the capacity where the system changes the most.
• Boy Scout rule: whoever touches a module leaves it a bit better than they found it.
• Contract: “done” also means tests and documentation, and acceptance includes a code quality check (chapter 20).
• Budget: paying down debt is an item in the annual maintenance budget (chapter 22).

Refactoring, rewrite, or replacement?

A system becomes obsolete when running and changing it costs disproportionately much, its technology has lost support or you cannot find experts for it, and the system cannot handle new requirements, such as round-the-clock operation or integration through an API. Age alone does not decide. But a platform’s end of life means a mandatory and expensive migration: the State Agricultural Interventional Fund (SZIF) has support for its platform secured only until 2027, and the Supreme Audit Office (NKÚ) has pointed out the risk of further high expenditure NKÚ, audit conclusion KZ 20/07. So for every key component, track its end-of-life date and have a plan for what comes next.

Incremental replacement is known in the trade as the strangler fig, after the fig tree that gradually grows around an old tree until it replaces it Fowler, 2004. The new system takes over one function after another until the old system can be switched off. The steps are small and reversible, you see the benefits along the way, and you can change vendors piece by piece. For a while, however, you pay for two systems. A prerequisite is access to the old system, its interfaces, and its data (chapter 24).

A big rewrite all at once is tempting because it promises a clean slate. With large systems, however, the knowledge stored in the old code gets lost, requirements change in the meantime, and the old system has to be developed in parallel. Large-scale modernization takes years: of the 10 critical federal systems that the US Government Accountability Office identified in 2019, three had been modernized by February 2025 GAO, 2025. A switch-off plan and a budget for parallel running therefore belong in the project from the start. The MZV case in chapter 4 shows what happens without them.

Vendor dependency is the rule, not the exception

In Czech public procurement, the Datlab Institute found 910 relationships between public authorities and vendors in vendor lock-in, worth roughly CZK 8.5 billion a year. That is about 53% of the analyzed government spending on IT vendors, and the dependency affects 13 of the 15 ministries Datlab Institute, 2021. The Supreme Audit Office (NKÚ) writes that dependency “significantly increases costs” and leads to a decline in IT competence on the government side NKÚ, Annual Report 2021. Companies have the same problem; it is just that nobody measures it.

Lock-in is like a car that only one garage is allowed to service. The garage sets the price, and when you want to go elsewhere, you find out that it also has the keys and the service book. You can recognize it when:

• every change is more expensive than the last one, and nobody can say why,
• tenders for further development end with a single bid (in government IT contracts, these have accounted for more than 20% of the volume since 2017 Datlab Institute, 2021),
• the vendor refuses to hand over the code, access, or documentation,
• you do not know the structure of your own data,
• nobody knows how much moving elsewhere would cost.

You get out step by step, not in one leap

Replacing the vendor completely is the last and most expensive step. Both Datlab and the methodology of the Public Procurement Association (AVZ) recommend starting with the cheapest thing that reduces the dependency AVZ, 2023:

1. a partial transfer of rights or a license for modifications,
2. handover of the code and documentation,
3. transfer of know-how,
4. opening up the interfaces,
5. splitting the system into modules and replacing them gradually,
6. only at the very end, a complete replacement.

When should you act? According to Datlab, when the costs exceed those of comparable services to such an extent that moving to another provider or a new system pays off in the medium term, say within 7 years Datlab Institute, 2021.

You agree on the exit plan in the contract (chapter 11). In practice, you then keep it up to date: update the handover package with every release, and once a year have an independent party test it. An audit at handover primarily verifies whether the system can be built, deployed, and modified from the materials delivered. It also checks whether the code handed over matches the version running in production.

Source code escrow is an emergency brake, not a way out

Escrow is a three-party contract: the vendor deposits the code with a third party, which releases it if the vendor goes bankrupt or fails to perform over a long period. It helps if the vendor goes under. If the vendor is just expensive or slow and you want a different one, you usually will not meet the release conditions. Even released code may not be usable if:

• the deposited version has not been updated for years and does not match production,
• nobody has verified that it can be built,
• a license for modifications by a third party, the documentation, and the data are missing.

Also expect vendors to stipulate in the contract that they are not liable for parts that another company has modified. So agree in advance that the warranty remains valid for the untouched parts and that changes are traceable in Git. The main safeguard remains the continuous handover of the code and rights.

Cloud: the Data Act only goes halfway

The EU Data Act has applied since September 12, 2025, and gives you the right to switch to another cloud provider within clear time limits (Article 25): a notice period of no more than 2 months, the switch itself within no more than 30 days, or up to 7 months if it is technically unfeasible, and then at least 30 days to retrieve your data. Until January 12, 2027, switching charges may cover no more than the direct costs. After that, they are to be abolished, including data egress charges Data Act, Art. 29.

There are, however, two important limitations. For services largely custom-built for a single customer, the ban on charges and the obligation of functional equivalence do not apply, but the time limits do (Article 31). So for custom software, the Data Act protects you only partially. It helps most with the standard cloud services the system runs on. And the proprietary services of a particular cloud have to be rewritten when you leave anyway. So build from portable parts (chapter 15) and plan large migrations for after January 12, 2027.