01 / How we workTicket · test · build · merge
Taste you can't automate. Speed you can.
Our speed comes from discipline: written tickets, tests that fail first, a time box for every ticket, review on every change and one merge owner. We use AI tooling to move faster on the repetitive parts, and these rules are what make that fast and safe.
These are our working principles, not our playbook. We don't publish prompts, internal tools or anything about unreleased products.
02The flow
From ticket to main
Read it from the ticket. An engineer writes it and a failing test proves it. We build, AI-assisted, until the test passes or the time box runs out. Premerge runs every test, an engineer reviews the change, and one merge owner lands it on main. People sit at both ends.
03Principles
Eight rules we keep
Write the ticket first
Every change starts as a short written ticket: what changes, which files it may touch, and which tests prove it. If a ticket needs a fact nobody wrote down, the work stops and we ask.
Tests before code, and they must fail
We write the tests first and run them to watch them fail. A test that has never failed has not proved anything.
Frozen tests
Once a test is merged, later work cannot quietly rewrite it to fit new code. When 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 few attempts, a few dollars of tooling and a couple of hours. When the time box runs out, we stop and write down what blocked it, and usually the fix is a clearer ticket. We bring in a stronger model only when a ticket needs it.
Guards that can fail
Every check in the toolchain has a test that feeds it a mistake and expects a refusal. A guard that cannot fail looks exactly like success.
One merge owner
Two builds can run at once, on tickets that do not share files. One queue merges, one branch at a time, and refuses anything behind main.
People own taste and approval
We use AI tools; they do not invent copy, colours or rules. Engineers decide what to build, review every change, approve anything that changes a rule or moves money, and check every screen by eye.
Say only what is built
Our pages describe what exists today. When something is planned, we say planned. When it is not live, we say not live.
04Read more
The longer version
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.
One ticket from start to merge, and the engineering rules behind it. Tests first, frozen tests, time boxes, guards that must fail, review and one merge owner.