Understand before building
We spend time on the process, the data and the existing systems before committing to a technical direction. Requirements written from an assumption are the most expensive kind of defect.
About us
CLOUD AND KEY LTD
An information technology company building custom software, cloud infrastructure and integrations for organisations that depend on those systems to operate.
Company overview
What the company does
CLOUD AND KEY LTD provides software engineering services: custom application development, web application development, cloud architecture and infrastructure, systems integration, business process automation, quality assurance and technical maintenance.
Engagements vary in shape. Some start from an empty repository; others begin with a system already in production that needs to be extended, connected to something else, or made stable enough to change safely. In each case the first task is the same: understand the process the software serves and the constraints that apply to it.
We describe our work in terms of deliverables rather than promises — what will be built, how it will be verified, and what documentation will exist when it is handed over.
Mission and approach
Building software that remains workable
Our mission is to deliver systems that continue to serve the organisations using them after the initial project ends — systems that can be understood by someone who did not write them, and changed without fear.
Prefer the simpler structure
Complexity is added only where the problem requires it. Every additional layer, service or abstraction has a maintenance cost that someone will pay later.
Make decisions visible
Architectural choices, trade-offs and known limitations are written down. A decision that cannot be explained cannot be reviewed or revisited.
Core working principles
The principles our engagements run on
These are the commitments that shape day-to-day work, from the first conversation to routine maintenance.
- 1
Accuracy over optimism
Estimates, risks and limitations are stated as we understand them, including when the honest answer is that something is not yet known.
- 2
Scope defined in writing
What is included, what is excluded and what would constitute a change are agreed before implementation begins.
- 3
Incremental delivery
Work is broken into pieces that can be reviewed while there is still time to adjust direction.
- 4
Ownership stays with the client
Code, infrastructure definitions and documentation are handed over in a form that allows another team to continue the work.
- 5
No unnecessary lock-in
We avoid dependencies that make a system difficult to move, host elsewhere or maintain without us.
Engineering philosophy
Code is read far more often than it is written
We optimise for the person who will open the codebase in two years, including when that person is us.
Explicit over clever
Readable code that states its intent, rather than concise code that requires reconstruction.
Boundaries that hold
Clear separation between domain logic, interfaces and infrastructure concerns.
Tests as documentation
Automated tests that describe expected behaviour, especially around business rules.
Refactoring as routine
Structural cleanup treated as normal work, not deferred until a rewrite is unavoidable.
Collaboration process
How we work alongside your team
Software projects involve people who are not engineers. The process is designed so that those people can follow it without translation.
- A shared, written scope that both sides can refer back to.
- Regular progress updates covering what changed, what is next and what is blocked.
- Demonstrations of working software rather than descriptions of progress.
- A single channel for questions, so answers are not lost across tools.
- Open questions raised early, while adjusting the plan is still inexpensive.
Quality and maintainability
Our commitment after the system is running
Quality is not a phase at the end of a project. It is the accumulated result of decisions made throughout it.
Reviewed changes
Changes pass through review before release, so more than one person understands each part of the system.
Verified behaviour
Functionality is checked against the agreed scope, including error paths and permission boundaries.
Living documentation
Setup, configuration and operational notes are kept with the code and updated as the system changes.
Managed dependencies
Third-party libraries are tracked and updated deliberately rather than left to drift.
Reproducible environments
Infrastructure defined in configuration so an environment can be rebuilt rather than repaired by hand.
Clean handover
Everything required to run, deploy and modify the system is transferred at the end of the engagement.