About Us
DOOR 47 LTD is an IT company working in software engineering, system architecture, cloud delivery and integration. This page describes how we work and what we hold ourselves to.
01Introduction
DOOR 47 LTD builds and maintains software systems: custom applications, web applications, integrations between existing tools, and the cloud environments those systems run in. The work ranges from designing a system from a blank page to taking over something that has become difficult and expensive to change.
We are an engineering company rather than an agency. That distinction matters in practice: the people who make architectural decisions are the people who write and operate the code, and the artefacts we produce are aimed at whoever maintains the system next.
We publish only what we can stand behind. You will not find invented statistics, client logos or awards on this website — the description of our practice is the claim.
02Mission and vision
To build software that organisations can rely on and continue to change: systems whose behaviour is understood, whose costs are visible, and whose maintenance does not depend on the availability of a single supplier. We measure our work by how easily someone else can pick it up.
A working practice in which technical decisions are documented, reversible and open to review — where modernisation is a continuous, low-drama activity rather than a periodic rescue project, and where the people funding a system understand the trade-offs they are paying for.
03Values
When we do not know how long something will take, we say so and describe what would reduce the uncertainty.
Systems we inherit were built under constraints we did not face. We study them before judging them.
The person who builds a component is responsible for its tests, its documentation and its behaviour in production.
Fewer moving parts, fewer dependencies and fewer abstractions than the problem seems to invite.
Ambiguous requirements produce ambiguous software. We write definitions down until they stop being negotiable.
A decision that saves a week now and costs a quarter later is not a saving.
04Engineering philosophy
Most of the cost of a system appears after the first release. That single observation shapes almost every technical choice we make: conventional technology over novel technology, explicit code over implicit magic, boring data models over flexible ones that nobody can query.
We design boundaries first. Deciding which component owns which data, and what each one promises to the others, removes most of the coupling that makes later change expensive. Interfaces are written down as contracts and versioned when they move.
Failure is part of the specification. Timeouts, retries, idempotent operations, partial degradation and recovery procedures are designed with the feature, because distributed systems fail continuously in small ways.
Finally, we optimise for legibility. A junior engineer reading a module for the first time should be able to predict what it does. If that is not true, the module is not finished.
05Collaboration
We ask for a single person on your side who can answer questions about the domain and make decisions. Progress is limited by decisions, not by code.
Anything agreed in a call is summarised in writing. If it is not written down, it is not agreed.
Work is broken into increments that can be reviewed in days, so direction can change before it becomes expensive.
Repositories, pipelines, issue tracking and environments are shared from the beginning, not presented at the end.
Where you have an internal team, they review our changes and we review theirs. Handover then requires no event.
06Quality standards
07Responsible technology
Collect less. We help define the minimum data a system needs to do its job, and we question fields that exist only because they might be useful later.
Make processing explainable. Where software makes decisions that affect people, the inputs and rules behind those decisions should be inspectable rather than buried in code.
Design for accessibility. Keyboard operation, contrast, semantic structure and readable typography are treated as requirements in every interface we build.
Keep the exit open. Data export, documented interfaces and portable infrastructure definitions mean you can leave any supplier, including us.
Use resources deliberately. Efficient queries, right-sized environments and honest cost reporting reduce both spend and energy use.
08Contact details