Scope in writing
Agreed scope, assumptions and exclusions recorded before work begins, and updated when they change.
About us
A company organised around engineering judgement
KIO BARBER LTD is an IT company. We build and maintain software: custom applications, web platforms, the infrastructure they run on and the integrations that tie them to the rest of a business.
This page describes how we work and what we believe about building software. It deliberately makes no claims about history, size, clients or credentials.
01Focus
Where we concentrate
Software that runs a business
Systems where correctness, availability and clarity matter more than novelty: operational tools, internal platforms, customer-facing web applications and the services behind them.
The long middle of a project
Much of the value in software arrives after launch. We are set up for the sustained phase: maintenance, refactoring, dependency updates and steady functional growth.
Systems that already exist
Extending, stabilising and integrating software already in use, including codebases with sparse documentation and infrastructure that grew without a plan.
02Working principles
How the work is run
Increments, not milestones
Delivery in small releasable pieces so direction can be corrected early and cheaply.
Review everything
Every change reviewed before it merges; nothing reaches production on a single pair of eyes.
Reversible steps
Migrations, deployments and configuration changes planned with a rollback path.
Explicit trade-offs
Options presented with their costs, including the risk of an approach we would not recommend.
No silent surprises
Problems raised when they appear rather than at the point they become unavoidable.
03Collaboration
Working alongside your team
Software is built with the people who will use and maintain it. We work from a shared task board, write updates that a non-specialist can follow, and keep technical discussion in a place that is searchable later.
Where an internal team is involved, we adopt their conventions rather than imposing ours, and treat knowledge transfer as part of delivery: pairing, written architecture notes and runbooks produced as the system takes shape.
Written first
Decisions, scope and updates in writing so they survive staff changes and time.
One source of truth
A single board and repository for work in progress, visible to everyone involved.
Demos over reports
Progress shown in a running system rather than described in a status document.
Handover by default
Documentation written as the work proceeds so the system can be maintained without us.
04Engineering philosophy
Code is read far more often than it is written
We optimise for the engineer who opens the file in two years. That means straightforward control flow, names that describe intent, boundaries that are explicit, and tests that document expected behaviour.
Complexity is spent deliberately, where the problem genuinely requires it, and paid down when it stops earning its keep. Performance work follows measurement. Security is a property of the design rather than a review at the end.
The goal is a system that a reasonable team can keep changing safely — long after the first release.
05Contact