Request a quoteGet a quote

    ↑ ↓ selectEnter openEsc close

    The whole guide for printing: vyvoj.solutia.cz/en/guide/print

    Part III Development: keeping the project on track

    What software is built on

    ~10 min readUpdated Lukáš Mikula

    You do not have to understand code, but you do have to watch five things that decide whether the system can be fixed and handed over to another vendor in five years. Dependency comes not from the programming language but from the contract and the documentation. Choose widely used technologies and a simple architecture, and describe your requirements for security, accessibility, and AI using specific standards and rules.

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

    The vendor’s own framework

    “We build on our own platform; it’s our know-how.” This is the strongest red flag for dependency. Only the author of the platform can then develop the system further, and at its prices. Accept it only with the platform’s source code, documentation, and the right to hand both over to another vendor. Otherwise, ask for a common public framework.

    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.

    Three ways to organize a system internally
    MonolithModular monolithMicroservices
    Comparisona large hall without partitionsa house with rooms and doorsa development of small houses connected by paths
    Operationssimplesimplecomplex
    Takeover by another companyhard without internal ordereasiestexpensive
    When it makes sensesmall systemsmost business and government systemsmany independent teams, extreme load

    The recommendations for choosing an architecture are indicative.

    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:

    Mobile apps: three paths
    NativeCross-platformPWA (a website as an app)
    Costshighest, two codebasesmedium, one codebaselowest
    Phone featuresallmostlimited, especially on iOS
    Who can take it overtwo types of specialistsexperts in the given frameworkordinary web developers
    WhenBluetooth, NFC, biometrics, demanding graphicsa typical app with notifications and a cameraforms, overviews, internal tools

    The comparison is indicative. For native and cross-platform apps, plan for annual costs of keeping up with new versions of iOS and Android.

    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:

    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.

    How it goes wrongHow to do it right
    How it goes wrong“The platform is our know-how; we’ll hand over the code when the cooperation ends.”How to do it rightCode and documentation in your repository on an ongoing basis; another company tries to build the system.
    How it goes wrongTechnology chosen by fashion, or by what one person knows.How to do it rightWidely used technology with documented support and an overview of end-of-life dates.
    How it goes wrongMicroservices “like Netflix” for a system with one team.How to do it rightA modular monolith with documented interfaces that can be split up later.
    How it goes wrongA system tied to one cloud’s services, accounts in the vendor’s name.How to do it rightStandard building blocks, accounts in your name, an exit plan with a price.
    How it goes wrong“It will be secure”; a penetration test only after launch.How to do it rightASVS 5.0 level 2, SBOM, and an independent test as a condition of acceptance.
    How it goes wrongCalls to one AI provider’s services scattered throughout the code.How to do it rightAn abstraction layer for replacing the model and an AI Act classification in the documentation.

    Questions

    Questions about the technology

    1. Why this technology and architecture? What alternatives did you consider? Explain it in one sentence.
    2. Until when are the versions used supported, and who will pay for the migration to a new version?
    3. Do you use your own framework or non-public libraries? Will we get their code and the right to hand it over to another vendor?
    4. Could another company take over further development within three months with only what you hand over to us?
    5. Which cloud services are proprietary, and how much would it cost to move elsewhere?
    6. Which OWASP ASVS 5.0 level do you guarantee, will you deliver an SBOM with every release, and who will do an independent penetration test?
    7. Which version of WCAG will you build to, and who will carry out the accessibility audit?

    Solutia video