Eleven areas
of engineering
work.

What it includes

• Domain modelling of the process, its states and its exceptions
• Backend services, business rules, scheduled jobs and background processing
• Role and permission structures matched to real job functions
• Migration of existing records from files or legacy databases

Typical deliverables

• Source repository with review history
• Data model and architecture documentation
• Automated test suite and pipeline configuration
• Deployment runbook and user-facing operating notes

Problems addressed

Manual coordination across spreadsheets and inboxes, rules that only exist in someone's head, and processes that cannot be audited because no history is kept.

How the work is approached

The process is mapped with the people performing it, including the cases that break the standard path. A data model is agreed first, then functionality is built in slices that can be used and reviewed while the rest is still in progress.

What it includes

• Component library derived from a shared design system
• Server-rendered pages where indexing or first-load speed matters
• Form-heavy interfaces with validation, drafts and error recovery
• Responsive layouts and keyboard-accessible interaction

Typical deliverables

• Documented component library
• Application code with type checking enabled
• Accessibility and browser support notes
• Performance baseline measurements

Problems addressed

Interfaces that only work on one screen size, slow first loads, inconsistent components across screens, and forms that lose work when a submission fails.

How the work is approached

Interaction and data requirements are defined per screen before layout work. Shared components are built once and reused, so behaviour stays consistent as the application grows.

What it includes

• Network layout, environment separation and access boundaries
• Infrastructure as code definitions for every environment
• Managed database, storage, queue and cache selection
• Backup, restore and scaling procedures

Typical deliverables

• Versioned infrastructure definitions
• Environment and network diagrams
• Backup and restore procedure with test evidence
• Cost breakdown by component

Problems addressed

Environments configured by hand that cannot be rebuilt, unclear cost drivers, and staging setups too different from production to be informative.

How the work is approached

Requirements for availability, data location and recovery time are agreed first, then the smallest architecture that meets them is defined as code. Complexity is added only when a measured constraint requires it.

What it includes

• REST and event-driven interface design with versioning rules
• Schema definition, validation and published documentation
• Transfer logic with retries, idempotency and dead-letter handling
• Reconciliation reporting between connected systems

Typical deliverables

• Machine-readable API specification
• Integration contract documentation
• Monitoring and reconciliation reports
• Sandbox environment for consumer testing

Problems addressed

Integrations that break when a supplier changes a field, duplicated records after a retry, and no way to tell which system holds the correct value.

How the work is approached

A record of reference is chosen per entity, then the contract is written and agreed before implementation. Failure modes — timeouts, partial writes, duplicate deliveries — are designed deliberately and documented for operators.

What it includes

• Architecture and code review of an existing system
• Technical due diligence before acquisition or investment
• Modernisation planning with sequencing and risk assessment
• Vendor and platform evaluation against stated constraints

Typical deliverables

• Written assessment with prioritised findings
• Target architecture outline and migration sequence
• Risk register with mitigations
• Effort ranges per recommendation

Problems addressed

Rewrite proposals without evidence, disagreement between internal teams about the cause of recurring failures, and roadmaps that cannot be delivered with the current architecture.

How the work is approached

Evidence is gathered from the code, the infrastructure, the incident history and interviews with the people operating the system. Findings are ranked by business impact and effort, with the reasoning attached.

What it includes

• Task analysis and interaction design for core workflows
• Design tokens, typography scale and component specifications
• Implementation of the component library in code
• Accessibility review and remediation

Typical deliverables

• Component specifications and usage rules
• Implemented, documented component library
• Interaction and empty/error state definitions
• Accessibility audit notes

Problems addressed

Screens that mirror the database rather than the task, inconsistent controls between modules, and interfaces that force users into workarounds.

How the work is approached

The frequent tasks are identified first and given the shortest path. Layout, states and error handling are specified per component, then implemented once and reused across the application.

What it includes

• Ingestion from applications, files and third-party services
• Transformation layers with tested logic and version control
• Warehouse or analytical store modelling
• Metric definitions and reporting interfaces

Typical deliverables

• Documented pipeline and schedule
• Data dictionary and metric definitions
• Data quality checks with alerting
• Reporting layer with lineage notes

Problems addressed

Dashboards that disagree, metrics defined differently in each query, pipelines that fail silently, and reports produced by hand every month.

How the work is approached

Sources are catalogued and their update behaviour documented. Transformations are written as reviewed, tested code, with metric definitions centralised so a change is made once and applied everywhere.

What it includes

• Test strategy matched to the risk profile of the system
• Unit, integration and end-to-end suites in the pipeline
• Exploratory sessions against written acceptance criteria
• Load, performance and browser or device coverage checks

Typical deliverables

• Test strategy document
• Automated suites integrated into CI
• Defect reports with reproduction steps
• Release readiness checklist

Problems addressed

Regressions discovered by users, releases delayed by manual test cycles, and defect reports that cannot be reproduced.

How the work is approached

Coverage is concentrated where failure is expensive rather than spread evenly. Defects are reproduced, classified by impact, fixed with a regression test and reviewed for the underlying cause.

What it includes

• Threat modelling per system and data classification
• Authentication, authorisation and session design
• Secret management, key rotation and audit logging
• Dependency and container scanning in the pipeline

Typical deliverables

• Threat model and data classification
• Access control matrix
• Logging, monitoring and alerting configuration
• Patch policy and incident procedure

Problems addressed

Broad administrative roles, credentials stored in configuration files, unpatched dependencies, and no record of who changed what.

How the work is approached

Assets, actors and misuse cases are listed, then converted into concrete requirements that enter the same backlog as functional work. Findings from scanning are triaged on an agreed cadence rather than in reaction to incidents.

What it includes

• Audit of current hosting, dependencies and deployment steps
• Containerisation or repackaging of existing applications
• Pipeline construction and environment parity work
• Phased migration with rollback points

Typical deliverables

• Current-state audit
• Infrastructure code for the target environment
• Migration and rollback plan
• Post-migration monitoring configuration

Problems addressed

Deployments that require a specific person, operating systems past end of support, and no way to recreate the server if it is lost.

How the work is approached

The existing setup is documented and reproduced in a new environment before anything is switched. Traffic is moved in stages, with a rollback path defined and tested at each step.

What it includes

• Monitoring, alert thresholds and on-call procedure
• Dependency, runtime and security patching on a schedule
• Incident response, root cause analysis and written review
• Periodic technical review with a prioritised improvement list

Typical deliverables

• Support scope and escalation document
• Monitoring dashboards and alert rules
• Incident reports with follow-up actions
• Quarterly technical review notes

Problems addressed

Software with no owner, ageing dependencies, alerts nobody reads, and improvement work permanently postponed by operational tasks.

How the work is approached

Scope, reporting channels and priority levels are agreed in writing. Operational work and improvement work are tracked separately so neither absorbs the other silently.