Maintenance is planned, not improvised
Dependency updates, certificate renewals and platform upgrades are scheduled work with owners and dates, so they do not arrive as emergencies.
About the company
An IT company that
works in the open.
House and Garden Services Ltd provides information technology services to organisations that need software built, integrated, tested and kept running. This page describes how we work and what we hold ourselves to.
01About the company
Who we are and what we do
We are a software engineering and IT services company. Our work covers custom application development, web and mobile products, interface design, cloud infrastructure, system integration, modernisation of existing software, quality assurance, security consulting and ongoing support.
The work arrives in different shapes. Sometimes it is a new system that does not exist yet. More often it is an existing arrangement — part software, part spreadsheet, part habit — that has stopped scaling with the organisation. Both cases start the same way: understanding the current situation precisely before proposing anything.
We deliberately keep teams small and directly involved. The people who design a system are the people who build it, and the people who build it are the people who answer for it once it is live.
02Mission and purpose
To build software that organisations can still change five years from now.
Our purpose is practical rather than aspirational. Systems fail organisations most often not because they were badly built at the start, but because nobody could safely modify them later. We aim to leave every system we touch easier to understand and easier to alter than we found it.
That commitment shapes ordinary decisions: choosing a boring, well-supported dependency over an interesting one; writing the migration script rather than the manual instruction; spending an afternoon on naming. None of it is dramatic, and all of it compounds.
03Company values
Six commitments we can be held to
- 01
Accuracy before speed
A fast answer that turns out to be wrong costs more than a considered one. We would rather spend an extra day understanding a requirement than a month building against a misreading of it.
- 02
Plain language
Technical work can be explained without jargon. If a decision cannot be described in terms a non-specialist understands, it usually has not been thought through properly.
- 03
Ownership
Whoever builds a component is responsible for its behaviour in production. This keeps quality decisions close to the people who make them.
- 04
Restraint
Every feature, dependency and abstraction has an ongoing cost. We add them when they earn their place and remove them when they no longer do.
- 05
Confidentiality
Client systems, data and commercial context are treated as private. Access is limited to the people who need it for the work in hand.
- 06
Continuity
Software outlives the people who wrote it. Documentation, naming and structure are chosen so that the next person can pick the work up.
04Approach to technology
Conservative in tooling, deliberate in design
- Prefer proven technology
- New tools are adopted when they solve a problem we actually have and have a support horizon long enough to justify the commitment.
- Design for the second year
- Architecture is judged by how easy the tenth change will be, not by how quickly the first version can be assembled.
- Keep boundaries explicit
- Interfaces between components are defined, versioned and tested, so parts of a system can be replaced without rewriting the whole.
- Automate the repeatable
- Anything performed by hand more than a few times becomes a script, a pipeline stage or a check — including our own internal processes.
- Measure before optimising
- Performance work follows evidence from profiling and monitoring rather than assumptions about where time is being spent.
05Collaboration principles
How we work alongside your people
One named point of contact
Each engagement has a person responsible for communication, so questions do not circulate without an owner.
A regular rhythm
Progress is reviewed at agreed intervals with working software rather than status slides. Between reviews you can see what is in progress.
Decisions in writing
Any decision that changes scope, cost or architecture is confirmed in writing, including the reasoning and the alternatives considered.
Your tools where practical
We adapt to existing tracking, repository and communication tools rather than requiring a parallel set of our own.
Early warning
If a date or estimate becomes unrealistic, we raise it at the point we know, not at the point it becomes visible.
Shared access
Repositories, environments and documentation are visible to you throughout the engagement, not only at handover.
06Quality standards
What "finished" means here
Definition of done
Work is complete when it is implemented, reviewed, tested, documented and deployable — not when the code compiles.
Review of every change
All changes pass peer review and automated checks. The same standard applies to urgent fixes, which are the changes most likely to cause damage.
Layered testing
Unit tests for logic, integration tests for boundaries, end-to-end tests for the paths users depend on, and manual exploration for the things automation misses.
Accessibility checks
Interfaces are checked for keyboard operation, focus order, contrast and assistive-technology semantics as part of normal review.
Performance budgets
Response times and payload sizes are treated as requirements with agreed thresholds rather than as something to measure after launch.
Reproducible builds
Builds and environments are defined as code so that what runs in production can be recreated exactly.
07Long-term support philosophy
The years after launch are the real test
Monitoring precedes complaints
Systems we support are instrumented so that failures and degradations are detected by alerting rather than by a user reporting them.
Incidents produce change
After a significant incident we record what happened, why the safeguards did not catch it, and which specific change prevents a recurrence.
Knowledge is transferable
Runbooks, architecture notes and environment documentation are kept current so that internal teams can take over whenever they choose.