Constraints first
Before any architecture is proposed, the constraints are established: existing systems, data ownership, regulatory limits, budget, and the skills of the team who will live with the result.
About the company
An engineering practice
organised around
clarity and continuity.
BOOK A PARTY DJ LTD is an information technology company. It designs, builds and maintains business software, cloud environments and the infrastructure around them, for organisations that need those systems to behave the same way every day.
This page describes how the company works. It contains no claims about size, history, location or clients, because such claims would add nothing you could verify.
01 / Mission
Mission
To make business technology understandable to the people who depend on it.
A system that only its author can explain is a liability, regardless of how well it performs today. The purpose of the work is therefore not simply to deliver working software, but to leave behind something an organisation can inspect, change and continue without the original author present.
This shapes practical decisions: fewer moving parts, conventional solutions preferred over clever ones, documentation treated as part of delivery rather than an optional extra.
02 / Approach
Approach to technology
Boring where possible
Well-understood technology with long support histories is preferred. Novelty is justified only when a specific requirement cannot reasonably be met otherwise.
Reversible steps
Changes are shaped so they can be undone. A decision that cannot be reversed is escalated and documented rather than made quietly.
03 / Principles
Working principles
01
Say what is known and what is not
Estimates are presented with their uncertainty attached. Where something has not yet been investigated, that is stated instead of being smoothed over.
02
Write it down
Scope, assumptions, architectural decisions and their rejected alternatives are recorded so that future changes start from context rather than guesswork.
03
Prefer the smaller change
Where two solutions satisfy the requirement, the one that adds less surface area is chosen, even when the larger one is more interesting to build.
04
Automate what is repeated
Anything performed manually more than a few times becomes a script or a pipeline, so that correctness does not rely on attention.
05
Leave the system inspectable
Logging, metrics and readable code are treated as deliverables. If a problem cannot be diagnosed from outside, the work is not finished.
06
Refuse work that does not fit
Where a request falls outside the practice's competence, saying so is more useful than accepting it and learning at the client's expense.
04 / Standards
Quality standards
Definition of done
Each piece of work has written acceptance criteria agreed in advance. Work is not reported as complete until those criteria are demonstrated.
Automated checks on every change
Type checking, linting and tests run before review. A change that breaks them does not proceed.
Review before release
Code is read by someone other than its author, with attention to failure handling, data access and readability rather than style alone.
Accessibility as a requirement
Interfaces are built for keyboard use, sufficient colour contrast and meaningful structure, and tested for those properties.
Performance measured, not assumed
Load behaviour and query cost are measured against realistic data volumes rather than inferred from a development machine.
05 / Collaboration
Collaboration philosophy
Good technical work is done with an organisation, not to it.
The people who operate a process understand its exceptions better than any specification will. Their observations are treated as primary source material, and the resulting design is described back to them in language they can challenge.
Where internal engineers or another supplier are involved, boundaries are agreed in writing at the start: who owns which component, where reviews happen, and how handover is performed. Ambiguity about ownership is the most common cause of avoidable failure.
Communication defaults
- Written summaries after every substantive discussion
- Plain English, without unexplained jargon
- Progress described by what works, not by percentages
- Problems raised when found, not at the deadline
- One accountable point of contact per engagement
06 / Privacy
Security and privacy principles
Minimum necessary access
Access to systems and data is limited to what a task requires, granted for as long as it is needed, and removed when the work ends.
Client data stays with the client
Production data is not copied to local machines or unmanaged storage. Where a copy is unavoidable it is reduced, masked and removed afterwards.
Confidentiality by default
Details of an engagement, its systems and its weaknesses are treated as confidential without needing to be marked as such.
Secrets managed properly
Credentials live in managed secret storage, never in source control or chat, and are rotated when exposure is suspected.
Purposeful collection
Systems are designed to collect only the personal data they need for a stated purpose, with retention limits considered at design time.
Honest incident handling
If something goes wrong, it is reported promptly with what is known, what is unknown and what is being done.
07 / Vision
Long-term vision
The intention is to keep doing a narrow thing well rather than a wide thing approximately.
That means deepening capability in the areas the practice already works in — application development, cloud environments, integration and the operational discipline that keeps them running — instead of expanding into unrelated services because demand exists.
It also means favouring long relationships over volume. A system maintained over several years teaches more about durable design than a series of short projects handed over and forgotten, and it is where the practice can be most useful.
Software should outlast the enthusiasm that created it.