thechillijacket.com

THE CHILLI
JACKET LTD

An independent software engineering practice. The company designs, builds and maintains custom applications, web platforms, cloud infrastructure and integration layers for organisations whose operations depend on software behaving correctly.

Practice

Software development · Web engineering · Cloud and infrastructure · Integration and automation · Quality assurance · Long-term support

Fig. 01 — Engineering environment

§ 01Introduction

A practice built around systems

THE CHILLI JACKET LTD works with organisations that rely on software to run daily operations, serve customers, and hold the record of what has happened in the business.

The company's work spans the full life of a system: understanding the process it supports, designing its structure, writing and testing the code, putting it into production, and keeping it dependable as the surrounding organisation changes. Engagements are structured so that value appears in reviewable increments and so that the client retains full ownership of the resulting source code, infrastructure definitions and documentation.

Work is deliberately unglamorous in method. Requirements are written down. Interfaces are specified. Behaviour is covered by tests. Deployments are automated and reversible. These practices are what allow a system to be changed safely years after it was first written.

§ 02Technology capabilities

What the practice covers

Application engineering

Server-side services, data models, background processing and user-facing interfaces built as one coherent system rather than assembled from disconnected parts.

Data and storage design

Relational schemas, migrations, indexing strategies and reporting structures designed around how information is actually queried and changed over time.

Interfaces and APIs

Documented, versioned interfaces that allow internal teams and external partners to exchange data predictably, with clear error semantics.

Infrastructure and delivery

Environment definitions, deployment pipelines, observability and rollback paths so that releases are repeatable and reversible.

Automation

Scheduled jobs, event-driven workflows and rule engines that remove repetitive manual steps from operational processes.

Verification

Automated and exploratory testing applied at the level where each risk actually lives, from unit behaviour to end-to-end flows.

Technical blueprint diagram showing interconnected system nodes, data links and a highlighted primary node — Fig. 02 — Illustrative architecture diagram

Laptop showing a code editor with API route handlers beside a notebook containing a hand-drawn architecture sketch — Fig. 03 — Implementation and design notes

§ 03Custom software development

Software shaped by the process it serves

Off-the-shelf products assume a standard process. When an organisation's advantage lies in doing something differently, that difference has to be encoded somewhere — usually in spreadsheets, email threads and the memory of experienced staff.

Custom development moves that logic into a system where it can be applied consistently, audited and improved. The work begins by mapping the process as it exists, identifying the rules that genuinely matter, and modelling the data those rules operate on. Implementation follows the model, not the other way round.

Domain modelling and data structure design
Business rule implementation with test coverage
Role-based access and audit trails
Reporting and export surfaces for operational use

§ 04Web application engineering

Interfaces that hold up under daily use

A web application is used for hours at a time by people who did not choose it. Its value comes from clarity, responsiveness and predictability rather than visual novelty.

Interfaces are built with semantic markup, keyboard operability and sensible contrast as defaults. Layouts are designed to work across phone, tablet and desktop widths without separate codebases. State handling, loading behaviour and error messaging are treated as functional requirements, because they determine whether the application can be trusted during an ordinary working day.

Rendering

Server-rendered and client-rendered surfaces chosen per view according to indexing and interactivity needs.

Accessibility

Semantic structure, focus management, contrast and text scaling considered from the first layout.

Performance

Asset budgets, image sizing, lazy loading and measured interaction cost.

Resilience

Explicit error, empty and permission states rather than blank screens.

§ 05Cloud and infrastructure

Environments defined as code

Infrastructure that exists only as manual console configuration cannot be reproduced, reviewed or recovered reliably. The practice defines environments declaratively so that development, staging and production differ by parameters rather than by history.

Deployment pipelines build once and promote the same artefact through environments. Observability — structured logs, metrics and traces — is installed with the first release, not after the first incident. Backup and restore procedures are written down and exercised rather than assumed.

Abstract visualisation of layered cloud computing planes with light trails in charcoal, ivory and red — Fig. 04 — Layered platform model

Provisioning

Declarative environment definitions kept in version control.

Pipelines

Automated build, test and deployment with promotion between environments.

Observability

Structured logging, metrics, alerting thresholds and dashboards.

Continuity

Backup schedules, restore procedures and documented rollback paths.

Network patch panel with neatly routed cables, one red cable standing out among ivory cables — Fig. 05 — Connection layer

§ 06Systems integration and automation

Removing the manual handover

Most operational friction sits between systems rather than inside them: data re-keyed from one tool into another, exports emailed on a schedule, reconciliations performed by hand at the end of the month.

Integration work replaces those handovers with defined interfaces. Messages are validated, retried on transient failure and recorded so that the state of any exchange can be inspected. Automation then applies the rules that a person would have applied, at the moment the triggering event occurs, and escalates only the cases that genuinely require judgement.

Interfaces: REST and message-based interfaces with versioning, authentication and documented payload contracts.
Reliability: Idempotent operations, retry policies, dead-letter handling and replay tooling.
Visibility: Per-message audit records so that failures can be diagnosed without guesswork.

§ 07Discovery and technical planning

Decisions made before code

Discovery exists to reduce the number of expensive assumptions carried into implementation. It produces written artefacts: a description of the current process, a data model, a list of integration points and constraints, a risk register, and a sequence of increments with defined outputs.

Where a requirement is uncertain, it is resolved with a narrow technical spike rather than a longer debate. Where a constraint is external — a legacy interface, a regulatory obligation, a fixed data format — it is documented as a fact that the design must accommodate.

Overhead view of a planning table with a printed system architecture diagram, annotated notes and a dashboard on a tablet — Fig. 06 — Planning artefacts

§ 08Development process

How work moves

Phase 01
Framing
The problem is described in operational terms: who performs the work today, which systems hold the data, and what a correct outcome looks like.
Phase 02
Architecture
Boundaries, data ownership, integration points and failure modes are drawn before implementation begins, and reviewed against the constraints of existing systems.
Phase 03
Increment
Work proceeds in reviewable increments. Each increment is demonstrable, deployable and accompanied by the tests that describe its behaviour.
Phase 04
Verification
Functional, regression and non-functional checks run against a realistic environment, with defects triaged by impact rather than by discovery order.
Phase 05
Release
Changes reach production through an automated pipeline with migration steps, monitoring in place and a documented path back to the previous state.
Phase 06
Operation
After release the system is observed, tuned and extended. Findings from production feed directly into the next planning cycle.

§ 09Quality assurance and testing

Testing placed where the risk is

A test suite is useful when it fails for real reasons and passes for understandable ones.

Unit tests describe the behaviour of individual rules and calculations. Integration tests exercise the boundaries where components exchange data, including the failure paths. End-to-end tests cover the small number of journeys the business cannot afford to break. Exploratory testing is used where human judgement is faster than specification — new interfaces, unusual data, and edge conditions discovered during development.

Suites run automatically on every change. Defects are recorded with reproduction steps, expected and observed behaviour, and severity assessed by operational impact.

Abstract security visualisation showing a fine data grid crossed by a red scanning line with system check indicators — Fig. 07 — Continuous verification

§ 10Security-aware engineering

Security as a design property

Security decisions are cheapest at design time. Authentication and authorisation models are defined alongside the data model, so that every record has a clear owner and every operation a defined permission.

Input validation and output encoding at trust boundaries
Secrets held in managed stores, never in source control
Least-privilege access to environments and data
Dependency monitoring and scheduled patching
Transport and at-rest encryption as a default posture
Logging of privileged actions for later review

§ 11Maintenance and long-term support

The years after launch

Most of a system's life happens after its first release. Runtimes reach end of support, dependencies publish advisories, data volumes grow past the assumptions of the original design, and the business changes the rules the software encodes.

Support arrangements are defined in writing: what is monitored, how issues are reported and prioritised, how updates are scheduled, and how larger changes are planned. The objective is a system that can be modified confidently for as long as it is needed.

Rows of dark server racks with faint red status indicators in a data centre aisle — Fig. 08 — Running systems

§ 12Illustrative use cases

Scenarios, not case studies

The scenarios below are generic illustrations of the kinds of problems this type of engineering work addresses. They are explanatory examples only. They do not describe completed client projects, and no outcomes, metrics or client identities are implied.

Operations spread across spreadsheets

A team coordinates work through shared spreadsheets that no longer agree with each other. A custom application could hold the authoritative record, enforce the rules currently applied by convention, and expose the same data to every participant.

Two systems that never talk

An order system and a fulfilment system are reconciled manually each day. An integration layer could exchange records automatically, validate them on arrival, and surface only the exceptions requiring human judgement.

A recurring manual report

A monthly report is assembled by exporting, merging and reformatting files. Automation could produce the same report on a schedule from the source systems, with a consistent definition of each figure.

An ageing internal tool

A long-serving internal tool runs on an unsupported runtime with no tests. Incremental modernisation could add coverage around critical behaviour, move deployment onto a pipeline, and replace components one at a time.

A public service under load

A customer-facing application slows at predictable peaks. Profiling, query and index work, caching strategy and infrastructure scaling could address the specific bottlenecks identified by measurement.

A compliance-driven change

A regulatory change alters how a category of data must be stored and accessed. A design review could establish the required model, migration path, access controls and audit trail before implementation.

§ 13Frequently asked questions

Questions answered in full

What kinds of systems does the company build?: Business applications, internal tools, customer-facing web platforms, integration layers between existing systems, and the supporting infrastructure and automation those systems require.
How is a piece of work scoped before development starts?: Through a discovery stage that documents the current process, the systems involved, the data that must move between them, and the constraints that apply. Scope is expressed as a set of increments with defined outputs rather than as a single undivided deliverable.
Which technologies are used?: Technology selection follows the requirements of the system: the data shape, expected load, integration surface, hosting constraints and the skills of the team that will operate it. Mainstream, well-documented and actively maintained tooling is preferred over novel components.
Can work be carried out on an existing codebase?: Yes. Engagements can begin with a review of an existing system, followed by incremental improvement — adding tests around critical behaviour, clarifying boundaries, and modernising deployment before introducing new features.
How is quality assessed?: Through automated test suites executed on every change, code review, manual exploratory testing of new flows, and monitoring of the system in production. Quality criteria are agreed as part of the scope so that they can be checked rather than assumed.
How is security handled during development?: Security is treated as a design property. Authentication and authorisation models are defined early, inputs are validated at trust boundaries, secrets are kept out of source control, dependencies are monitored, and access to production systems is limited and logged.
What happens after a system is delivered?: Support arrangements can cover dependency and platform updates, monitoring and incident response, performance tuning, and a continuing development stream for new requirements. The scope of support is agreed in writing.
How is documentation handled?: Architecture notes, interface documentation, environment setup instructions and operational runbooks are produced alongside the code, so that another engineering team can take ownership of the system if required.
In what language is work conducted?: All documentation, code comments, correspondence and reporting are produced in English.

§ 14Company and contact information