About us
About the practice
THE CHILLI JACKET LTD is a software engineering company. Its work is the design, construction and continued care of systems that organisations depend on to operate.
§ 01Company overview
What the company does
The company delivers custom software development, web application engineering, cloud and infrastructure work, integrations, workflow automation, quality assurance and ongoing technical support. Engagements range from a focused technical review of an existing system to the design and construction of a new platform, followed by long-term maintenance.
Every engagement produces transferable output: source code held in the client's repository, infrastructure defined as code, documented interfaces and operational instructions. Nothing essential is retained privately by the company.
All work, documentation and correspondence is conducted in English.


§ 02Approach to technology
Boring tools, carefully applied
Technology is selected for the properties a system needs, not for novelty. Mature, well-documented and actively maintained components are preferred, because they can be hired for, reasoned about and patched.
Complexity is treated as a cost carried by everyone who touches the system later. Each additional service, dependency or abstraction has to justify itself against the simpler alternative. Where a novel component is genuinely warranted, it is isolated behind an interface so that it can be replaced without rewriting the system around it.
§ 03Working principles
Principles applied to every engagement
Write it down
Requirements, interfaces, decisions and their reasoning are recorded. Shared understanding that exists only in conversation does not survive a change of people.
Small increments
Work is delivered in reviewable pieces that can be deployed independently, so progress is visible and course corrections are cheap.
Make it reversible
Deployments, migrations and configuration changes are designed with a path back to the previous state.
Measure before optimising
Performance work follows profiling and monitoring data rather than intuition about where time is spent.
Own the boundaries
Trust boundaries — user input, third-party data, privileged operations — receive explicit validation and explicit permission checks.
Leave it maintainable
Code, tests and documentation are written for the engineer who will read them without context in two years.
§ 04Collaboration philosophy
Working alongside, not apart
The people who run a process know things about it that no specification captures. Access to them, at a predictable cadence, is the single largest factor in whether software fits the work it supports.
Engagements are structured around regular demonstrations of working software rather than status reports about progress. Open questions, assumptions and risks are shared as they arise instead of at the end of a phase. Where a request would create a long-term cost that is not obvious from outside, that cost is described plainly so the decision can be made with full information.
The client's existing engineering, operations and security teams are treated as collaborators. Conventions already in place — repository structure, review practice, deployment tooling — are adopted rather than displaced, unless there is a specific reason to change them.
§ 05Engineering quality
Quality that can be checked
Quality is defined as properties that can be verified: the behaviour described by tests, the coverage of critical paths, the clarity of error handling, the reproducibility of the build, and the completeness of the documentation required to operate the system.
Every change passes through review and an automated suite before it can be deployed. Defects found in production are traced to the missing check that allowed them through, and that check is added.


§ 06Long-term product thinking
Designing for the second decade
A system delivered on time but impossible to change has only deferred its cost. Decisions are therefore weighed against what they will require of the team maintaining the software long after the initial engagement.
That means stable data models that tolerate new requirements, interfaces versioned so that consumers are not broken by improvement, dependency choices that will still receive security updates, and an operational story that a different team can pick up from the documentation alone.
Contact for written enquiries: amymills1994@gmail.com
Website: thechillijacket.com