The short answer
Hiring a development team from us means renting named people by the month, not buying a project. One seat is one engineer, designer or QA who joins your standups, works from your board, pushes to your repository and reports to you. Seats are billed per person per month at , depending on seniority and how many hours a week you book, and they run month to month with 30 days notice on either side.
We work from Kampala, which sits at UTC+3 and never changes its clocks. That gives you an almost identical working day with Europe and the Gulf, most of the day with the UK, and roughly five hours of your morning if you are in New York. Everything the team produces lives in your repository and your cloud accounts from the first commit, so if a developer leaves you keep the code, the documentation and the access, and we put a replacement in the seat with a paid overlap. We have 29 live builds behind us, and when you would rather buy a defined build than a headcount we quote one fixed price before work starts.
Overlap hours with the US, the UK and Europe
Distributed teams fail on calendars far more often than they fail on code. So we agree the shift before anyone starts and write it into the agreement, rather than leaving it to goodwill and time zone maths at 7am.
Kampala is UTC+3 all year round. Your side is the part that moves, because most of Europe and North America change clocks twice a year, so the gap narrows or widens by an hour in spring and autumn. Here is what the shift actually looks like.
- Europe and the Gulf. One to two hours apart. A 10:00 to 19:00 Kampala shift is 08:00 to 17:00 in Berlin, Paris or Amsterdam, and Dubai and Riyadh are effectively the same day. Full overlap without anyone working odd hours.
- United Kingdom. Two to three hours apart. An 11:00 to 20:00 Kampala shift covers 08:00 to 17:00 in London through both winter and summer.
- US East Coast. Seven to eight hours apart. A 13:00 to 22:00 Kampala shift gives you 09:00 through early afternoon in New York, so your whole morning, every day, including standup and a live handover before the team logs off.
- US West Coast. Ten to eleven hours apart. We can hold roughly three hours of your morning, and that is the honest ceiling. Anyone promising full Pacific cover from East Africa is describing a permanent night shift, and night shifts burn people out, which costs you the person you trained.
Whichever shift you pick, you get a written standup in your own channel each working day and a demo of running software each week, not a status report. Public holidays on our side are sent to you the month before, never on the morning.
What a dedicated seat costs, and why it costs less
The price gap between a Kampala team and a London or Austin team is an operating cost gap, not a quality gap. Office rent, salaries measured against local living costs, and no recruiter fee baked into every hire. The tooling is identical: React and Next.js, Node and Laravel, Flutter, PostgreSQL, AWS and DigitalOcean, reviewed through the same pull request discipline your last agency used. We set out the full argument in why outsource software development to Africa.
You are usually choosing between three options, and the honest comparison looks like this.
| How you add capacity | Monthly cost per person | What you actually get |
|---|---|---|
| In-house hire in the US, UK or EU | Salary, payroll taxes, equipment and recruiter fee, typically three to five times a Kampala seat | Full control and full commitment, plus a hiring cycle of two to four months and a redundancy cost if the work dries up |
| Marketplace freelancer | The lowest hourly rate available, with no floor and no ceiling | A fast start, then no cover, no documentation, and nobody to call the week they stop replying |
| Dedicated seat with us | per person | A named engineer on agreed overlap hours, code in your repository, a second reviewer on every system, and a replacement if they leave |
| Fixed scope project instead of a seat | One fixed quote agreed before work starts, paid 50/25/25 | A defined build with a number you can put in a budget, and no headcount to manage |
We are not the cheapest line on that table and we do not try to be. A marketplace freelancer will always undercut a team that carries cover, documentation and a delivery lead. What a seat buys is continuity at a price that is not a Western agency's. If you want that trade off in full, read freelancer vs agency.
What happens when someone leaves
This is the real question behind hiring remote developers, and most agency pages walk straight past it. People move on. Ours have families, other offers and lives of their own. The plan cannot be that nobody ever leaves. The plan has to be that it does not cost you a sprint when they do.
Nothing lives in one person's head
- The repository is yours, on your GitHub or GitLab organisation, from the first commit. We are collaborators on your account, never the owner of your code.
- Hosting, domains, databases and third party services are registered in your name and billed to your card. We hold access, not ownership.
- Every system has a second reviewer. Pull requests are read by someone other than the author, so at least two people have read every part of what you own.
- Each project carries a written handover file: architecture notes, the list of environment variables with the values kept in your own secret store, deploy and rollback steps, scheduled jobs, and every external service the build depends on.
- Recorded walkthroughs of deploy and rollback, so a new developer can watch how it is done instead of guessing.
The replacement
If we move someone off your seat, you get 30 days notice and the incoming developer overlaps with the outgoing one for two weeks at our cost, not yours. If you end a seat, the same 30 days applies and we hand over properly: access transferred, documentation brought up to date, one final walkthrough call. No exit fee and no arguing about who holds the keys.
The roles you can put in a seat
Most clients start with two seats, usually a senior full stack engineer plus either a designer or a QA, and grow once the pace is proven rather than before.
- Full stack engineers. React and Next.js at the front, Node or Laravel behind it, PostgreSQL or MySQL underneath.
- Mobile engineers. Flutter or React Native, including store submission and release management for both the App Store and Play.
- Integration engineers. Payments and third party work: Stripe, Paystack, Flutterwave and mobile money on the African side, plus the CRM, accounting and logistics APIs your operation already runs on. See API development and integration.
- QA. Test plans, a regression pass before each release, and bug reports someone can actually reproduce, so your engineers are not the ones discovering faults in production.
- Product designers. Figma, a real design system, and front end that matches the file instead of approximating it.
- Delivery lead. Usually a part seat on larger teams. Runs standups, keeps the board honest, and gives you one person to call when you do not want to chase four.
- Growth seats. If the shortage is marketing rather than engineering, the same model covers a Google and Meta ads manager. We manage six figures of client ad spend, and everything we build ships SEO and AI search ready.
If you would rather hand over a defined build than manage people at all, that is custom software development services, quoted as a project instead.
How the first month works
No long procurement process and no discovery invoice before you know whether you like the people.
- A short call, then a written role brief. Stack, seniority, hours, overlap window, and what the person owns in their first 90 days. If we cannot staff it properly we say so on that call, rather than taking the money and learning on your product.
- Profiles, not CVs. You see the actual people, what they have shipped, code we are permitted to show, and a call with each one before you agree to anything. You interview them and you can say no.
- A real first fortnight. The first two weeks are paid work on your actual backlog, not a test task. If the fit is wrong you stop there and you keep everything produced.
- Onboarding is on us. Reading your codebase, setting up locally and learning your domain is our time, not your billed hours.
- Monthly invoice, monthly review. One invoice per seat, and one call at the end of each month covering velocity, blockers, and whether the shape of the team is still the right shape.
Seats are paid monthly in advance. Project work is priced differently: a fixed quote agreed before anything begins, then 50% to start, 25% at the agreed midpoint and 25% on delivery.
When a team is the wrong answer
It costs us money to say this, so take it as honest. A dedicated development team earns its keep when the work is continuous and the requirements keep moving: a product with a live roadmap, an internal system whose users keep asking for more, a platform in a market you are still learning. The people build context over months, and context is most of what you are paying for.
It is the wrong answer when the brief is finished and unlikely to change. If you can describe the whole thing in a document and would rather have a number than a headcount, buy the build, not the bench. The same goes for a first version you are using to test an idea, where MVP development on a fixed quote gets you to a decision faster and for less.
The tell is simple. If your engineering questions this quarter are about scope, take a fixed quote. If they are about capacity, hire the seats.
Frequently asked questions
How much does it cost to hire a development team?
Seats are billed per person per month at , depending on seniority and how many hours a week you book. Two seats is the most common starting point. If you would rather buy a defined build than headcount, we quote one fixed price before work starts, paid 50/25/25.
Can your developers work US or UK hours?
Yes, within honest limits. Kampala is UTC+3, so a shifted start covers a full London working day or your entire New York morning. Full US West Coast cover would mean a permanent night shift and we do not sell that, because people leave night shifts and then you lose the developer you spent months training.
Who owns the code and the accounts?
You do, from the first commit. The repository sits on your GitHub or GitLab organisation, and hosting, domains and third party services are registered in your name and billed to you. We work as collaborators on your accounts, so there is nothing to reclaim if we part ways.
What if the developer you assign is not a good fit?
You interview each person before they start, and the first two weeks are real work on your product rather than a trial task. If the fit is wrong you stop there, keep everything produced, and we either propose someone else or step away.
Can I start with one developer and add more later?
Yes. Most teams start with one or two seats and scale after the first delivery lands. Adding a seat usually takes two to three weeks depending on the stack, and reducing a seat takes 30 days notice.