Product engineering
A demo is the twenty per cent of a product that is easy to show. We are usually hired for the rest.
What this is
The build, including the parts nobody demos.
Every product has a surface that gets screenshotted and a body that decides whether it survives. The surface is the landing page, the onboarding, the dashboard. The body is what happens when a payment half-completes, when two people edit the same record, when a support agent needs to reverse something a customer did three weeks ago. The second list is longer, is where the cost is, and is almost never in the brief.
We build in a boring stack on purpose. Server-rendered web platforms, a relational database or a structured content store, and as little bespoke infrastructure as the problem allows. Novel infrastructure is a liability you pay for every month in a market where the person maintaining it in two years may not be the person who chose it.
The work includes the screens your own team lives in. An operator console is the most-used interface in most businesses and the least-designed, and the difference between a product that scales and one that stalls is frequently just whether staff can resolve a problem without a developer.
What’s involved
- Web platforms
- Server-rendered applications built to be fast on the connections your users actually have, not the office fibre they were tested on.
- Payment integration
- Mobile money and cards, with the reconciliation, retries, timeouts and partial-failure states designed rather than discovered.
- Identity and verification
- Sign-in, roles, permissions, and document or account checks, including what happens when a check later fails.
- Operator tooling
- The admin, moderation and support surfaces that let a non-developer fix things. Built as a first-class product, because it is one.
How it usually goes
- 01Read what exists
- Existing code, existing data, existing support tickets. The tickets are usually the most honest specification available.
- 02Agree what is out of scope
- Written down. Most disputes about delivery are actually disputes about scope that nobody recorded.
- 03Ship in slices
- Something usable early, then extended. A long build with nothing in production is a long build with no feedback.
- 04Hand over or keep carrying
- Documentation, access, and a named owner. Where we stay on, the runbook still gets written, it is what makes leaving possible later.
What we won’t do
- We will not add a framework because it is new. Choosing technology is a maintenance commitment made on someone else’s behalf.
- We will not build a feature we have argued against without recording the disagreement. You are entitled to overrule us and to have the reasoning on file.
- We will not ship a product with no admin surface and call it finished.
Where we’ve done it
- Business Report
An independent Kenyan business publication, rebuilt as a server-rendered newsroom its editors run themselves.
- Khendo FM
A radio station whose website is part of the transmission rather than a poster for it.
- SpaceYako
A property platform for Kenya, built around a single question: can you believe the listing?
Next
If this is the shape of your problem, describe the part that breaks if it isn’t right.
Get in touch