Work held together by spreadsheets
Critical processes run in files that only one person fully understands, with no history, validation or access control.
Software engineering studio
Considered software for organisations that intend to keep it
WATER AND WOOD ATELIER LIMITED designs, builds and maintains custom applications, web platforms and the integrations that connect them. The work is deliberately unhurried: clear structure, readable code, and systems that remain understandable years after release.
- Practice
- Custom software, product design and system integration
- Method
- Small reviewable stages, written decisions, working software
- Contact
- Written enquiries by email, answered in plain language
01 — Overview
An independent studio built around engineering craft
The studio works on software that businesses depend on daily: the tool that schedules the work, the portal customers log into, the service that moves data between two systems that were never designed to speak to each other. These are not glamorous problems, but they decide whether an organisation runs smoothly.
Every engagement begins with understanding the actual process before any interface is drawn. What a team does today, where information is re-entered by hand, which exceptions break the rules — these details shape the architecture far more than any technology preference.
The name reflects two working values rather than a material. Water: adapting to the shape of the problem instead of forcing a template onto it. Wood: structure, grain and durability, built to be worked on again later by someone else.
The studio remains deliberately small in scope per project, so that the people writing the code are the people who understand the requirements, and decisions do not lose their reasoning as they travel through layers of process.
02 — Capabilities
Core technology capabilities
- 01
Application engineering
Server-rendered and single-page web applications, background processing, scheduled jobs and long-running workflows.
- 02
API and interface design
HTTP and event-based interfaces with explicit contracts, versioning strategy, validation and predictable error semantics.
- 03
Data modelling
Relational schema design, migrations, reporting structures and the query work required to keep them responsive as volume grows.
- 04
Front-end systems
Component libraries, design tokens, state management and accessible interaction patterns that scale beyond a single screen.
- 05
Cloud and deployment
Environment configuration, container images, continuous integration, automated deployment and rollback paths.
- 06
Observability
Structured logging, metrics, alerting thresholds and traces that make production behaviour legible rather than guessed at.
03 — Services
What the studio is engaged to do
Engagements range from a single well-defined build to continuous work alongside an internal team. The full explanation of each service, the business need it addresses and the work it typically involves is set out on the services page.
- Custom software development
- Systems shaped around a specific operational process rather than around a product licence.
- Digital product design and UI/UX engineering
- Interface architecture, design systems and the front-end code that implements them faithfully.
- System integration
- Reliable movement of data between applications, with reconciliation and failure handling.
- Modernisation and ongoing support
- Incremental replacement of ageing components, plus the maintenance that keeps software healthy.
04 — Problems
Business problems this work addresses
Most requests arrive described as a technology problem. Underneath, they are usually one of a small number of operational failures.
Systems that cannot exchange data
Information is retyped between tools, creating delay, duplication and disagreement about which record is correct.
Software nobody dares to change
The codebase works, but every modification risks breaking something invisible, so improvements stop happening.
Interfaces that slow people down
Staff need training to complete routine tasks because the screens follow the database rather than the workflow.
Costs that scale badly
Infrastructure or licensing grows faster than usage because nothing was sized, measured or reviewed.
No visibility into production
Failures are reported by users rather than detected by monitoring, and root causes are reconstructed from memory.
05 — Delivery
How a project moves from question to running software
Stages are sequential but not rigid. Findings from later stages routinely send work back to an earlier one, and that is treated as normal rather than as failure.
Stage 1
Enquiry
A written description of the problem, its context and any constraints already known.
Stage 2
Discovery
Review of the current process, existing systems, data shapes and the people affected.
Stage 3
Definition
Scope, architecture outline, sequencing and the acceptance conditions for the first stage.
Stage 4
Build
Implementation in reviewable increments, with automated tests written alongside the code.
Stage 5
Verification
Functional review, accessibility and performance checks, and correction before release.
Stage 6
Operation
Deployment, monitoring, documentation and the maintenance rhythm that follows release.
06 — Principles
Engineering principles that shape the result
- Simple before clever
- The obvious solution is preferred until measurement proves it insufficient. Complexity has to earn its place.
- Explicit over implicit
- Configuration, contracts and failure modes are written down rather than inferred from behaviour.
- Boring infrastructure
- Well-understood, widely supported components reduce the number of unknowns during an incident.
- Tests as documentation
- Automated tests record intended behaviour and make later change affordable rather than frightening.
- Reversible decisions first
- Where a choice can be deferred cheaply, it is deferred until more is known.
07 — Non-functional work
Security, reliability, accessibility and performance
These qualities are treated as part of the build rather than as a review at the end, because retrofitting any of them is consistently more expensive than designing for them.
Security
Least-privilege access, validated input at every boundary, secrets kept outside source control, and dependencies tracked for known vulnerabilities.
Reliability
Defined failure behaviour, retries with limits, backups that are restored in practice, and deployment paths that can be reversed.
Accessibility
Semantic markup, keyboard operability, visible focus, sufficient contrast and content that does not depend on colour alone.
Performance
Budgets agreed early, measured against realistic data volumes, with queries and payloads examined before hardware is added.
08 — Contexts
Business contexts the work suits
The studio does not claim sector specialisation or name organisations it has worked with. What follows describes the kinds of situations where this approach tends to fit well.
Operations-heavy businesses
Where scheduling, inventory, logistics or field work is coordinated across several tools.
Professional services
Where client records, documents and billing information must stay consistent and auditable.
Product teams
Where an early version proved the idea and the codebase now needs structure to grow.
Regulated environments
Where access control, retention rules and traceability shape what may be built.
Education and research
Where structured data collection and reporting matter more than visual novelty.
Internal platform work
Where several teams share infrastructure, component libraries or common services.
09 — Considerations
Reasons an organisation might choose this studio
Direct communication
You correspond with the people writing the software. Requirements are not relayed through account management, and technical trade-offs are explained in ordinary language.
Written reasoning
Architectural decisions, alternatives considered and their consequences are recorded, so future maintainers inherit the reasoning and not only the result.
Handover by default
Code, infrastructure definitions and documentation belong to you. The work is structured so another team could continue it without renegotiation.
Honest scope
Where a requirement is uncertain, it is called uncertain. Estimates carry their assumptions, and unsupported guarantees are not offered.
Restraint in tooling
Dependencies are added when they solve a real problem. Fewer moving parts means fewer upgrade paths to maintain later.
Attention after release
Software is treated as something that lives. Monitoring, updates and small corrections are planned rather than improvised.
10 — Questions
Frequently asked questions
What kind of software work does the studio take on?
- Work is focused on custom software: web applications, internal business tools, APIs and integrations between existing systems, along with the design and engineering that surrounds them. Projects may start from an idea, an existing prototype, or a system that already runs in production and needs to be extended or modernised.
How does an engagement usually begin?
- It begins with a written description of the problem. From there the scope is discussed, constraints are clarified, and a first stage of work is defined that is small enough to deliver and review quickly. Nothing is committed until the objectives, the assumptions and the boundaries of the work are agreed in writing.
Can you work with an existing codebase?
- Yes. A large part of software work is inheriting systems written by other people. The usual approach is a structured review of the code, its dependencies and its deployment path, followed by incremental changes that keep the system running while its weakest areas are replaced.
Which technologies are used?
- Choices depend on the problem rather than on preference. In general, the studio favours widely supported, well-documented languages and frameworks, standard relational databases, and managed cloud infrastructure, so that the resulting system can be maintained by other engineers in the future.
How is progress communicated?
- Through written updates and working software. Each stage of a project ends with something that can be run and inspected, together with a plain description of what changed, what remains open, and what decisions are needed next.
What happens after a product is delivered?
- Support can continue on an ongoing basis: dependency updates, monitoring, fixes, performance work and small feature additions. Alternatively, the work can be handed over with documentation so an internal team can take over maintenance.
11 — Company information
WATER AND WOOD ATELIER LIMITED
Enquiries about custom software, product design, integration or maintenance work are welcome in writing. A short description of the problem, the systems already in use and any fixed constraints is enough to start a useful conversation.
Website language: English. Correspondence is answered by email only.