About / Index 01
An engineering practice, described honestly
BREAD FURNITURE LIMITED is an IT services company working in software development, web applications, integration and infrastructure planning. This page describes how the work is approached — not a corporate biography.
Who we are
The company provides information technology services: building software, connecting systems, planning the infrastructure they run on, and maintaining them afterwards. Despite the registered name, the work is not related to furniture.
No founding date, leadership profile, office address, employee count or registration detail is presented here, because those facts are not documented on this site. What is described instead is method: how a project is structured, how decisions are recorded, and what quality means in practice.
Enquiries are handled by email at aidahenderson1998@gmail.com. The company domain is breadfurniture.com.
Build software
that stays
understandable
The mission is straightforward: deliver digital systems that solve a stated problem and remain workable for the people who inherit them. Software that cannot be changed safely has a short useful life, regardless of how it looked on the day it launched.
The working philosophy follows from that. Scope is kept deliberate. Complexity is added only when it earns its place. Decisions are written down with their reasoning so that a future change does not begin with archaeology.
Progress is measured by working software rather than by documents describing future software. Each increment should be demonstrable, and each demonstration should be an opportunity to correct direction.
Where a requirement is unclear, the ambiguity is raised rather than resolved silently. A short question early is cheaper than a rebuild later.
Engineering values
Write for the next reader
Code, migrations and documentation are written on the assumption that someone else will read them under time pressure.
Prefer boring solutions
Familiar, well-understood tools are chosen over novel ones unless the novelty solves a real, present problem.
Make behaviour observable
A system should be able to explain what it did. Logging and error reporting are designed, not bolted on.
Say what is uncertain
Estimates, risks and unknowns are stated plainly. Confidence is reserved for things that have been verified.
Working together
Collaboration is structured around short cycles and written records. A cycle starts with an agreed objective, ends with something reviewable, and produces notes on what changed and what remains open.
Access to the work in progress is preferred over status reports. Seeing a running increment answers more questions than a summary of one.
Disagreement is treated as useful information. When a technical recommendation conflicts with a business preference, both are stated explicitly with their trade-offs, and the decision is recorded.
Maintainability and quality
Maintainability is designed in. Modules are given clear responsibilities, dependencies are kept few and current, configuration is explicit, and the path from a fresh checkout to a running system is documented and tested.
Quality work combines automated tests around fragile logic, structured code review, and manual verification of the paths that matter most — including what happens when something fails.
After release, attention shifts to evidence: error reports, usage patterns, and feedback from the people doing the work. Improvements are planned from that evidence rather than from assumption.
