thechillijacket.com
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
§ 01Introduction
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
01
Server-side services, data models, background processing and user-facing interfaces built as one coherent system rather than assembled from disconnected parts.
02
Relational schemas, migrations, indexing strategies and reporting structures designed around how information is actually queried and changed over time.
03
Documented, versioned interfaces that allow internal teams and external partners to exchange data predictably, with clear error semantics.
04
Environment definitions, deployment pipelines, observability and rollback paths so that releases are repeatable and reversible.
05
Scheduled jobs, event-driven workflows and rule engines that remove repetitive manual steps from operational processes.
06
Automated and exploratory testing applied at the level where each risk actually lives, from unit behaviour to end-to-end flows.
§ 03Custom software development
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.
§ 04Web application engineering
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
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.
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.
§ 06Systems integration and automation
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.
§ 07Discovery and technical planning
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.
§ 08Development process
Phase 01
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
Boundaries, data ownership, integration points and failure modes are drawn before implementation begins, and reviewed against the constraints of existing systems.
Phase 03
Work proceeds in reviewable increments. Each increment is demonstrable, deployable and accompanied by the tests that describe its behaviour.
Phase 04
Functional, regression and non-functional checks run against a realistic environment, with defects triaged by impact rather than by discovery order.
Phase 05
Changes reach production through an automated pipeline with migration steps, monitoring in place and a documented path back to the previous state.
Phase 06
After release the system is observed, tuned and extended. Findings from production feed directly into the next planning cycle.
§ 09Quality assurance and testing
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.
§ 10Security-aware engineering
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.
§ 11Maintenance and long-term support
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.
§ 12Illustrative use cases
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.
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.
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 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.
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 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 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
§ 14Company and contact information
Written enquiries about software development and technology services are welcome by email. All details below are provided as plain text.