Nairobi, Kenya

About Auto Dev Labs

A new company, built by engineers who are not new to this.

We are a Nairobi-based software engineering company. This page sets out who we are, how we work, what we guarantee in writing and how we handle your data — so you can judge us on specifics rather than adjectives.

Our story

Why the company exists

Every engineer here has at least three years of hands-on delivery behind them, across web, mobile, cloud and automation work. For most of that time we took this work on individually and as contractors — good software, delivered, but each of us carrying a project alone.

That model has a ceiling, and clients feel it before we do. A single contractor cannot cover for illness, cannot review their own architecture, and cannot credibly promise to still be reachable eighteen months after launch. The work was sound; the structure around it was not.

Auto Dev Labs is how we now do that work properly: one contract instead of several, shared engineering standards rather than personal habits, code review before anything ships, documented handovers, and someone accountable after launch instead of a freelancer who has moved on to the next thing.

We are a young company and we say so plainly, because the alternative — a borrowed client list — is not a foundation worth building on. Our standards are set out instead: a written scope before we start, a fixed price agreed before any code is written, working software you can open and review as it is built, and a straight answer when something falls outside what we should responsibly take on.

What we are

  • A registered Kenyan company, invoicing in KES or USD
  • An engineering team you speak to directly, with no account manager in between
  • 13 services across design and build, automation, cloud operations and advisory
  • Remote-first, working with clients across Kenya and beyond

What we are not

  • A reseller subcontracting your project to someone you never meet
  • A vendor that keeps your credentials or accounts as leverage
  • A firm that quotes a number before understanding the requirement

The team

A dedicated team of experienced software engineers

We describe our team by the disciplines we can field rather than by individual names. People move between projects and companies; the capability, the standards and the contractual commitments stay constant, and those are what you are actually buying.

Design & build

5 services

Taking an idea or a requirements document through to working, maintainable software.

Automation & intelligence

3 services

Removing manual work and connecting the systems a business already runs on.

Cloud & operations

3 services

Hosting, deploying, monitoring and keeping software running after launch.

Advisory & teams

2 services

Technical direction, and engineering capacity that plugs into your own team.

Reviewed, not solo

Nothing reaches your environment on one person's judgement alone. Code review and a second opinion on architecture are part of how we work, not a premium tier.

Standards over habits

Shared conventions for structure, testing, security and documentation, so the codebase reads consistently regardless of who was assigned to it.

Continuity by design

Work is documented as it is built and more than one engineer knows every project. Your system does not depend on any single person remaining with us.

What we put in writing

Guarantees you can hold us to

Reputation is asserted; terms are enforceable. Every commitment below appears in the statement of work you sign, which means you can hold us to it rather than take our word for it.

A fixed price, signed first

The statement of work lists deliverables, exclusions, milestones and the price. We do not start building against a verbal brief.

The exclusions matter as much as the deliverables. Most disputes in this industry come from two parties reading the same sentence differently six weeks in, so we write down what is not in scope alongside what is. If you later want something on that exclusions list, it is a priced change order you approve — never a silent addition to the invoice.

Your accounts, your repository

We work inside your own source-control and cloud accounts. Nothing has to be migrated away from us at the end, because it was never ours.

If you do not have these yet, we will help you create them in your company's name and add ourselves as collaborators. It is a small step at the start that removes the most common form of lock-in later: the agency that holds the credentials and therefore holds the leverage.

IP yours on payment

All intellectual property in the work transfers to you outright. No licence-back, no per-seat fee, no dependency on a component only we can maintain.

We build on mainstream open-source foundations with permissive licences, and we tell you before introducing any dependency that would carry a recurring cost or a restrictive licence. You should never discover a mandatory subscription after the handover.

NDAs signed individually

We will sign yours or ours, both as a company and by each engineer personally. Access is granted per person and revoked when they leave the project.

A company-level NDA alone is weak comfort when the people with database access change. Every engineer on your project signs personally, access is granted individually rather than through a shared login, and it is withdrawn the day they rotate off.

Working software every week

A weekly demo of something you can open and click, on a URL you can reach. Progress you can verify rather than a percentage in a report.

A percentage in a status report can say anything. A staging URL cannot. This also means problems surface in week two rather than week ten, when they are still cheap to fix and you still have the budget to decide differently.

Handover as a deliverable

Documentation, credentials and a training session are line items in the scope, not favours at the end. You can hire someone else to take over.

Handover is quoted and scheduled like any other milestone, because work that is unpaid and unscheduled is the work that quietly does not happen. The test we hold ourselves to: another competent engineering team could pick this up from the documentation without calling us.

We decline work we should not take

If a project needs deeper specialist experience than we can field, or does not need custom software at all, you hear that on the first call.

Sometimes the honest answer is an off-the-shelf product, a configuration change, or a specialist firm in a domain we do not work in. Saying that costs us one project and is the reason we would be worth calling for the next one.

You can leave cleanly

Give notice and we invoice only delivered milestones, then hand over the code and credentials as they stand. Being easy to leave keeps us honest.

There is no termination penalty and no notice period designed to trap another month of fees. An engagement you can exit cheaply is one we have to keep earning, which is a better guarantee of our attention than anything we could write in a brochure.

Security & data protection

Controls we implement, not badges we display

Kenya's Data Protection Act, 2019 places obligations on you as the data controller. What follows is how we build so those obligations are actually met in the software, rather than asserted in a policy nobody has read.

Encryption in transit and at rest

TLS on every endpoint we deploy, and encryption at rest for databases, backups and file storage. Secrets live in a managed secret store or your cloud provider's vault — never in the repository, never in a spreadsheet.

Role-based access, granted per person

Access is scoped to the role that needs it and granted to named individuals rather than shared logins, so it can be audited and withdrawn. Production access is restricted to the engineers who require it and revoked when a project ends.

Data residency and retention

We agree in the scope where your data is hosted and how long each category is kept, then implement the retention windows rather than leaving records to accumulate indefinitely. Test environments use anonymised or synthetic data wherever the work allows.

Audit logging

Systems we build log who accessed or changed sensitive records and when, because a data protection obligation you cannot evidence is one you cannot demonstrate to a regulator.

Lawful basis and data subject rights

We help you map what personal data a system collects and why, and build the mechanics that let you honour access, correction and deletion requests — the operational side of the Data Protection Act, not just the policy page.

Backups and recovery

Scheduled backups with a defined restore procedure, tested rather than assumed. The recovery expectation is written into the support agreement instead of being discovered during an incident.

We are not a certification body and we do not claim an audit we have not undergone. If your sector requires formal certification or an independent penetration test, we will say so during scoping and help you plan for it. How we handle data on our own site is set out in our Privacy Policy.

How we work

You always know what happens next

The same six stages on every engagement, whether it is a corporate website or a management system. Each one ends with something you can review and approve before the next begins.
  1. 01

    Discovery call

    A free 30-minute conversation about the problem, the constraints and the budget range. If we are not the right fit, we say so on this call.

  2. 02

    Scope & written quote

    We define what the first release includes and excludes, then quote it as a fixed price in a statement of work you can take to procurement.

  3. 03

    Design & architecture

    Screens and data model agreed before the build. Changing a diagram is cheaper than changing a shipped feature.

  4. 04

    Build in increments

    Short cycles with something reviewable at the end of each. You see progress in a working environment, not in a status report.

  5. 05

    Test & launch

    Functional, performance and security checks, a staged rollout with a rollback path, and a launch date agreed rather than announced.

  6. 06

    Handover & support

    Documentation, training and code in a repository you own — followed by a support retainer if you want us to keep it running.

Where we work

Nairobi-based, remote-first, and open about it

We are based in Nairobi, Kenya and registered here. We do not yet have an office you can walk into, so we do not publish a street address we cannot receive you at — you would find the door locked and think less of us for it.

In practice this changes very little. Most projects run remotely with a scheduled weekly call and a shared board you can check at any time. We worked this way for years as contractors, which is why a client in Kisumu, Mombasa or outside Kenya is no harder for us to serve well than one in Westlands.

When a project genuinely needs people in a room — a requirements workshop, a launch, a training session — we travel to you and meet in Nairobi or on site.

Registered in Kenya

Nairobi, Kenya. Working with clients across Kenya and East Africa. Invoicing in KES or USD, with the tax documentation a Kenyan procurement process expects.

Clients across East Africa and beyond

Remote delivery as standard, with on-site sessions when the work calls for it. Time zone overlap is rarely the constraint people expect it to be.

Working hours

Mon–Fri, 08:00 – 18:00 EAT. Support retainers carry a written response commitment; we do not advertise 24/7 cover we cannot honestly staff.

How to reach us

Book a 30-minute consultation in our calendar, call +254 725 173 705, or message us on WhatsApp. Enquiries are answered by an engineer, not a call centre.

Start with a conversation, not a contract

Thirty free minutes on the problem, the constraints and the budget range. You leave with a straight answer on whether we are the right team for it — including when we are not.