Years two and three
Most of a system's cost arrives after launch, in changes, dependency updates and new integrations. Structure decided early determines how affordable that period is.
About the studio
A software studio organised around clarity, structure and durability
This page describes how WATER AND WOOD ATELIER LIMITED thinks about software, how work is carried out, and what can reasonably be expected from an engagement. It contains no claims that cannot be supported.
Who we are
WATER AND WOOD ATELIER LIMITED is an independent software engineering and digital product studio. The work spans the whole life of an application: understanding the process it must support, designing how it behaves, writing and testing the code, deploying it, and keeping it healthy afterwards.
The studio does not sell a fixed platform or resell licences. Each system is built for the organisation that will run it, using widely supported technologies chosen because they suit the problem and because other engineers can maintain them later.
Engagements vary in shape. Some are a single defined build with a clear endpoint. Others are continuous, running alongside an internal team for as long as the product keeps evolving. In both cases the unit of progress is working software that can be inspected, not a status report.
Mission
To build software that solves a real operational problem and stays maintainable long after the first release
A great deal of software is abandoned not because it stopped working, but because it became too difficult to change. The studio treats future modification as a primary requirement, alongside the features requested today.
Approach to technology
Technology chosen for the problem, not for novelty
Selecting a stack is a long-term commitment on behalf of whoever maintains the system next. The studio therefore favours mature languages, standard relational databases and managed infrastructure with a documented upgrade path.
Newer tools are adopted where they clearly reduce risk or effort, and only after the cost of leaving them is understood. Where a dependency could be replaced by a small amount of readable code, the readable code usually wins.
Architecture follows the same logic. A single well-structured application is preferred until the constraints of a system genuinely justify splitting it, because distribution introduces failure modes that must then be managed forever.
Working principles
How the work is actually conducted
01
Understand before building
Time spent mapping the existing process is repaid several times over during implementation.
02
Deliver in reviewable stages
Each stage ends with something that runs, so feedback arrives while it is still inexpensive to act on.
03
Write decisions down
Options considered and reasons for the choice are recorded next to the code they affect.
04
Automate what repeats
Builds, tests, checks and deployments run without manual steps, because manual steps are eventually skipped.
05
Prefer plain language
Progress and risk are described without jargon, so non-technical stakeholders can make informed decisions.
06
Leave the system better
Every change includes tidying the area around it, which keeps the codebase from degrading gradually.
Quality and responsibility
Standards applied to every engagement
These standards are commitments about method. They describe what is done, not results that could be promised on someone else's behalf.
- Correctness first
- Behaviour is verified with automated tests and reviewed against the agreed acceptance conditions before anything is released.
- Data handled carefully
- Personal and business data is collected only where needed, protected in transit and at rest, and retained according to agreed rules.
- Accessibility as a baseline
- Interfaces are built to WCAG 2.1 AA principles: keyboard operable, semantically structured, legible and not dependent on colour alone.
- Transparent limitations
- Known weaknesses, deferred work and technical debt are named openly rather than discovered later by someone else.
- Responsibility for defects
- Faults introduced by the studio are corrected as a matter of course, not treated as new billable scope.
Collaboration philosophy
Working with your people, not around them
The people who use a system every day know things that never appear in a specification. Their exceptions, workarounds and shortcuts are evidence about how the process really works, and they shape the design directly.
Where an internal technical team exists, the studio works within its conventions rather than importing unfamiliar ones. Code review runs in both directions, and knowledge transfer happens continuously instead of at a handover meeting.
Disagreement is treated as useful. When two reasonable approaches exist, the trade-offs are written out so a decision can be made deliberately and revisited if the assumptions change.
Long-term product thinking
The first release is the beginning of the cost, not the end of it
Documentation that survives
Runbooks, architecture notes and environment definitions are written as work proceeds, because reconstructed documentation is rarely accurate.
Exit without penalty
Repositories, infrastructure configuration and credentials are yours throughout. Continuing with the studio should be a choice, never a dependency.
Contact
Speaking with WATER AND WOOD ATELIER LIMITED
Enquiries are handled in writing by email. Further guidance on what to include in a first message is available on the contacts page.
heidibrooks198461@gmail.com