About us
An IT company that starts with how you work.
HORSE MEAT DISCO LTD builds and maintains software for organisations whose needs are not served by generic products.
Company overview
HORSE MEAT DISCO LTD is an information technology company. We design, build, deploy and maintain custom software, web applications and cloud infrastructure, and we integrate these with the systems our clients already depend on.
Rather than offering a fixed product, we offer an engineering practice: a way of understanding a problem, agreeing what should be built, delivering it in visible steps and keeping it healthy afterwards. Every engagement is scoped individually and described in plain language before work begins.
Mission and working philosophy
Make technology fit the organisation, not the reverse.
Software should reduce friction for the people using it. We measure success by whether a process became simpler, a decision became better informed or a risk became smaller — not by the volume of features shipped.
We are deliberate about scope. Building less, well, and extending it as understanding grows is almost always better than building everything at once.
Engineering principles
Six rules we apply on every project.
- 01
Clarity before code
A problem described precisely is half solved. We write things down and agree them before building.
- 02
Small, reversible steps
Work is delivered in increments that can be reviewed, released and, if needed, undone.
- 03
Boring technology
Proven tools with long support horizons are preferred over novelty, unless the problem genuinely demands otherwise.
- 04
Tests as documentation
Automated tests describe intended behaviour and protect it as the system evolves.
- 05
Observable systems
If it runs in production, it logs, it reports metrics and it alerts someone when it misbehaves.
- 06
Ownership stays with the client
Repositories, cloud accounts and credentials belong to the client from day one.
Understanding business requirements
We ask until the diagram is boring.
Discovery begins with the people who do the work: what they receive, what they produce, where they wait and where things go wrong. We observe current tools, collect real examples and sketch the flow until everyone agrees it is accurate.
From that shared picture we derive requirements, priorities and acceptance criteria. Ambiguities are resolved in writing before they become expensive.
Collaboration practices
Transparent, regular, documented.
- A single shared backlog visible to the client at all times
- Short delivery cycles ending in a demonstration of working software
- Decisions and trade-offs recorded alongside the code
- A named point of contact for every engagement
- Handover documentation written for the people who will maintain the system
Commitment to quality and maintainability
Built to be changed by someone else.
We write code assuming another engineer will inherit it. That means consistent structure, meaningful names, automated tests, reproducible environments and documentation that explains why, not only what.
Maintenance is planned from the start rather than negotiated at the end. Dependencies are kept current, monitoring is in place before launch and improvements are scheduled in the same open backlog used during the build.