About
We take problems that are not fully worked out yet, and turn them into software.
Almost nothing arrives finished. A marketplace turns out to be a trust problem before it is a catalogue problem. School fees turn out to be a question about what to do when nobody can tell which child a payment belongs to. A naming system turns out to be a question about whether the premise it was built on holds at all.
CodeLabPros is founded and led by Nicholas Munene
What the work is
So the work is rarely writing the thing that was specified. It is working out what the thing actually has to do, modelling the difficult part, building it, testing it against reality, and changing the design when reality disagrees.
We take that across the whole of it, not the convenient half. Product logic, architecture, database, backend, interface, integrations, payments, deployment. Not because a generalist is better than a specialist, but because the interesting failures in this kind of software happen in the joins, and someone has to own the joins.
Where we are careful
Anywhere the software has to make a consequential decision on somebody else’s behalf: money, access, identity, a state that cannot be un-entered. A wrong answer there cannot be fixed by shipping an update next week, because by then the money has moved, or a family has been told something untrue, or someone has built further work on top of a bad conclusion.
That is why payments and escrow are the strongest evidence on this site. Not because payments are the subject, but because they are the least forgiving place to demonstrate the point.
How we work
What comes out of that is a set of habits rather than a favourite framework. Measure rather than guess, and where the number will be shown to someone who might disagree, use a tool they already trust instead of one we built. Keep what we checked separate from what we assumed, in writing, because after a week the two feel the same. Decide what would make us stop before we know the answer. And when a wrong guess would land on someone who did nothing wrong, ask a person instead of guessing cleverly.
The best evidence that we actually work this way is not a project that went well. It is the piece of research where we set out eleven theories, went looking for evidence against all eleven, and published the seven that turned out to be wrong, several of which had looked right at the time. And a product whose first proper run showed the idea behind it was mistaken, where we changed the design to match the finding instead of shipping anyway. The whole method is written down.
What we build with
Mainly Python and TypeScript, usually with PostgreSQL, and we write things down. The list below is what we reach for, not what we are limited to. The tool has never been the interesting part of any of this.
- Languages
- Python · TypeScript · JavaScript
- Systems
- Next.js · Node/Express · PostgreSQL · MongoDB · Docker
- Payments
- Mobile money — checkout, collections, consumer and business payouts
- Practice
- mypy --strict · import-linter contracts · Postgres RLS · TDD
Where to find us
If you have something that needs building, or something already running and going wrong, tell us about it.