THE CHILLI JACKET LTD

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.

Code editor open on a laptop next to a notebook with a hand-drawn service architecture diagram
Fig. 01 — Design and implementation held together
Blueprint-style network diagram showing nodes, active and proposed links, and a legend
Fig. 02 — Structure before implementation

§ 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.

Planning table seen from above with an architecture diagram, annotations, notes and an operations dashboard
Fig. 03 — Review and planning artefacts
Data centre aisle with dark server racks and small red status lights
Fig. 04 — Systems in continuous operation

§ 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