Restraint
The best system is the smallest one that solves the problem completely. We build fewer moving parts, on purpose.
§ About the practice
Careful engineering, quietly done.
BLOCK AND RESERVE LTD is an independent technology practice. We build, modernise and operate the software and infrastructure that organisations rely on to conduct their business. This page describes who we are, what we believe about our craft, and how we work with the teams that engage us.
§ 01 — Introduction
The company
An independent house of engineers.
BLOCK AND RESERVE LTD was formed to make one kind of work possible: serious, senior engineering delivered by a small team that stays with a project from its first draft to its long-term operation.
We are deliberately compact. Every engagement is led by people who read code, write code and remain answerable for the systems we deliver. There is no delivery layer separating the client from the engineer.
§ 02 — Mission
Mission
To build technology that its operators can trust on ordinary days and rely on during unusual ones — software and infrastructure that behaves predictably under load, is safe to change, and can be understood by the people who inherit it.
§ 03 — Vision
Vision
A working environment in which technology decisions are made with the same care as any other decision that will last a decade — documented, reviewed, and taken by people who will be present when those decisions are tested by real conditions.
§ 04 — Values
Six principles
Legibility
Code, architecture and decisions should be understandable to the next person who reads them. Clarity is a feature.
Accountability
The engineer who designs a system stays close to it. There is no hand-off to a team the client has never met.
Longevity
We build for the second decade of the system, not the first demo. Boring, well-known technology usually wins that argument.
Honesty
We say when we do not know something. We say when a request is a mistake. We are hired for our judgement, not our agreement.
Discretion
Client work is confidential by default. We do not publish case studies, logos or metrics without explicit permission.
§ 05 — Technical philosophy
Technology should be an instrument, not a monument.
We are not sentimental about tools. We prefer boring, well-understood technology executed rigorously to novel technology executed hopefully. The interesting problem is almost never the choice of framework; it is the domain the framework is being asked to model.
Where new tools genuinely earn their place — because they reduce complexity, remove a whole category of failure, or make a system measurably easier to operate — we adopt them, deliberately and with a written justification.
§ 06 — Client partnerships
We work with clients, not for them.
The engagements that go well are the ones in which the client treats us as a partner: reading the same documents, arguing about the same trade-offs, sharing the same on-call rotation when the time comes. Our best clients are technically curious and organisationally patient. We look for that pairing.
§ 07 — Quality standards
Reviewed
No engineer merges their own work into production. Peer review is applied to code, to infrastructure changes, and to architectural decisions alike.
Tested
Automated tests are written alongside the code, not after. Every deploy runs the whole suite. Every critical path has an end-to-end test.
Documented
Every system is delivered with an operator's runbook. Every decision of consequence is recorded so the next engineer does not have to guess.
§ 08 — Security & confidentiality
Confidentiality is a working discipline.
Every engagement begins with a written agreement covering data handling, credential management and disclosure. Access is granted on a least-privilege basis, scoped to the specific systems in play, and revoked promptly at the end of an engagement.
We do not publish the names of our clients or the details of their systems. When a case study would serve the wider engineering community, it is published only with explicit written permission and only after any sensitive detail has been removed.
§ 09 — Delivery methodology
A method built around short cycles.
We plan in weeks, not quarters. Each iteration produces something a client can inspect: a working slice of software, an updated architecture document, a benchmark against a target, or an operational rehearsal.
The rhythm is straightforward: a short review at the beginning of the week to agree on what matters, focused work in the middle, and a written note at the end summarising what was decided, what was built, and what remains open.
§ 10 — Long-term perspective
The second decade of the system.
A production system is not finished at launch. It has to be upgraded, migrated, audited and eventually decommissioned. We design for that entire lifespan, not for the demo.
That means: portable data formats, documented interfaces, standard deployment patterns, and no hidden dependencies on a single vendor or a single person. The system should be as easy to hand over as it was to build.
§ 11 — Contact
Correspondence
Speak to the practice.
- Company
- BLOCK AND RESERVE LTD
- [email protected]
- Website
- blockandreserve.com
- Working language
- English