AAbout us
An engineering company that prefers plain answers
HUMBLE JACKET LTD builds and maintains software. This page describes how we think about that work — the philosophy, the working principles, and what we do to keep a system maintainable long after the first release.
01Company overview
What the company does
The company operates as a software engineering practice. Work arrives as a problem description — an application to build, a process to automate, an integration to make reliable, a system to modernise — and leaves as running software with documentation and tests attached.
Our services cover custom software development, web application development, backend engineering and API integration, cloud infrastructure and deployment, workflow automation, software testing and quality assurance, and ongoing technical maintenance.
We deliberately publish no invented history, no team photographs and no statistics we cannot substantiate. What we can describe accurately is our method, and that is what this page contains.
02Engineering philosophy
Software is a liability until it earns its place
Every line of code has to be understood, tested, deployed and eventually changed by somebody. That cost is real, so we write as little as the problem allows and make what remains as legible as we can.
We treat correctness as a design property rather than a testing outcome: constrain the data model so invalid states cannot be represented, keep side effects at the edges, and make the difficult cases explicit in code instead of leaving them to convention.
Where a shortcut is taken knowingly — and sometimes it should be — it is recorded as a shortcut, with the conditions under which it must be revisited.
03Working principles
The rules we hold ourselves to
- 03.1
Scope before estimate
We do not quote on a sentence. Scope is written down, reviewed and agreed first, and the estimate follows from it.
- 03.2
Small, verifiable steps
Work is divided so that each step produces something reviewable. Long stretches without visible output hide risk rather than remove it.
- 03.3
No silent assumptions
When a requirement is ambiguous, we ask instead of guessing, and record the answer where both sides can find it later.
- 03.4
Tests accompany changes
A change without a test is provisional. Automated checks are written alongside the feature, not deferred to a later phase.
- 03.5
Leave the system operable
Deployment steps, environment variables, backup and restore procedures and known limitations are documented as part of delivery.
- 03.6
Honest limits
If a request falls outside what we can do well, we say so rather than learn at the client's expense.
04Collaboration style
Written first, meetings second
Most coordination works better in writing. A written thread can be re-read, forwarded to someone who joined late, and checked against what was actually built. Calls are useful for resolving disagreement quickly; their conclusions are then written down.
- Single point of contact
- Enquiries and project correspondence run through email, so the history of a project stays in one searchable place.
- Regular written updates
- Each cycle closes with a note covering what shipped, what was decided, what is blocked and what comes next.
- Open backlog
- Outstanding items are visible rather than held privately, including the ones we have deprioritised and why.
- Direct disagreement
- If we think a requested approach will cause problems, we explain the reasoning once, clearly, and then respect the decision made.
05Long-term maintainability
Designing for the maintainer who is not us
The realistic lifetime of a business system is measured in years, and most of that time is spent under someone else's care. We build with that handover assumed from the first commit.
- Conventional project structure, so a new engineer can orient without a tour
- Dependencies kept current and deliberately few, with upgrade paths noted
- Migrations versioned and reversible wherever the data allows
- Configuration separated from code, with every environment variable documented
- Architecture decisions recorded with their context and alternatives
- Runbooks for the operations that will eventually be needed at an awkward hour
Maintainability is not a single deliverable; it is the accumulated effect of many small refusals — refusing an undocumented workaround, refusing a dependency that is not maintained, refusing a clever abstraction that only its author understands.