Eight engineering services, described plainly.

Purpose

To build applications around a specific operational process when existing products would force that process to change in ways the organisation cannot accept.

Typical scope

Requirements analysis and domain modelling, architecture and data design, iterative implementation, automated testing, deployment configuration, and handover.

Possible deliverables

• Application source code in a repository owned by the client
• Domain and data model documentation
• Automated test suite covering business rules
• Deployment and environment configuration
• Architecture notes recording significant decisions

Purpose

To deliver browser-based products and internal tools that are accessible, responsive and predictable under everyday use.

Typical scope

Interface architecture, component design, state management, server-side rendering or client rendering as appropriate, API design, accessibility review and performance work.

Possible deliverables

• Responsive web application with semantic, accessible markup
• Documented API contracts and validation rules
• Component structure and styling system
• Automated interface and integration tests
• Build pipeline and release configuration

Purpose

To give software a stable, repeatable place to run, with environments that can be rebuilt deliberately rather than reassembled by hand.

Typical scope

Environment design, infrastructure as code, container and runtime configuration, deployment pipelines, observability, backup and recovery planning, and cost review.

Possible deliverables

• Infrastructure definitions held in version control
• Continuous integration and deployment pipelines
• Monitoring, structured logging and alerting configuration
• Backup and restore procedures with documented steps
• Runbook describing routine and emergency operations

Purpose

To make separate systems agree, so that information is entered once and remains consistent wherever it is used.

Typical scope

Interface discovery and documentation, data mapping, authentication and transport design, error and retry strategy, reconciliation, and monitoring of integration health.

Possible deliverables

• Integration services or adapters with defined contracts
• Field-level data mapping documentation
• Retry, idempotency and dead-letter handling
• Reconciliation reporting for mismatched records
• Alerting on integration failure conditions

Purpose

To remove repetitive manual steps from a process while keeping it auditable and keeping people in control of the exceptions.

Typical scope

Process mapping, rule definition, scheduled or event-driven execution design, exception handling, audit logging, and operational reporting.

Possible deliverables

• Automated process implementation with defined triggers
• Documented business rules and exception paths
• Audit log of automated actions
• Operational dashboard or reporting output
• Handover guide for the team responsible for the process

Purpose

To find defects before users do, and to keep a codebase safe to change as it grows.

Typical scope

Test strategy, automated unit, integration and end-to-end suites, exploratory test sessions, accessibility checks, performance testing, and defect triage.

Possible deliverables

• Written test strategy matched to the risk profile of the system
• Automated test suites running in the delivery pipeline
• Exploratory testing notes and reproducible defect reports
• Accessibility and performance findings with recommended fixes
• Release verification checklist

Purpose

To support decisions about architecture, technology selection, or the direction of an existing system, with reasoning rather than assertion.

Typical scope

Codebase and architecture review, technology assessment, modernisation planning, delivery process review, and second-opinion analysis on proposed designs.

Possible deliverables

• Written assessment of the current system and its constraints
• Options with trade-offs, risks and indicative effort
• Prioritised recommendations with a sequencing proposal
• Architecture decision records for agreed choices
• Review session with the client's technical stakeholders

Purpose

To keep delivered software correct, secure and useful as dependencies, platforms and business needs move on.

Typical scope

Defect correction, dependency and security updates, performance monitoring, small enhancements, and periodic technical review of the system as a whole.

Possible deliverables

• Agreed maintenance scope and working arrangements
• Applied dependency, runtime and security updates
• Defect fixes with root-cause notes
• Periodic health report covering errors, performance and cost
• Updated documentation reflecting every change made