The Batunet Engineering Method.
How we think — from the first question to operations years later. Not a project process, but a technical operating model.
Six convictions that hold in every phase.
Understand before building. Expensive decisions first. Prove the hard path first. Operate what we build.
Understand before building
Not a line of code until the problem is defined and its success is measurable. The most expensive mistake is a well-built solution to the wrong problem.
The expensive decisions first
Few decisions are expensive to reverse. We make them deliberately and write down the why — before the cheap decisions use up everyone's attention.
Reversibility over prediction
We don't predict the future; we keep change cheap. Every important decision is classified as reversible or not.
Prove the hard path first
Risk is eliminated at the start, not discovered at the end. The riskiest path runs end to end before the simple features are built.
Fail on purpose
We design for failure and rehearse it before production does. A system whose failure modes are unknown is not finished.
Operate what we build
Operability is a design decision from day one, not a handover on the last day. We build as if we had to run it ourselves for ten years.
Seven phases. Frame to Operate.
Each phase is a distinct mode of thinking, not a calendar stage — and answers one question before the next begins.
- 01
Frame
What problem are we really solving — and what happens if we don't?
The actual problem, its boundaries and a measurable definition of success are established before any solution is considered.
- 02
Model
Where do this system's real boundaries lie?
The domain is modeled and sliced into contexts — with a precise, shared language.
- 03
Decide
Which decisions are expensive to reverse — and did we make them deliberately?
The load-bearing decisions come first — deliberately and documented, while change is still cheap.
- 04
Prove
Does the hardest path work end to end?
A walking skeleton proves the architecture on the riskiest path — before going broad.
- 05
Build
Is every increment shippable on its own, tested and reversible?
On top of the proven skeleton, the system grows in verifiable, reversible steps — with progress visible every week.
- 06
Harden
How does this system fail — and what happens then?
Failure cases, load and security are tested, not assumed. “It runs” becomes “it holds.”
- 07
Operate
Will someone be able to change this system safely five years from now?
We operate, monitor and keep evolving the system — and keep it understandable and changeable.
Decisions that stay documented.
The method's memory is its decision records (ADRs). Every phase adds to them, and every phase can revise them. An ADR records the context, the options, the decision and its consequences — and whether the decision is reversible.
This preserves not only what a system is, but also why. Where the why survives, a system can be changed safely for ten years. Where it is lost, every change is a risk.
What a decision looks like.
A generic excerpt — with no client context. The format in which we record load-bearing decisions.
- Context
- Payment events are processed with at-least-once delivery. A duplicate delivery must not create a duplicate booking.
- Decision
- Every payment carries an idempotency key. It is checked and persisted in the same transaction as the booking. Known keys are acknowledged as a no-op.
- Consequences
- Duplicate processing is structurally ruled out. The key store grows with throughput and needs a retention policy. Consumers must pass the key along.
- Rejected
- Downstream deduplication by reconciliation — detects duplicate bookings too late.
Let's talk about your project.
No sales team. A direct conversation with the management.
