Method
How we work.
A working set of principles. We revisit them, edit them when reality teaches us a better one, and try to live by them on every engagement. Written in 2026.
Every engineering shop has a public way of describing itself and a private way of working. This page is the second one. We share it because the gap between the two is where most client relationships go wrong, and we'd rather you know what working with us actually looks like before you sign anything.
-
01
Read the problem twice before opening an editor .
Most engineering failure is failure of comprehension, not implementation. We spend the first day of every engagement re-stating the problem in our own words, getting it wrong, getting corrected, restating, until the client says 'yes, that.' Only then do we open a code editor.
-
02
Ship the simplest working system, then earn complexity .
We start with the boring version: a single Postgres table, a cron job, a flat file. We add Redis when measurements demand Redis. We reach for Kafka when measurements demand Kafka. The point is to keep complexity earned, not anticipated. Most systems are slowed by complexity that paid no rent.
-
03
Reliability is a feature, not a phase .
We do not 'add monitoring later.' Logging, structured errors, dashboards, and a runbook are part of the first PR, not the last. A system that breaks at 3am with no one able to diagnose it is worse than no system at all. We instrument first because we plan to be on-call for what we ship.
-
04
Honest reporting beats optimistic estimates .
When something is going to be late, we say so as soon as we know — usually weeks before the deadline, not the day of. When a model is performing worse than the baseline, we say so. We have lost engagements over this and we will lose more. The clients we keep are the ones who needed exactly that.
-
05
Working code over impressive demos .
A demo is a system optimized for the four minutes the camera is on. A working system is optimized for the next four years. We do not ship demos. If you need to be impressed in four minutes, we are probably the wrong shop.
-
06
We instrument what we cannot reason about .
When a system surprises us, we do not guess. We add a log line, a metric, a query, a probe. The cost of one extra observation is paid back the first time it tells us something we did not know. This compounds.
-
07
The interface is the hardest part .
Models are commodifying. Compute is commodifying. The remaining hard problem is making a system that humans can use without a manual, that fails in legible ways, and that respects the operator's attention. We treat the interface — UI, CLI, API contract, error message — as the most important code in the system.
-
08
Long-term over short-term .
We build code we expect to revisit in three years. We pick boring databases, mainstream languages, well-understood file formats. We avoid frameworks that have not yet survived a contraction. The code we ship is the code someone else has to read at midnight under pressure — usually that someone is us.
In closing
We are a small shop. We will not be the cheapest engineering option you find, and we will not be the fastest. We aim to be the one you call when something has to actually work.
— Segun John Oni, Founder & Principal Engineer