Part II Preparation and vendor selection
Chapter 7: Who will build your software
The type of vendor determines the risk more than its presentation does. What matters is who will be responsible for the result and how much of the project management you can handle yourself. If you hire people by the hour, responsibility for the result stays with you, even if you expect a finished system.
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).
| Type | Suitable for | Main risk | Rate per PD (indicative) |
|---|---|---|---|
| Freelancer | small changes, a prototype, reinforcing your team | everything depends on one person | usually below the MV median |
| Small studio | web and mobile apps, MVP | key people, cash flow, 24×7 support | usually below the MV median |
| Mid-sized company | enterprise applications and integrations | variable seniority, juniors | around the MV median |
| Large systems integrator | extensive and critical systems, large tenders | overhead, chains of subcontractors, B-team | upper quartile and above |
| Staff augmentation (body shop) | adding to a team you manage | you are responsible for the result | by role, compare with MV |
| Nearshore, offshore | well-described parts under strong management | communication, knowledge transfer, data outside the EU | within the EU often not competitive with Czech prices |
| In-house team | core business, further development for years | hiring, salaries, cover for absences | salary costs, not a rate |
Size limits and rates are indicative. Primary data on rates by vendor type in the Czech Republic does not exist; the Ministry of the Interior’s overview of typical ICT rates (Přehled obvyklých cen ICT prací) does not distinguish vendor types. The median developer rate per person-day in government contracts is CZK 9,920 excluding VAT (first half of 2026, source: MV overview of typical ICT rates, issued July 3, 2026), details in chapter 4.
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.
Different copyright rules may apply to a freelancer than to a company: according to the prevailing interpretation, Section 58(7) of the Copyright Act applies only to a work ordered directly from the author. But the interpretation is not uniform, so always agree on the license explicitly (chapter 11).
| How it goes wrong | How to do it right |
|---|---|
| How it goes wrongYou hire 4 developers from a body shop and expect a finished system. | How to do it rightWith staff augmentation, you have a product owner on your side and an architect. Otherwise, you order a deliverable. |
| How it goes wrongThe director and two seniors came to the presentation; juniors are on the project. | How to do it rightKey personnel named in the contract, replacement only with your consent. |
| How it goes wrongThe freelancer has the code on their laptop. | How to do it rightCode in your repository daily, documentation written continuously, cover for absences agreed. |
| How it goes wrongA large systems integrator for a small application, because “a big brand is a safe bet.” | How to do it rightThe size of the vendor matches the project, and you are an important customer for them. |
| How it goes wrongAn offshore team with no clear location for the data. | How to do it rightYou know where the data and code reside, and you have a data processing agreement. |
| How it goes wrongYou only find out about subcontractors when there is a problem. | How to do it rightA named list of subcontractors with their share of the delivery is part of the proposal. |
- Under Section 6 of the Public Procurement Act (ZZVZ), qualification requirements must be proportionate. Excessive requirements for turnover or headcount exclude smaller vendors who could handle the project.
- You check vendors through qualification (Section 73 et seq. of ZZVZ); practical vendor due diligence is in chapter 9.
- For strategically important services, the National Cyber and Information Security Agency (NÚKIB) may, following a government resolution, restrict or prohibit delivery by specific vendors through a measure of a general nature (Section 29 of the Cybersecurity Act) Act No. 264/2025 Coll.. This also affects offshore solutions.