Henaho LabsStart a project

01 / ServicesBuild · Accelerate · Advise

We build software for other teams the way we build our own: small written slices, tests first, an engineer reviewing every change, and AI-assisted tooling for the repetitive parts.

Start a projectSee the three offers

Offer 01 / 03Product design and engineering

Product design and engineering, one working slice a week.

We design and build the product with you: web, mobile with Capacitor, desktop with Tauri, and backends in Go, Rust or TypeScript. Every week ends with a thin slice through every layer that you can click, not a status report.

  • A working slice every week
  • Design and code in your repo
  • Tests that come with the code
  • Docs and an AGENTS.md at handover
Start a Build project

Fig. 01An example plan, slice by slice

Example plan · a booking appWeek 6 of 6

  1. Week 1Sign-in works
  2. Week 2First booking
  3. Week 3Payments, sandbox
  4. Week 4Admin view
  5. Week 5Reminders sent
  6. Week 6Launch checklist

Offer 02 / 03Our engineering discipline

Our engineering discipline, set up inside your team.

We set up the engineering discipline that lets your team ship faster with AI, safely: the one we run our own products on. Written tickets. Tests that fail first and then freeze. A time box for every AI-assisted build. Review on every change and one merge owner. Your team runs it; we set it up and coach.

  • Ticket and test templates for your repo
  • AI-assisted tooling set up in your CI
  • Time boxes and escalation rules
  • Your engineers coached to run it
Bring it to your team

Fig. 02The loop, running

Simulation · not client data

Tickets written by people

  1. T-110
  2. T-111
  3. T-112
  4. T-113

Builds AI-assisted · 3 running

  1. build 1 T-109 test fails 2/5
  2. build 2 T-107 test passes 4/5
  3. build 3 T-108 test fails 3/5

Merge queue one owner

  1. empty

main T-104 landed

Merged to main
6
Tests frozen
9
Attempts
27
Back to a person
0
Run more builds in parallel and the work spreads out, but there is still one merge queue and one engineer who owns it. A ticket that runs out of its time box goes back to a person, not round again.

Offer 03 / 03A second pair of eyes

A second pair of eyes, in writing.

Architecture and code review, technical due diligence, product and UX audits, and fractional technical leadership. You get numbered findings ranked by risk, and the fixes we would make first.

  • Architecture and code review
  • Technical due diligence
  • Product and UX audits
  • Fractional technical leadership
Ask for a review

Fig. 03A review, marked up

httpswebhookWeb appbrowserAPI2 instancesPostgresprimaryPaymentswebhooksJob queueretries: foreverWorkeremails · receipts1234
Example review · an invented system, not a client's
  1. 1High riskThe payment webhook is not idempotent.A retried event records the same payment twice.Fix Store each event id and ignore repeats.
  2. 2High riskSessions live in API memory.With two instances, half of all requests look logged out.Fix Move sessions to Postgres or signed tokens.
  3. 3Medium riskFailed jobs retry forever.No dead-letter queue and no alert, so a bad receipt loops quietly.Fix Cap retries, park failures, alert a person.
  4. 4Medium riskNo test covers token refresh.The path every signed-in user hits can break without anyone seeing.Fix Add a failing test first, then freeze it.

How an engagement runsFour steps

Nothing starts without a written scope.

  1. 01

    Intro call

    What the problem is, and whether we are the right people for it.

    Notes you can keep

  2. 02

    Written scope

    A fixed price for a defined slice, or a monthly retainer. Nothing starts without it.

    scope.md

  3. 03

    Weekly slices

    Each week ends with something you can click, on a link you can share.

    A preview link

  4. 04

    Handover

    Your code, your docs, and an AGENTS.md, so your engineers and their tools can carry on.

ProofOur own products, as they are today

We build our own products the same way.

No client logos or testimonials here. What we can show is what we build ourselves, each with its real status today.

Questions

Before you write.

01How do engagements work?

Two ways. A fixed price for a scoped slice of work, agreed in writing before we start, or a monthly retainer for ongoing building, delivery or advice. Either way, the written scope says what you get each week.

02Who owns the code and the IP?

You do, from the first commit. We work in your repositories and accounts wherever we can, and everything we make for you is yours at handover.

03Which timezones do you work in?

We work remotely and mostly in writing. The written scope fixes the overlap hours and the slot for the weekly demo, so you know when to expect us.

04Will you sign an NDA?

Yes, on request. If you need one before the first call, say so in the form and we will send it or sign yours.

05How do you use AI on our code?

As tooling, under the same written rules we use on our own products. An engineer writes the ticket and the failing test, AI-assisted work runs inside a time box, and a named engineer reviews and merges every change. We use AI tools; engineers own every decision.

06Can we hire you just to review what we have?

Yes. That is Advise: a written review of the architecture, the code or the product, with numbered findings ranked by risk and the fixes we would make first.

Start a projectReplies from a person

Tell us what you are building.

04 What do you need? Choose one or more

Up to 5,000 characters.

Goes to hello@henaholabs.com. A person reads every message. A bot check from Cloudflare runs when you start typing. Privacy

What happens next

  1. A person reads it, not a sales sequence.
  2. We reply by email, with questions or a time for an intro call.
  3. If we fit, you get a written scope before any work starts.

Rather write directly?

hello@henaholabs.com