Services
Eight areas of work, each with a defined output. Where a service does not fit your situation we will say so instead of stretching the definition.
Detail
01
Applications designed around a specific operational process rather than a generic template. We start from how work is actually carried out, model the data that process produces, and build the system that supports it.
Deliverables include the application source, database schema and migrations, automated tests, deployment configuration and written operating documentation.
02
Browser-based systems built for accessibility, keyboard operation and predictable performance on ordinary connections and devices.
We use semantic markup, server-rendered content where it benefits users and search engines, and state management that keeps behaviour explainable as an application grows.
03
Environments defined as code so they can be created, destroyed and recreated identically. Networking, access control, deployment pipelines and backups are part of the definition, not manual afterthoughts.
Monitoring, log aggregation and alerting are configured so that the operating team learns about failures before users do.
04
Interfaces between internal applications, databases and third-party services. We define the data contract first, then handle the unglamorous parts properly: retries, idempotency, error routing and audit records.
Where an external service is unreliable or rate limited, integration is designed to degrade in a controlled way rather than fail silently.
05
Incremental improvement of systems that still deliver value but have become difficult to change. We begin by establishing tests and observability around existing behaviour, then replace components one at a time.
A full rewrite is proposed only when the cost of incremental work clearly exceeds it, and the reasoning is written down before anything is discarded.
06
Independent review of architecture, delivery practice, infrastructure or a proposed technology choice, returned as a written assessment with options and trade-offs.
The output is intended to be usable by your own team without further involvement from us.
07
Corrective, adaptive and preventive work on systems already in production: dependency updates, security patches, performance work and small feature changes.
Response expectations, working hours and escalation are agreed in writing at the start of the arrangement rather than assumed.
08
Test strategy proportionate to risk: unit and integration coverage for logic, end-to-end checks for critical journeys, and manual exploration where judgement is required.
Test suites run automatically on every change, and release decisions are made against their results.
Delivery methodology
Every engagement follows the same skeleton: understand, write down, build a small piece, verify it, review it together, then repeat. The length of a cycle varies with the project; the shape does not.
Each cycle ends with something running in a shared environment and a short written summary of what changed, what was learned and what the next cycle addresses.
Nothing is declared finished on the basis of a demonstration alone. A change is complete when it is tested, reviewed, documented and deployable.
Quality principles
Any environment can be rebuilt from version-controlled definitions.
Every change links to a reason, a review and a release.
Testing and process effort match the risk of the component involved.
Work is done as if another team will inherit it tomorrow.
Engagement approach
01
You describe the situation in writing. We ask questions and confirm whether we are a sensible fit.
02
A written description of the first increment, the collaboration model, responsibilities and commercial terms.
03
Access is arranged narrowly, environments are prepared, and the first cycle begins against the agreed scope.
Yes, provided we are given access to the source, the infrastructure and whatever documentation exists. We normally begin with a short assessment period before committing to ongoing work.
Pricing is agreed per engagement in writing, based on the scope note and the collaboration model chosen. We do not publish rate cards because scope, duration and responsibility vary too widely between projects.
Support is available as a separate arrangement with agreed scope and response expectations. It is optional: systems are handed over in a state that allows another team to maintain them.
The scope note is revised and the change is priced and scheduled explicitly. Changes are normal; absorbing them silently is what causes projects to drift.
Access is requested narrowly, tied to named individuals, and revoked when the work requiring it ends. Credentials are held in managed secret storage and never committed to source control.