Build-Operate-Transfer gives companies in the UAE a dedicated software team without hiring it first: we recruit the team to your brief, run it under contract, and you can take the engineers we recruited in-house when the contract ends. Delivery starts before you have built a hiring, HR and payroll function, and the option to employ those engineers yourself stays with you.

What is Build-Operate-Transfer for a software team?

Quick answer: Build-Operate-Transfer (BOT) gives you a long-term software team without hiring it first. We recruit a dedicated development team to your brief, and you approve every person. We run it under contract, handling HR, payroll and replacements while it works only on your product. When the contract ends, you can take over the engineers we recruited for you, on terms agreed up front. Our delivery lead and QA stay with our core team, and hand over the process and documentation.

Ask how BOT works for your team →

What waiting costs you

A team of your own starts long before the first commit. You need a recruiting process, an employer where the people sit, payroll, HR and someone to run it all. In the UAE, a developer who already has a job serves a notice period of 30 to 90 days before joining you, under Article 43 of the Labour Law (u.ae), and our staff augmentation vs in-house breakdown adds up the rest. Handing the work to an outside vendor for good is quicker, but the knowledge then lives with them. A BOT model sits between the two: delivery starts under our contract, and the engineers can join your company later.

How a BOT team gets started

  1. You send a role brief. Roles, skills, seniority, working hours, languages, and where you want the team to sit for the long term. That last point matters more for BOT than for any other model, because it decides who employs the engineers after the transfer.
  2. We recruit to your brief. We source candidates from the market for each role and screen them: a technical interview with a senior Flojics engineer, a practical assessment relevant to the role, and an English check, plus Arabic where your product needs it.
  3. You interview and choose. You meet the shortlist, can set your own technical task, and approve every person before they join.
  4. Contract and onboarding. Your NDA first if you want one, then the master agreement and statement of work, with the transfer terms written in from day one. The team gets named accounts in your tools and repositories, and the first sprint starts.

Build, Operate, Transfer: who does what, and what you decide

Each phase ends with a decision that belongs to you. Take this table to the people who will sign off the team.

Phase What happens Who does what What you decide at the gate
Build We recruit the team to your brief and bring it into your tools, repositories and rituals We source, screen and shortlist. You interview and approve every person Is the team the right shape? Confirm the roles and seniority before the first sprint, or ask us to recruit again for a role
Operate The team works only on your product, under a long-term contract You own the backlog and accept the work. Our delivery lead runs the team’s process. We handle HR, payroll and replacements Is it delivering? Judge each sprint demo and the monthly written report, and resize the team through the contract
Transfer When the contract ends, you can take over the engineers we recruited for you The engineers you keep join your company, or an employer you choose, on the terms agreed at the start. Our delivery lead and QA stay with our core team, and hand over the process notes, documentation and anything still in our name Do you take your engineers in-house, and which of them? Decide inside the agreed notice period, so the handover runs to plan

What to agree before you start

The transfer goes smoothly when it is settled on day one, not in the last month. Put these in the contract:

  • The term: how long the contract runs before the transfer option applies.
  • Transfer conditions: what the transfer involves and what, if anything, it costs.
  • Notice: how much notice each side gives before the transfer or the end of the contract.
  • The future employer: your own entity in the country where the team sits, or an employer you choose.
  • Which roles transfer: the engineers we recruited for you, and which of them you plan to keep. Our delivery lead and QA stay with our core team.
  • Hardware and accounts: who owns the laptops and licences. Keep repositories and tool accounts in your company’s name from the start.
  • Knowledge transfer: documentation written into your repositories as the work happens, plus a handover plan for the final weeks, in which our delivery lead and QA hand over the process and documentation.
  • Code and IP: when they pass to your company. With us, that is at the end of the contract term or project, once it is completed and paid.

On data, we design for UAE PDPL, Saudi PDPL and PIPEDA, and agree data rules with you before access. The contract runs from our headquarters at Dubai Digital Park, and where the recruited team works is part of the brief you approve.

Send us a role brief. The roles, skills, seniority, working hours and where you want the team to sit. We reply with how we would recruit for it, who you would interview and when the team could realistically start. Ask how BOT works for your team →

Not ready for a call? Ask for our company profile and we’ll send it to you. It sets out the four ways to work with us, from one developer to a team whose engineers you can take over.

Is BOT the right model for you?

BOT suits work you expect to run for years: a funded startup building its own product team, or an enterprise planning a long-term product line or its own offshore hub. It is not the quickest route for a short job. If you need one or two developers inside a team you already run, staff augmentation fits better. If the scope is fixed, project delivery does. If you want a long-term team but not the transfer, read how a dedicated development team for enterprises works. You can compare the four ways to work side by side, or see how we set up dedicated teams in Dubai, from vetting to onboarding.

In practice: engineers inside a client’s own team

BOT is an option we offer on dedicated-team contracts. The closest public example of our engineers working inside a client’s team is ButlerFM, facility management software for cleaning businesses. Office staff run properties, employees, supplies, work orders and reports from a web dashboard, and field staff use the mobile app for their tasks, daily checklists and QR code check-ins. Our engineers joined ButlerFM’s own team. That engagement was team extension, not BOT, but the daily work is the same: engineers inside your product team, building what you rank first.

On a dedicated team, two of our pillars carry most of the weight:

  • Transparent delivery. Sprint demos with your product owner, and a monthly written report on work delivered against plan, open risks, and changes to people and access.
  • Independent QA. The person testing the work did not write it, so quality never rests on the team checking itself.

Both live in your tools rather than ours, so the reports, test plans and history stay with your product after the transfer.

Plan your team with us. Ask how BOT works for your team → We ask about your goal, what you use today, your timing and who else should be involved. You leave with clear next steps. The call commits you to nothing, and we sign an NDA first if you want one.

FAQ

Frequently asked questions

How much does a Build-Operate-Transfer team cost?

A dedicated team is billed as a monthly fee per team under a long-term contract. The fee depends on the roles, seniority and team size, and the transfer terms sit in the same contract. We don't publish rates because every team is recruited to its own brief. Your figure is agreed in your proposal, so you see the full picture, transfer terms included, before you sign.

How long before we can take our engineers in-house?

The term is agreed in your contract, and the transfer option applies when it ends. Set it around your own plans: when the product will be stable, and when your entity and managers will be ready to take the engineers on. The term and the notice are written in on day one, so you can plan the handover from the start.

Who controls the team during the contract?

You do, on everything that shapes the product. You approve every person before they join, own the backlog and accept the work. Our delivery lead runs the team's day-to-day process, and we handle HR, payroll and replacements. You see the work in every sprint demo and in a monthly written report, so nothing happens out of sight.

What happens if someone leaves or isn't the right fit?

During the contract, replacements are ours to handle. We recruit to the same brief, and you interview and approve the new person as you did the first time. Because code and documentation live in your repositories, the knowledge stays with your product when a person changes.

Who owns the code, and how is our data handled?

The code and IP pass to your company at the end of the contract term or project, once it is completed and paid, as written in your agreement. Until then, the code, pipelines and documentation can sit in your own repositories and accounts, so you see every commit as it is written. We sign your NDA first if you want one. Which environments and data the team can reach is agreed with you before anyone gets access.

What if we decide not to take the engineers over?

Taking the engineers over is your option, not an obligation. If you don't use it, the contract ends on its agreed notice terms. Your repositories, documentation and accounts are already in your name, and the code and IP pass to you once the contract is completed and paid, so you are not locked in either way.

Plan your team with us

Send us the roles and timing. We source the people, you interview them and choose who joins.