Model the domain first
Before frameworks are chosen, the entities, states, and rules of the domain are written down. A correct model makes most later decisions obvious; an incorrect one makes every one of them harder.
00About us
We build software the way engineers build instruments.
BOTTLECLOSET LTD is an IT services company. Our work is the design, construction, verification, and operation of software systems — and the written reasoning that makes those systems maintainable after we hand them over.
01Company overview
What the company does
The company delivers custom software development, web application engineering, cloud infrastructure and DevOps, systems integration and automation, quality assurance, and technical consulting.
Engagements are defined in writing before work begins: objective, scope, deliverables, and the way progress will be reviewed. Work is carried out in short increments so that direction can be corrected early, and so that what has been completed is always demonstrable rather than described.
We do not publish client names, case studies, or performance statistics on this website. What we can describe honestly is our method — and that is what these pages set out.
02 / Mission
To make software that organisations can rely on and understand.
Much of the cost of software is paid after launch, by the people who must change it. Our mission is to shift effort forward — into clear modelling, tested behaviour, reproducible infrastructure, and honest documentation — so that later change is a routine engineering task rather than an excavation.
03Engineering philosophy
Four convictions that shape every technical decision.
Make the invisible visible
Logs, metrics, traces, and tests exist so behaviour can be observed rather than assumed. A system you cannot observe is a system you cannot maintain.
Prefer boring solutions
Established tools with predictable behaviour are chosen over novelty. Novelty is reserved for the part of the problem that is genuinely new.
Write for the next reader
Code, commits, and documents are written for the engineer who arrives without context. Cleverness that costs comprehension is removed in review.
04Values
How we hold ourselves to it.
- Clarity
- A system that cannot be explained simply is not yet finished. Naming, structure, and documentation are part of the work, not an afterthought.
- Accountability
- Estimates, risks, and mistakes are stated plainly. When something slips, the reason and the revised plan are communicated immediately.
- Restraint
- Complexity is added only when a requirement demands it. Fewer moving parts means fewer ways to fail.
- Durability
- Decisions are judged by how they behave a year later, under maintenance by someone new.
- Evidence
- Behaviour is demonstrated by tests and observability data rather than asserted in a status report.
- Respect for context
- Existing systems, budgets, and internal constraints are treated as facts to design around, not obstacles to dismiss.
05Collaboration
Working alongside your team, not around it.
Engagements are set up so that internal teams keep ownership of their systems. That means a shared backlog rather than a private one, code review that includes your engineers where they wish to participate, and documentation written in the repository instead of in a closed tool.
Progress updates follow a fixed structure: completed, in progress, blocked, next. Decisions of consequence are recorded with the options considered, so a future reader can see why the current design exists.
Handover is planned from the beginning — environment definitions, runbooks, and architectural notes are produced during the work, not assembled at the end.
06Quality principles
Quality is a process, not a final inspection.
- 01Definition before constructionA change is only started once its expected behaviour is stated in a way that can be tested.
- 02Review as standardEvery change is read by another engineer before it merges; review covers correctness, security, and readability.
- 03Automation in the pipelineType checking, static analysis, and test suites run on every change, and a failing pipeline blocks release.
- 04Reproduce, then repairDefects are reproduced with a failing test before a fix is written, so the fix is provably effective.
- 05Observe after releaseBehaviour is monitored after deployment, and what is learned feeds the next increment.
These principles describe how we work. They are not a warranty of specific business results, and they are not a statement of legal or regulatory compliance on your behalf.
07Contact
Enquiries are handled by email. BOTTLECLOSET LTD — [email protected] — bottlecloset.com