Legacy systems under load
Software originally designed for a smaller organisation is now supporting the whole business. It works, but it groans. We stabilise it, document it, and modernise it in place without stopping the line.
Volume 01 — The Engineering Register
BLOCK AND RESERVE LTD is an independent technology practice. We design, build and operate the software, infrastructure and security systems that organisations depend on every working day — carefully, quietly, and for the long term.
Reserved for

§ 01 — The house
A note from the practice
We are a small, senior team of engineers, architects and consultants working under a single roof. Each engagement is led by people who write code, review code, and remain accountable for the systems we deliver long after they enter production.
Our name is deliberate. Block refers to the units of infrastructure — servers, services, contracts, ledgers — that make a modern business function. Reserve is the discipline of leaving margin: margin for load, for change, for the unforeseen. Together, they describe how we work.
We do not chase trends. We do not resell hardware. We take on a small number of engagements at any time so that every one of them receives the attention it needs.
§ 02 — Capabilities
Twelve disciplines
Custom software architecture and engineering
Web and mobile application development
Enterprise systems and back-office platforms
Cloud infrastructure design and operation
Cybersecurity, hardening and incident response
System integration and middleware
Business process automation
Data platforms, warehousing and analytics
API design, versioning and integration
Infrastructure modernisation and migration
Technical consulting and architecture review
Ongoing technical support and maintenance

§ 03 — Problems we take on
What clients bring us
Software originally designed for a smaller organisation is now supporting the whole business. It works, but it groans. We stabilise it, document it, and modernise it in place without stopping the line.
Information lives in twelve spreadsheets, three databases and a filing cabinet. Decisions are slow because nobody trusts the numbers. We build reliable data pipelines and clean, queryable warehouses.
Access is loosely controlled, secrets are shared informally, and there is no incident playbook. We introduce least-privilege access, encrypted operations, audit trails, and rehearsed response procedures.
Skilled staff spend their days re-typing figures between systems. We identify the highest-value processes and automate them cleanly, with monitoring and human oversight built in.
The cloud bill grows every month and nobody can say precisely why. We instrument workloads, remove idle infrastructure, and rebuild the parts that were designed for a different scale.
The roadmap is longer than the team can deliver. We plug in as a senior engineering partner: writing code, reviewing pull requests, and mentoring rather than replacing your in-house engineers.
§ 04 — Sectors
Where we work
Our engagements cluster in industries where reliability, security and long time-horizons matter more than novelty.
Financial services & fintech
Insurance & risk
Healthcare & life sciences
Logistics & mobility
Industrial & manufacturing
Energy & utilities
Public sector & regulated bodies
Retail & e-commerce operations
Professional services
Media & publishing platforms
Property & construction technology
Education & research
§ 05 — Software
How we build

Small commits. Reviewed code. Thorough tests. Deployments that can be reversed in one command. We build systems that are boring to operate, because boring is what production software is supposed to feel like on a Tuesday afternoon.
§ 06 — Cloud & Infrastructure
Built for uptime
Every environment we design is expressed as code, version-controlled, reproducible, and instrumented from the moment it is provisioned. Nothing is configured by hand and forgotten.
§ 07 — Security
Posture, not paperwork
We assume the environment is hostile. That assumption drives every decision we make about identity, transport, storage, deployment and observability. We prefer boring, well-understood controls executed consistently over novel controls executed once.
Least
privilege access, revoked on offboarding
Encrypted
in transit and at rest, by default
Audited
structured logs, retained and searchable
Rehearsed
incident playbooks, tested quarterly
§ 08 — Integration & automation
Systems that speak

Most operational pain is not caused by any single system failing; it is caused by systems that do not talk to each other properly. We build the middleware, the APIs, the event streams and the automations that turn a portfolio of tools into a coherent whole.
§ 09 — Method
How an engagement moves
Phase 01
One to three weeks of structured investigation. We read the code, interview operators, map data flows, and produce a written architecture brief before any implementation begins.
Phase 02
We propose the smallest viable design that solves the problem completely. Trade-offs are made explicit; the option we did not choose is documented alongside the option we did.
Phase 03
Short iterations, reviewed pull requests, thorough tests, continuous delivery to a staging environment your team can inspect at any time.
Phase 04
Load testing, failure injection, security review, and a written runbook covering every operational scenario we can reasonably foresee.
Phase 05
A defined support arrangement that keeps us close to the system while transferring ownership cleanly to your team on a timeline you set.
§ 10 — Technology
Working stack
Languages
Frameworks
Data
Platforms
§ 11 — Standards
Principles of practice
Quality is not a stage of the project — it is the way each hour of the project is spent.
Every architectural decision is recorded in writing. Every system we deliver has a runbook. Future engineers should never have to guess.
No single engineer merges their own code into production. Peer review is a discipline, not a formality, and we practise it inside our own team as well.
Every change we ship can be undone in one command. If it cannot be undone, we build the migration path back before we build the migration path forward.

§ 12 — Reasoning
Why we are engaged
We take on few engagements at once
So the senior team is genuinely on your project
We write things down
So decisions survive the people who made them
We measure what we ship
So performance and cost are observed, not assumed
We hand off, not hostage
So your team can operate the system without us
We reserve capacity
So we can respond when something is genuinely urgent
We invoice for time, not tickets
So we can slow down when a decision requires care
§ 13 — People
Every engagement is delivered by senior engineers who remain part of the project from discovery through operation. There are no hand-offs to a delivery team you have not met.

§ 14 — Questions
Frequently asked

§ 15 — Correspondence
We reply to every serious enquiry, whether it becomes an engagement or not. A short note describing the situation you are working on is enough for a first conversation.