How we ship fast without shipping a mess
How Henaho Labs ships fast with a small team. Written tickets, tests first, review on every change, and where AI tooling fits inside that discipline.
Henaho Labs is a product studio. We build for clients, and we build our own products: a life sim of everyday Nigeria, a screen recorder for the Mac, and a marketplace built around protected payments. We are a small team, and we move fast.
That speed comes from how we work, not how many of us there are. We write down what each change must do, prove it with a test before it exists, keep every piece of work small, and review every change before it lands. We use AI tools to move faster on the repetitive parts. The discipline is what makes that speed safe.
What people do, and what the tools do
Engineers own the work. We decide what to build and in what order, design it, set the architecture, write the tickets and the tests that prove them, review every change and decide what merges.
Our AI-assisted tooling takes the repetitive parts in between: drafting code against a ticket, running the checks, retrying until a test passes. It works one ticket at a time, inside the files and the time box we give it, and it hands the branch back to us.
Some things stay with people, always:
- Deciding what to build, and in what order.
- Writing down the rules each product must follow.
- Choosing copy, colours and type. Our tools use what the design system and the ticket give them. They don’t invent words or values.
- Approving anything that changes a rule, a frozen test or how money moves.
- Looking at the result. If it is on screen, a person checks it by eye.
That split matters more than any tool. A tool can propose. An engineer approves.
Small tickets
Every change starts as a written ticket. A ticket says what to change, which files the change may touch, and which tests prove it works. If a ticket needs a fact nobody wrote down, the work stops and we ask. Nobody guesses.
Tickets are small on purpose. A small ticket fits in one session, one branch and one review. When a ticket grows past its limit, we split it before anyone writes code.
Tests before code
The tests come first, and we run them to watch them fail. Then comes the least code that makes them pass. A test that has never failed hasn’t proved anything.
Once a test is merged, it is frozen. Later work can’t quietly rewrite it to fit new code. If behaviour really changes, the old test is retired by name, with the owner’s yes.
A time box for every ticket
Each ticket gets a time box: a few attempts, a few dollars of tooling and a couple of hours. If it runs out, the work stops and what blocked it gets written down for an engineer to read. Pushing on past that point just makes more code to throw away. Usually the fix is a clearer ticket.
We start with lighter tooling and bring in a stronger model only when a ticket needs it.
One merge owner
Two builds can run at once, on tickets that don’t share files. Only one session merges. Merges happen one at a time, through one script, and that script refuses a branch that is behind main or changes a protected file without approval.
It sounds slow. It isn’t. A queue of small, checked, reviewed branches moves faster than a pile of big ones that conflict.
What this buys us
The discipline cuts the time between a written ticket and tested, merged code, and our tools cut it further. The time we save goes into the parts that need people: deciding, designing, reviewing, and checking how things feel.
It also changes what we write down. Tools copy whatever patterns they see, so the rules have to be written, short and current. Our engineering conventions fit on one page. Every repo has an AGENTS.md that points to them, and every pull request is reviewed against those conventions before it is reviewed for features.
What it doesn’t buy us
No tool makes a product good on its own. A tool doesn’t know that a button feels slow, or that a sentence sounds like an ad. It doesn’t know which Lagos joke lands. Taste, architecture and product sense are ours.
Nor does it remove the boring work. Someone has to write the tickets, keep the rules current and read every diff. That someone is us, and we think the work is worth it. It is how a small team ships fast without shipping a mess.
Where to go next
If you want the detail, read Tickets, frozen tests and loop budgets. It follows one ticket from start to merge. The short version of our principles is on How we work.