How to Hire a Software Developer in Uzbekistan: Employment, Civil Contracts or Self-Employment

When a startup hires a software developer, choosing the right arrangement is about much more than deciding how to pay someone. It is a legal and operational decision that affects your company's obligations, flexibility and exposure to risk.

In Uzbekistan, businesses generally consider three options: an employment contract, a civil-law agreement (commonly referred to locally as a GPH agreement), or cooperation with a registered self-employed professional (*samozanyatyy*). The most important factor is not the document's title or the desire to minimize administrative costs. It is the actual working relationship: who directs the developer's work, what deliverables are expected, and how independently the developer organizes their activities.

What you need to know:

• An employment contract is appropriate when a developer works as part of your team, reports to management and performs an ongoing role within the business.
• A civil-law agreement (GPH) is generally suitable for a defined project, individual software module, API integration or specific technical services.
• A self-employed software developer may independently provide software development and technical support services, provided the activities fall within Uzbekistan's permitted list of self-employment activities.
• If the actual working arrangement resembles employment, signing a civil-law agreement will not necessarily protect the company against the risk of the relationship being reclassified as employment.

1. Employment Contract: When a Developer Becomes Part of Your Team

If a developer works on your product every day, receives assignments from the CTO or Product Manager, follows an established work schedule and is subject to your company's internal policies, an employment contract is generally the most appropriate arrangement.

Under this model, the company is not simply purchasing a standalone development deliverable. It is engaging an individual to perform an ongoing job function. The developer becomes an employee, and the company assumes the corresponding responsibilities as an employer.

Employment relationships in Uzbekistan are governed by the Labour Code of the Republic of Uzbekistan. An employment contract can be concluded in written or electronic form. Electronic employment documentation is processed through the Unified National Labour System in accordance with the applicable legal requirements.

When preparing the employment contract, I recommend clearly defining:

• The developer's job title and responsibilities.
• The place of work and working arrangements, including any remote-work provisions.
• Remuneration, payment terms and payment schedules.
• Working hours, leave and rest periods.
• Probationary conditions, if applicable.
• Rules governing company equipment and corporate IT systems.
• Confidentiality obligations and intellectual property arrangements.

Pay particular attention to intellectual property. For an IT company, source code, software architecture, technical documentation and other development deliverables can represent some of its most valuable assets. You therefore need to establish the ownership and allocation of economic intellectual property rights in the work created, taking into account applicable legislation and the nature of the employment relationship.

The main advantage of an employment contract is legal certainty when engaging someone on a long-term basis and integrating them fully into your organizational structure. The trade-off is more extensive HR and administrative management, together with the employer obligations imposed by labour legislation.

2. Civil-Law Agreement (GPH): When You Need a Deliverable, Not an Employee

A civil-law agreement is suitable when a company commissions a defined piece of work or a particular service, and the contractor undertakes to deliver it under agreed contractual conditions.

Examples include:

• Developing a specific application module.
• Building an API integration with an external service.
• Conducting a software audit.
• Developing a website or minimum viable product (MVP).
• Fixing a defined set of technical issues.
• Migrating a database.

Unlike an employment relationship, the parties act as a customer (client) and an independent contractor. The central contractual obligation concerns an agreed deliverable or service, rather than the ongoing performance of a job function under an employer's direction.

For the agreement to work properly, I recommend addressing the following elements:

Scope of Work. Avoid vague descriptions such as "provision of programming services." Specify what needs to be developed, which features must work and what the client expects to receive.

Technical Specifications. Document product requirements, compatibility, integrations, limitations and acceptance criteria. The technical specification should be sufficiently detailed to allow both parties to determine objectively whether the work has been completed.

Deadlines and Milestones. Divide substantial development projects into independently identifiable stages. Define the deliverable and handover procedure for each milestone.

Fees and Acceptance. Specify the contract price, payment terms, deliverable review process and formal acceptance procedure. If revisions are included, distinguish corrections covered by the original price from additional work that may require separate payment.

Intellectual Property. Expressly regulate rights to source code, designs, documentation and other deliverables. Establish how source files and the necessary technical access credentials will be transferred.

The biggest mistake is treating a GPH agreement as a universal substitute for an employment contract. If the contractor actually follows the company's working schedule, continuously receives instructions from a manager and complies with internal workplace rules, the company may face a risk of employment reclassification.

Uzbekistan's Labour Code provides for the possibility of a court recognizing such an arrangement as an individual employment relationship. What matters is the substance of the parties' actual relationship, not the heading on the agreement.

3. Self-Employed Software Developers: A Flexible Option for Independent Professionals

Self-employment can be a convenient arrangement when a company engages an independent developer who organizes their own work and provides services to multiple clients.

There is an important point for IT businesses operating in Uzbekistan: software development and technical support involving software, information systems, mobile applications and websites are included in the list of permitted activities for self-employed individuals.

However, you should never assume that anyone describing themselves as a freelancer automatically qualifies for this status. You need to check the current list of permitted activities and confirm that the services actually being provided fall within the relevant category.

An updated list of permitted activities for self-employed individuals applies from 2026. This makes it particularly important to consult the current version of the relevant regulations before entering into an agreement, rather than relying on outdated templates or online articles.

When engaging a self-employed software developer, I recommend checking:

• Whether the individual has a valid self-employment registration.
• Whether the services actually provided correspond to a permitted activity.
• Whether identification and payment details are accurate.
• Whether the contractual terms and payment arrangements are appropriate.
• Whether there is proper documentary evidence of the services performed.
• Whether the transfer and ownership of intellectual property rights are clearly addressed.

Self-employment does not remove the client's obligation to structure the contractual relationship correctly. You should also assess the tax implications separately, as these depend on the parties' legal status, the nature of the income and the tax rules currently in force.

If a developer works exclusively for one company, receives daily instructions from a manager, must follow a fixed schedule and is effectively integrated into the company's internal operations, registering as self-employed does not, by itself, eliminate the risk of employment reclassification.

4. Civil-Law Agreement or Employment Contract: What Should a Startup Choose?

In practice, the right choice depends on the nature of the work, the developer's level of independence and the expected duration of the engagement.

My recommendation is to take a product-oriented approach: define the working model first, then select the appropriate legal document.

Consider two scenarios.

In the first, you hire a Backend Developer who works with your team every day, participates in sprint planning, receives a regular salary and reports to the CTO. This is a typical situation for an employment contract.

In the second, you need a payment integration developed for your application. The contractor independently determines how to complete the task, agrees on the technical specifications and delivers the finished integration. A civil-law arrangement may be much more appropriate here.

Do not choose an agreement solely because it appears to offer the lowest immediate cost. Getting the legal structure wrong can ultimately cost your company much more than properly documenting the relationship from the outset.

5. A Separate Risk for IT Companies: Who Owns the Source Code?

When discussing developer engagement, we cannot focus exclusively on employment arrangements and payment. For a technology business, intellectual property is one of its core assets.

Imagine this scenario: a developer creates a critical product feature and subsequently ends their relationship with the company. The startup still has the code repository and a functioning version of the application, but its legal documents do not clearly establish who owns the economic rights to the code that was created.

This creates a significant business risk, particularly if the company intends to raise investment, sell its product or undergo legal due diligence.

To avoid these situations, I recommend:

• Clearly identifying the development deliverables that will be created during the engagement.
• Defining the intellectual property ownership and licensing arrangements in the relevant agreement.
• Establishing how economic intellectual property rights will be transferred, taking applicable legislation into account.
• Addressing the use of open-source components and third-party libraries separately.
• Providing for the handover of source code, technical documentation and necessary access credentials.
• Verifying ownership of materials created before the engagement or using third-party resources.

AI tools deserve particular attention. If a developer uses generative AI models to produce code, designs or technical documentation, the agreement should address the use of third-party services, the confidentiality of information submitted to those services and the terms governing the use of generated outputs.

6. What to Do This Week: A Practical Checklist

If you are about to hire your first developer or review your existing developer agreements, I recommend starting with these concrete steps:

• [ ] Describe the actual working arrangement: ongoing participation in the team or independent delivery of a project.
• [ ] Determine whether the company needs an employment contract or a civil-law arrangement.
• [ ] If you are considering self-employment, verify the developer's registration and the current list of permitted activities.
• [ ] Prepare technical specifications with measurable deliverables and acceptance criteria.
• [ ] Define the fees, deadlines, payment terms and liability of each party.
• [ ] Establish ownership and transfer arrangements for intellectual property rights in the software code and documentation.
• [ ] Review confidentiality obligations, repository access and data-handling requirements.
• [ ] Conduct a legal review of your existing agreements with developers.

For a more systematic approach, I recommend maintaining three internal contract templates: an employment agreement for permanent team members, a software development agreement for project-based work, and a services agreement for independent professionals. Each template should have a clearly defined use case and should not replace a legal assessment of the specific circumstances.

FAQ: Frequently Asked Questions About Hiring Software Developers

Can I engage a programmer under a civil-law agreement for ongoing work?

A long-term engagement does not automatically create an employment relationship. However, if the developer effectively performs an ongoing job function under the company's direction and follows its internal workplace rules, there is a risk that the relationship will be recognized as employment.

Can a self-employed software developer provide services to a legal entity?

Yes, provided the applicable self-employment requirements are met and the actual services fall within the permitted categories of activity. Before signing an agreement, verify the current permitted activities list and the contractor's registration status.

Do I need a separate agreement to transfer ownership of source code?

Not necessarily. Intellectual property provisions can be included directly in the main agreement. What matters is that they clearly establish the rights to the development deliverables, the transfer procedure and the permitted ways in which the company may use them.

Which is more cost-effective for a startup: a civil-law agreement or an employment contract?

There is no universal answer. An employment arrangement is generally more appropriate for a permanent team member. A civil-law agreement may be suitable for an independent contractor delivering a specific project. You should compare not only the financial costs but also the legal risks and administrative obligations associated with each option.

Can I use one contract template for all developers?

I would not recommend it. Even when developers perform similar tasks, the actual working relationships, contractor status and development arrangements may differ considerably. A single universal template can create more problems than it solves.

Conclusion

Properly engaging a software developer is not merely an administrative formality for your accounting or HR department. It is part of your IT business's legal architecture. It determines how your company works with its team, protects its source code, manages intellectual property and reduces legal exposure as the business scales.

At Pactum, we approach legal matters through the lens of actual business operations. We assess working arrangements, help select the appropriate contractual structure, formalize intellectual property rights and build documentation around the needs of the specific product.

If you are planning to hire developers or want to review your existing agreements, book a consultation. It is much better to establish the right legal structure before a dispute arises than to deal with the consequences afterward.

*This article is provided for general informational purposes only and does not constitute individualized legal advice. Laws and regulatory requirements may change. Always verify the current legal requirements and applicable rules before entering into an agreement or making a business decision.*