01
The system is hard to change
Releases are slow and risky because nobody is certain what a change will affect. We map the real dependencies before touching them.
FRIEND HOMES LTD / IT engineering practice
Systems that
keep working.
We design, build and look after software and infrastructure: applications, cloud platforms, data pipelines and the security practices around them. The work is deliberately unglamorous — clear scope, readable code, systems your team can operate without us in the room.
01 — Who we are
An engineering company, organised around the systems our clients depend on.
FRIEND HOMES LTD works with organisations that already run technology and need it to be better understood, better built or better maintained. Some engagements start with a product idea; many start with an existing system that has grown faster than the documentation around it.
We prefer small, accountable teams working directly with the people who own the outcome. That means fewer handovers, decisions recorded where they can be found later, and a written trail of why a system looks the way it does.
IT capabilities, in plain terms
02 — Capability index
- Application engineering
- Web and mobile applications, internal tools, APIs and integrations between systems that were never designed to talk to each other.
- Cloud & platform
- Environment design, containerisation, deployment pipelines, observability and cost-aware architecture on mainstream cloud providers.
- Security engineering
- Threat modelling, access control review, dependency and configuration hardening, and practical remediation plans.
- Data & automation
- Ingestion, transformation, reporting models and the removal of manual steps that quietly consume working hours.
- Product & interface design
- Interface architecture, interaction detail and design systems that survive contact with real content.
03 — Problems we are usually called about
02
Nobody owns the infrastructure
Environments were set up under time pressure and never revisited. We document what exists, then modernise the parts that carry the most risk.
03
The data cannot be trusted
Numbers disagree between reports. We trace the lineage, fix the transformations and define one source of truth.
04
Manual work keeps growing
Spreadsheets and copy-paste steps hold a process together. We automate the repeatable parts and leave judgement with people.
05
Security is assumed, not verified
Access, secrets and dependencies drift over time. We review the current state and prioritise what to correct first.
06
The interface fights the user
The software technically works but takes training to survive. We restructure the flows around the tasks people actually perform.
04 — Services
Eleven service lines, one engineering standard
Engagements are usually a combination rather than a single line item. The full description of each service is on the Services page.
- Custom software development
- Web application development
- Mobile solutions
- Cloud architecture
- Infrastructure modernisation
- Cybersecurity consulting
- Data engineering
- Business process automation
- UI/UX and product design
- Technical consulting
- Maintenance and optimisation
05 — Software development
Write less, but write it to be read
We treat source code as the primary documentation of a business process, so it is written for the next engineer rather than for the compiler alone. Work is broken into small, reviewable changes with tests around the behaviour that matters, and every branch reaches an environment where someone can click through it.
- Requirements written as concrete scenarios before estimates are given.
- Short iterations with working software at the end of each one.
- Code review on every change, including changes made by senior engineers.
- Automated checks in the pipeline rather than manual pre-release rituals.
06 — Cloud & infrastructure
Environments that can be rebuilt from a repository
Infrastructure is described in code, versioned alongside the applications it serves, and rebuilt rather than repaired by hand. Staging resembles production closely enough to be useful, and deployments are routine events rather than scheduled risks.
We work with mainstream cloud platforms and with hybrid estates where part of the system stays where it is. Migration plans are staged so that each step delivers something usable and can be reversed.
07 — Security
Security as an operating habit
Most incidents we are asked to review begin with something ordinary: an account that kept access after a role change, a dependency nobody updated, a configuration copied from an old project. We start with the boring inventory — identities, secrets, exposed surfaces, third-party components — and produce a prioritised list you can act on.
From there, controls are built into the development pipeline: dependency scanning, least-privilege defaults, encrypted secrets handling, logging that makes an investigation possible after the fact. We describe residual risk honestly instead of claiming it away.
08 — Data & automation
From scattered records to a model people trust
Data work begins with lineage: where a figure originates, what transforms it, and who depends on the result. Once that is written down, pipelines can be rebuilt with tests on the values themselves, not only on the code that moves them.
Automation follows the same logic. We look for the repeated manual steps around a process, remove the ones that are purely mechanical, and leave clear points where a person makes a decision and can see what the system did.
09 — Product & experience
Design that starts from the task
Interface work is structural before it is visual. We map the tasks a user has to complete, the information they need in front of them, and the states the system can be in — including the awkward ones. Only then do typography, spacing and colour get decided, and they are recorded as a small system rather than a set of screens.
Accessibility is part of that structure: keyboard paths, readable contrast, sensible focus order and text that makes sense when read aloud.
How an engagement runs
10 — Process
Step 1
Discovery
We read the existing system, talk to the people who use it and write down constraints.
Step 2
Definition
Scope, sequence and acceptance criteria agreed in writing before build begins.
Step 3
Build
Short iterations, reviewed changes, working software at the end of each one.
Step 4
Verification
Automated checks plus review against the criteria we agreed at the start.
Step 5
Operation
Monitoring, maintenance and a handover that lets your team run it.
11 — Technology principles
Choices we can defend in two years
Boring where it counts
Established tools for the load-bearing parts of a system; novelty reserved for places where it is genuinely worth the risk.
Explicit over clever
Code and configuration that state their intent, even at the cost of a few more lines.
Reversible decisions first
Where a choice is hard to undo, we take longer over it and write down the reasoning.
No lock-in by accident
Platform features are used deliberately, with the exit cost understood before adoption.
Documentation as deliverable
Architecture notes, runbooks and decision records are part of the work, not an afterthought.
12 — Business contexts
Where this work tends to fit
We describe contexts rather than claiming named clients. If your situation resembles one of these, the conversation usually starts well.
Operations-heavy businesses
Internal systems that coordinate people, stock, scheduling or logistics.
Regulated and privacy-sensitive work
Environments where data handling and auditability are requirements, not preferences.
Growing digital products
Applications that outgrew their first architecture and need a considered second one.
Professional services firms
Practices automating reporting, intake and document-heavy processes.
Distributed teams
Organisations needing shared tooling, access control and reliable environments across locations.
Long-lived legacy systems
Software that still earns money and must be modernised without a shutdown.
13 — Quality & reliability
Reliability is a practice, not a promise
We do not publish uptime figures for systems we do not yet run. What we can commit to is method: defined acceptance criteria, automated regression checks, staged releases, monitoring with alerts that a human has agreed to answer, and a written response procedure for when something fails.
After an incident we write a short account of what happened and what changed as a result. Over time that record, not a slogan, is the evidence of reliability.
14 — Contact
Write to us with the specifics
Correspondence is by email. A short description of the system, the problem and your timeframe is enough for us to reply with something useful rather than a generic brochure.
- Company
- FRIEND HOMES LTD
- anniewatso89@gmail.com
- Language
- English