Contract Package for a Diia City Resident Company
When a team is preparing to join Diia City, the focus is often on registration, Ukrainian KVED (NACE-based activity classification) codes, average remuneration, and the compliance report. The contract package is sometimes postponed “until later” – until the first dispute over code, a legal claim from a client, or a check of whether the company is actually earning qualified income. That is when it becomes clear that, under the Diia City regime, a contract is not a template from a “standard documents” folder. It is how the company records its engagement model, transfers intellectual property, and preserves its resident status.
A mistake in a contract costs more than editing a clause.
It can turn relations with a gig specialist into an ordinary civil-law agreement without the safeguards of the Law of Ukraine “On Stimulating the Development of the Digital Economy in Ukraine” dated 15 July 2021 No. 1667-IX, leave the code with the gig specialist, render a non-compete clause void, or undermine the company’s position in a dispute with a client.
Below is a list of agreements without which the residency regime works only halfway. It is worth putting them in place before entering the regime or immediately after the company is added to the register, before the business starts working with its team, clients, and investors.
Why the Charter and Resident Certificate Are Not Enough
Resident status gives a company the right to use special legal mechanisms. By itself, it does not create a legal relationship with a gig specialist, transfer proprietary rights to code, or make a non-compete obligation binding on a gig specialist. If a company has entered the register but continues to work with its team “as before” – through individual entrepreneurs, oral arrangements, and last year’s NDA – that may not be enough for the regime.
The rules of Law No. 1667-IX apply equally to a product company selling its own SaaS, an outsourcing provider with long-form MSAs, and a startup that has just closed its first round. What differs is not the rule itself, but which agreement holds the particular business model together and where a mistake is most costly. For a product company, the key is to ensure that the code, design, and user database do not remain with a gig specialist or individual entrepreneur, but that the proprietary rights are consolidated in the legal entity selling the subscription. For an outsourcing or outstaffing provider, the client-facing framework comes first: the MSA and SOW should not promise the client more than the company already has under its agreements with the team (rights to the deliverables, realistic performance deadlines, and so on). In a startup that has closed a funding round, an investor looks at more than the gig contract. It matters whether options and equity interests were properly documented and whether the company can show that the product belongs to it rather than being scattered among different contractors.
It is also important to remember that the Diia City regime is not only about the gig contract. Law No. 1667-IX separately regulates the employment contract, non-disclosure agreement, agreement to refrain from competitive activities, option, and loan with an alternative obligation. A resident may build its team using both employment agreements or contracts and gig contracts. The difference lies in the legal regime: employees are governed by labor law and HR record-keeping requirements, while the gig model is governed by the special rules of Law No. 1667-IX. A non-disclosure agreement protects code, client data, the fact of working with a client, and similar information. A non-compete addresses a different risk: preventing a team member from taking the same experience to a direct competitor. A loan with an alternative obligation is relevant when the company raises investment. If the entire package consists of just one contractor agreement, the company is using the regime only halfway. It operates under the resident status but does not use the legal tools for which that status was designed.
Team Agreements: Employment, Gig Contracts, and Agreements with Individual Entrepreneurs
The first layer of the package is the engagement model. Before dealing with an NDA, non-compete, or client MSA, the company needs to answer a more basic question: on what legal basis does a person become a member of the team? The answer determines which laws apply to that person, whether they count toward the resident criteria, and who pays the taxes.
A Diia City resident may combine three frameworks
| 1 | Employment agreement or employment contract under Article 16 of Law No. 1667-IX. |
| 2 | Gig contract with an individual under Article 17. |
| 3 | Цивільно-правовий договір з ФОП. |
These models may be combined. The problem is not the combination itself. The problem arises when the same document mixes characteristics of all three models while, for accounting and reporting purposes, the person is counted under the wrong category.
If a specialist is engaged under an employment agreement or employment contract, labor law applies. The company gets the standard HR framework: hiring, record-keeping, vacations, sick leave, grounds for termination, and so on. An employment contract under the Diia City regime allows the parties to define the term, remuneration, termination grounds, and intellectual property regime more flexibly than a “bare” hiring order. This is useful for key roles where the discipline of regular employment is needed. But an employment contract does not take the person outside labor law. Labor legislation does not disappear. If the company wants a model that is “almost like gig, but on staff,” it still has to provide the applicable labor guarantees.
Gig contract – a separate legal construct. It may be entered into only by a Diia City resident and only with an individual. Another legal entity, even one with IT KVED codes, cannot enter into this type of agreement. A party to a gig contract is not an individual entrepreneur acting in their entrepreneurial capacity: the individual signs it in their own name, not as a business entity.
A civil-law agreement is not considered a gig contract unless it expressly states that it is being entered into specifically as a gig contract.
This is not merely a drafting detail in the preamble. Without this wording, the company loses the special rules of Law No. 1667-IX – from the presumption that proprietary rights are transferred to the resident to the ability to enter into a paid non-compete under the logic of this law. The contract must be in written or electronic form. An oral arrangement, an email saying “we start on Monday,” or access to a repository will not automatically become a gig contract.
The tax treatment under these models also differs. For a gig specialist, the company is the tax agent: it calculates and withholds taxes from the remuneration. For an individual entrepreneur, it is not: the entrepreneur calculates and pays their own taxes. An individual entrepreneur is not included in the average headcount requirement of “nine persons” and is not included in the calculation of average remuneration. Employees and gig specialists are included in those calculations.
The tax authority must be notified of the conclusion of a gig contract, just as it must be notified of hiring under an employment agreement, before the person starts work. There is another scenario that templates often overlook. If the company is removed from the Diia City register, the gig contract terminates after a certain period and the special regime no longer applies to the relationship. To continue working together, the parties need an ordinary civil-law agreement or employment agreement instead – without the special rules on which they relied under the gig framework.
What a Gig Contract Should Contain
Simply calling a document a “gig contract” does not resolve its substance. The text should define the term, rights, obligations, liability, remuneration, task-assignment process, acceptance of results, and grounds for termination, taking into account the specific requirements of the law. If no term is specified, the contract is considered indefinite. If the parties continue performing it after the stated term expires, it is, by default, extended for the same period and on the same terms.
The social guarantees under Section V of the Law are not optional. A gig specialist is entitled to an annual paid break of at least 17 working days, temporary incapacity benefits, and a break in connection with pregnancy and childbirth. These guarantees may be detailed in the agreement or in internal documents incorporated into it by reference.
A resident’s internal policies may be incorporated into the gig contract by reference. This is convenient for security rules, task-assignment procedures, equipment-use rules, and similar matters. But the specialist must then be notified of changes in advance – as a general rule, no later than 30 days before they take effect, unless the parties agree on another period. A policy that was simply updated in Confluence without being sent to anyone looks weak in a dispute.
As a general rule, termination of a gig contract requires 30 calendar days’ notice.
The resident may shorten that period by replacing it with compensation of no less than the daily remuneration for each day by which the notice period is shortened. A gig specialist’s financial liability for damage caused to the resident’s property through the specialist’s fault is limited: deductions may not exceed 20% of the monthly remuneration. A penalty for breach of confidentiality or non-compete obligations is a separate matter and should be addressed separately.
Contractual Intellectual Property Framework
Personal non-property rights in an object created in connection with the performance of a gig contract remain with the gig specialist. The company cannot “take away” the author’s name or the right to the integrity of the work. Proprietary rights are different: the rights to use code and design, modify them, license them, sell them to a client, or incorporate them into a product. Under Article 24 of Law No. 1667-IX, these rights belong to the resident as the customer unless the gig contract provides otherwise. This is a strong presumption. It applies specifically within the relationship with the gig specialist and specifically to an object created in connection with the performance of that contract.
The presumption does not extend beyond its perimeter.
It does not replace an agreement with a designer who creates banners as an ordinary freelancer without a gig contract. It does not automatically cover code written before the cooperation began, even if the specialist later added it to the same repository. Nor does it operate automatically in an agreement with an individual entrepreneur if that agreement contains the opposite formula: “rights remain with the contractor.”
In practice, a single sentence stating that “all rights belong to the company” is not enough. That sentence does not answer the questions that a client or investor may later ask. What exactly qualifies as an object created in connection with the performance of the contract: only code delivered under a task to the work repository, or also development work that the specialist created in their own time but based on an internal specification or using company materials? What about pre-existing materials – a library, template, or component that the person brought with them? Does the transfer include the right to modify, sublicense, and transfer the result to a client, affiliates, or a successor? What happens after the cooperation ends to repositories, accounts, domains, keys, design files, and cloud access? These issues should be addressed in the agreement.
Rules on open-source software, third-party libraries, and generative models should also be agreed separately. The presumption under Article 24 transfers to the company the proprietary rights in what the gig specialist personally created in connection with the contract. It does not override the license governing third-party code that the specialist integrated without permission. If a library from GitHub enters the product, that code already has a rights holder and its own terms. The company becomes the owner of the specialist’s modifications, but it does not automatically obtain the right to use a third-party fragment however it wants.
The same applies to generative models. If a specialist feeds client code, an internal specification, or a repository fragment into a public chat, the model stops being just a tool. The material has already left the company’s perimeter. It may be used for further training, may appear in a response to another user, and may be difficult to retrieve. The presumption under Article 24 does not help here: rights in generated text are already a disputed issue, while the obligation not to disclose client code remains in force.
If these rules are absent from the agreement with the team and from the SOW with the client, it may be pointless later to explain to the client that “it was more convenient for the developer that way.” The party accountable is not a commit or the author of a library. It is the company that warranted to the client that the rights in the deliverables were clear.
Non-Disclosure Agreement
Article 26 of Law No. 1667-IX expressly allows a resident to enter into a non-disclosure agreement. This is one of the few situations in which Ukrainian law does not leave an NDA in a gray area. But the law’s express permission does not save an empty two-page template that declares “all company information” confidential.
In a dispute, the company needs more than a good-looking heading – it needs a definition of what is protected: code, client data, the financial model, the funnel, unreleased features, the content of negotiations, the very fact of working with a particular client. It needs exclusions, such as information that is publicly available or independently created without using the company’s confidential information. It needs a survival period after the cooperation ends. It needs a ban on portfolio use where a demo reveals the client’s architecture. And it needs a clear sanction, rather than a generic obligation to “compensate for damages” without any methodology.
The NDA with the team and the NDA with the client should be aligned.
If a client Mutual NDA prohibits disclosure even of the fact that negotiations are taking place, while a specialist posts on LinkedIn that they are “proud to be building a product for this brand,” the company itself is already technically in breach. After a person leaves the team, the agreement should continue to set out the procedure for returning or destroying storage media, access credentials, and copies.
Agreement to Refrain from Competitive Activities
Articles 27 and 28 of Law No. 1667-IX allow a resident to enter into an agreement with a specialist to refrain from competitive activities. This is a powerful tool for which there is no equivalent detailed framework in labor legislation.
A non-compete clause is valid only if it is paid. The compensation must be fair.
A specialist’s refusal to sign such an agreement does not, by itself, give the resident the right to terminate the gig contract: the law separately protects freedom of consent.
The prohibited activities should be described specifically, for example, particular relationships with persons carrying out similar activities; the specialist’s own competing activities as an individual entrepreneur; or participation in the capital or management bodies of a competitor. An abstract ban on “working in IT anywhere in the world for one year” looks less like business protection and more like an attempt to remove a person from the labor market.
In practice, two extremes often appear here, and both currently look vulnerable. The first is to state that the non-compete payment is “included in the monthly remuneration” without identifying it separately in the payment or calculation. In that case, it is difficult to show that the restriction was actually compensated separately rather than merely named in the text. The second is to set a symbolic amount while imposing a broad territorial and time scope. In that case, the “fairness” of the compensation itself becomes questionable: the restriction is substantial, while the consideration provided in return is relatively small.
It is impossible to say in advance exactly how a court will assess this in a particular dispute. For now, it is safer to structure the arrangement so that it can be explained: a separate payment, or a separately identified portion of the remuneration with the payment description “non-compete compensation,” together with proportionate time and territorial limits. The sanction for breach of this agreement should be drafted separately and should not be mixed with the NDA penalty or with the limited deductions applicable to damage to property.
Client Agreements
A Diia City resident rarely operates in a vacuum. The external layer of the package includes the MSA, SOW, order form, SLA, and sometimes a separate IP assignment in favor of the client. If the internal agreements with the team are not synchronized with what the company signs with the client, the risk usually surfaces not during onboarding, but during due diligence before a large contract or an investment transaction.
The client wants a warranty that the company owns the rights in the deliverables or has the right to transfer them, and that the product does not contain third-party code used without a license. These promises can be made in the MSA only if the same substance is already reflected in the agreements with the team: a clear chain of intellectual property rights, an NDA that covers the client’s confidentiality perimeter, and rules on subcontracting.
Non-solicitation is a separate issue. This protects the service provider. A client may spend several months seeing a developer in Slack and on daily calls and then offer the developer a position directly. If the MSA does not contain a non-solicitation clause for the project term and a certain period afterward, and the gig contract does not bind the specialist not to go directly to that client around the company, the resident has no effective tool to protect its margin. An outstaffing model without a right to replace the specialist, without an NDA aligned to the client perimeter, and without a prohibition on direct hiring is not a flexible model.
The liability limitations in the client agreement should also be compared with those in the agreements with the team.
If the MSA sets a cap equal to the annual remuneration under the SOW, the company may owe the client tens of thousands of dollars for a missed deadline, a security vulnerability, or an IP claim. The problem is particularly noticeable where the gig contract makes the specialist liable only for a symbolic amount or only through the limited deductions applicable to damage to property. The difference between those two caps does not disappear. The resident pays it.
That is entirely reasonable if the company made the choice consciously, kept the risk on its own side, and priced it into its margin. But it is dangerous when this result is simply the default of two templates that no one has read together. One thing is then written in the MSA and another in the gig contract, and when a claim arises it turns out that there is almost nothing to recover from the contractor.
Corporate Agreements
A separate layer of the package is often remembered late – when the company needs to document an option or explain to an investor on what basis a specialist claims an equity interest. Law No. 1667-IX gives residents direct legal mechanisms for this purpose: an option and a loan with an alternative obligation. By themselves, however, these mechanisms do not create an equity interest.
What is needed, among other things, is an agreement that shows the amount, term, price or formula, and exactly what the person will receive if the relevant condition is met.
An oral promise of “a percentage after the release” may work as team motivation. In a dispute, however, it is much harder to turn that promise into a claim for the transfer of corporate rights than it is when there is a document with clear parameters.
This same layer also includes shareholders’ or participants’ resolutions, contractual arrangements on the allocation of equity interests and the procedure for transferring them, a corporate agreement, and similar documents. They do not replace the gig contract and do not govern day-to-day work. Their role is different: to record who owns the company and on what terms another person may enter its capital.
How to Assemble the Package Before Entering the Regime
Before entering Diia City, or before moving a team to a gig-specialist engagement model, it is worth walking through the company’s lifecycle as if it were a new business: a map of roles, selection of the form of cooperation for each role, onboarding, the first task, the first payment, a change in the rate, a specialist’s exit, and the transfer of rights to a client. At each step, it becomes clear which document covers the issue and whether that document would withstand scrutiny by a client, investor, or tax authority.
This is how a living set of documents emerges instead of a pile of templates. For a typical resident, it consists of several circles. At the center are agreements with the team: an employment agreement or employment contract, a gig contract, and an agreement with an individual entrepreneur where that model is genuinely appropriate. Around them are the non-disclosure agreement and the agreement to refrain from competitive activities. Next come the client MSAs. Above them are the charter, corporate resolutions, and similar documents. If one of these circles is missing, what breaks is not merely a “piece of paper.” What breaks is the chain by which the company demonstrates that the regime, the code, and the team are legally anchored to that company.
Compliance does not sit separately from the product. The way a party is named in the heading of an agreement can determine whether a particular contractual regime applies. The way the intellectual property section is drafted can determine whether the company has anything it can legally sell to the client. Whether the non-compete is paid can determine whether the restriction remains enforceable after a person leaves. That is why the contract package should be assembled with a lawyer before launch, not after the first complaint or dispute over code.
Companies becoming Diia City residents should plan the contractual framework as early as they plan the calculation of average remuneration.
Fixing the gig contract, NDA, and chain of rights before a specialist is onboarded is cheaper than later having to explain why the product is “sort of ours” while the repository tells a different story. There is no universal template that works for every product, outsourcing, and outstaffing model. Before launch, it makes sense to involve lawyers who can map the particular team and particular clients against the framework of Law No. 1667-IX and identify exactly what needs to change so that the agreements properly support the regime, the rights, and the team. The Legal IT Group team will be happy to assist with these matters.
