Dossier — About the practice

A technology practice with a long name, a narrow focus, and a preference for work that is still running five years from now.

01Overview

MOP AND BROOM CLEANING SERVICES LIMITED is an independent engineering firm. Under this legal identity we operate a modern digital and technology practice, delivering custom software, cloud infrastructure, cybersecurity work, data engineering and applied artificial intelligence to organisations that treat their internal systems as a business asset rather than a running cost.

Overhead view of a developer's workspace with a laptop, notebook and coffee
02Mission

To build technology systems that are trustworthy in the specific sense that matters — they behave the way their documentation says they behave, and the people who depend on them can plan around that.

03Vision

We work toward a state of practice in which software is treated with the same durability and accountability as physical infrastructure. That means systems that can be inspected, systems that can be handed on, and systems whose behaviour under stress is not a mystery to the organisations that rely on them.

04Core values
Restraint
We add complexity only when the simpler version has been genuinely tried. Most systems benefit more from what is removed than what is added.
Directness
Clients speak with the engineers doing the work. Status is reported in plain language, and difficult trade-offs are named rather than softened.
Durability
We choose tools, patterns and abstractions with a bias toward things that will still be maintainable when the current cycle of enthusiasm has passed.
Care
The people using the software are treated as the primary audience, ahead of internal preferences, portfolio aesthetics and technology fashion.
05Approach to technology

Our first response to any problem is to describe it plainly — the current behaviour, the desired behaviour, and the shape of the gap between them. From there we choose the smallest technology that can close that gap without creating a second problem.

We work with a broad but deliberate toolkit. Nothing is chosen for its novelty, and nothing is rejected for its age. The measure is whether it makes the system easier to reason about six months from now.

A small team collaborating in front of a dashboard on a large monitor
06Engineering philosophy

Small changes, shipped often. Long-lived branches accumulate risk; incremental delivery keeps the software close to a known-good state at all times.

Explicit interfaces. Modules communicate through contracts that can be tested, versioned and evolved without private knowledge of their neighbours.

Reversible decisions first. When two options are close, we prefer the one that would be easier to undo — reserving the irreversible calls for moments they actually earn.

07Collaboration principles
  • 01One shared source of truth for the current state of the work — no parallel status decks and no verbal-only commitments.
  • 02Written decisions with the reasoning attached, so that anyone joining later can understand why the system looks the way it does.
  • 03Regular, low-ceremony reviews of what shipped, what did not, and what changed in the picture since the last cycle.
  • 04A working relationship in which either side can say the current plan is wrong without it becoming a political event.
08Quality standards

Our engineering standard is not a slogan; it is a checklist that lives in the repository. Test coverage where coverage is meaningful. Documentation that is treated as part of the deliverable. Reproducible builds and environments. Explicit handling of failure modes rather than silent recovery. Reviewed access to anything sensitive.

09Security & reliability

Security is designed into the system rather than reviewed at the end of it. That includes least-privilege access, deliberate secret handling, encrypted transport and storage, and threat models that are updated when the system changes rather than left as historical artefacts.

Reliability is treated the same way: an operational property that is planned for, measured, and improved incrementally. Error budgets, observability, and on-call practices are shaped to the actual risk profile of the system, not copied from someone else's slide deck.

10Long-term perspective

Software is a compounding asset when it is looked after and a compounding liability when it is not. We plan for the version of the system that exists three years after we hand it over — not the demo that ships next quarter.

11Team culture

The people in the practice are treated as professionals with judgement, not as interchangeable resources on a plan. That means calm hours by default, real time for review and learning, and space to disagree with a decision before it becomes a commitment.

We hire slowly and stay small on purpose. The culture we operate inside is the culture that shows up in the work our clients receive.