Ukrainian product IT companies create competitive software capable of solving complex national-scale tasks. However, in the public procurement market, domestic developers often face discriminatory requirements in tender documentation. These non-technical barriers artificially limit the access of Ukrainian intellectual property (IP) to government contracts in favor of outdated foreign solutions. For owners and CEOs of product companies, this is a strategic challenge that directly affects business capitalization and the ability to scale in the local market.
Anatomy of discrimination: how non-technical barriers block Ukrainian software
Software procurement in Ukraine is regulated by an established order that defines rules for selecting suppliers and should ensure transparent competition. In practice, however, government customers often include non-technical barriers in their requirements. The most common are conditions regarding the availability of specific partner certificates from a particular foreign vendor or verified experience in implementing their licensed products.
For the Ukrainian product business, this creates a dilemma: invest significant resources in obtaining foreign certifications that have no direct relation to the quality of one's own code, or initiate a review of criteria through professional IT associations. Choosing the latter allows for protecting one's own IP and shifting the focus of procurement to objective functional requirements and open security standards.
Monolith versus microservices: why outdated architectural requirements conserve inefficiency
Technical specifications in government tenders often rigidly fix a monolithic architecture, making it impossible for modern cloud-native solutions to participate. According to Martin Fowler's definition, the microservices style of development involves building systems from independently deployable services, which ensures management flexibility and speed of delivering new features.
It is worth noting that microservices are not a universal solution for every project. In the initial stages of development (monolith-first approach), a monolith may be more economically feasible due to simpler infrastructure. However, when a customer buys a large-scale national system and artificially demands only an outdated monolithic model, it preserves technological backwardness. Modern approaches allow for significantly reducing scaling costs compared to traditional legacy systems.
The hidden price of legacy: why ignoring TCO harms the budget
A common mistake when evaluating tender proposals is focusing solely on the initial cost of licenses, ignoring the Total Cost of Ownership (TCO). Legacy systems may seem cheaper at the initial procurement stage, but their maintenance and customization require large budgets.
According to analytical reports in the IT consulting sector, in outdated systems, up to 49% of expenses go toward maintaining the functionality of legacy code, while only about 13% of the budget remains for developing and implementing new features. The lack of TCO evaluation criteria over a 3–5 year horizon allows these costs to be hidden and blocks competition from more economically efficient Ukrainian platforms.
Standards instead of brands: 12-Factor App principles and open source
Instead of tying requirements to brands, tender documentation should focus on modern development methodologies. In particular, adherence to 12-Factor App principles ensures software portability between different environments and significantly simplifies horizontal scaling.
Describing requirements around open interfaces (API), integration protocols, and compatibility standards creates a level playing field for participants. This allows domestic companies to compete based on architectural quality rather than partner statuses from global corporations.
The formula for a fair tender: how to scale Ukrainian IP
To create high-load systems, the public sector does not necessarily need to choose foreign proprietary solutions, as there is a mature technological base in Ukraine. An example of such a foundation is the full-stack JavaScript low-code / model-driven platform UnityBase. It is a joint development of companies within the Intecracy Group (an alliance of independent companies linked by partner agreements and share exchanges, where InBase is a key, but not the only, developer). The platform provides architectural mechanisms for enterprise applications: a unified domain model (Domain metadata), automatically generated REST API, flexible access control models (RBAC/RLS), and built-in audit tools (audit trail).
Solutions such as the electronic document management systems Megapolis.DocNet and Scriptum are built on UnityBase, which confirms the ability of Ukrainian software to operate under high loads and strict security requirements. An additional advantage of open architecture is the ability to integrate modern AI solutions — for example, computer vision or analytics services from Softengi, which is certified according to the international standard for artificial intelligence management ISO/IEC 42001.
To protect the interests of the state and develop the Ukrainian IT market, the criteria for selection in public procurement should be open architecture, real security, and proven economic efficiency calculated through TCO.
| Discriminatory requirement | Justification for restriction | Modern open alternative |
|---|---|---|
| Presence of specific partner certificates from a foreign vendor | Artificially narrows the pool of participants to partners of a single brand | Requirement for compliance with open security standards and integration compatibility |
| Rigid adherence to the monolithic architecture of a specific legacy system | Makes it impossible to use flexible microservices and cloud-native solutions | Description of requirements for API, integration protocols, and horizontal scaling methods |
| Evaluation of proposals solely based on initial license cost | Hides high costs for subsequent maintenance and customization | Mandatory evaluation of Total Cost of Ownership (TCO) over a 3–5 year horizon |
FAQ
How can a Ukrainian product company challenge discriminatory requirements in tender documentation?
The company can file an official request to the customer through the electronic procurement system with a detailed technical justification of how specific requirements limit competition. If the request is rejected, the participant has the right to file a complaint with the Antimonopoly Committee of Ukraine (AMCU), providing evidence that the technical specifications were written for a specific foreign product.
Which architectural requirements in technical specifications indicate hidden procurement for a specific foreign vendor?
Signs include the use of specific internal module names, rigid requirements for using a proprietary database or a closed integration bus of a specific brand, and the absence of descriptions for open interfaces (API), instead detailing unique technical features of a single system.
How can one prove the advantage of cloud-native architecture over outdated monolithic systems to a customer during a tender?
The argument should be based on financial and operational efficiency: provide a TCO calculation demonstrating lower scaling costs and refer to the 12-Factor App principles, which ensure software independence from specific cloud environments and fault tolerance during peak loads.
Data sources
- vertexaisearch.cloud.google.com: Закупівля програмного забезпечення - Держзакупівлі
- martinfowler.com: Microservices — a definition (Fowler & Lewis)
- Heroku / community: The Twelve-Factor App
- vertexaisearch.cloud.google.com: Перелік забороненого програмного забезпечення - Радник у сфері публічних закупівель