Services

Nine areas of technical work, described in full

Each service below states its scope, our approach, the situations it suits and the value it is expected to produce. Where an outcome depends on your context, we say so instead of promising a figure.

00Index

One practice, applied at different points in a system's life

Structured fibre optic cabling connected to a numbered patch panel

01Custom software development
02Web application development
03Cloud solutions
04System architecture
05API and systems integration
06Legacy software modernisation
07Technical consulting
08Quality assurance
09Maintenance and technical support

01Service

Custom software development

Applications and services built for a specific operational process rather than adapted from a generic product.

Scope

Requirement analysis and domain modelling
Backend services, business logic and data storage
User interfaces for internal or external users
Automated tests, deployment pipeline and documentation

Approach: We start from the process as it runs today, including its exceptions, and model the data before designing screens. Development proceeds in increments that are individually deployable, so the system becomes usable long before it is complete.
Suitable use cases: Processes currently held together by spreadsheets and manual coordination, or products where the core logic is a competitive concern and cannot be outsourced to an off-the-shelf tool.
Expected value: A system that matches how the work is actually done, with the source, tests and documentation under your control.

02Service

Web application development

Browser-based applications where interface behaviour, performance and accessibility are treated as engineering requirements.

Scope

Component architecture and design-token systems
State management, routing and form handling
Server-side rendering, caching and asset strategy
Accessibility and cross-browser verification

Approach: Interfaces are assembled from a small, documented component set with defined states, including empty, loading and error. Performance budgets and keyboard operation are checked as part of development rather than after release.
Suitable use cases: Customer portals, internal tools handling large data sets, and applications that must remain usable on constrained networks and devices.
Expected value: An interface that stays consistent as it grows, is usable without a mouse, and does not degrade as features are added.

03Service

Cloud solutions

Design and automation of the environments your software runs in, with reproducibility and cost visibility as first requirements.

Scope

Environment topology for development, staging and production
Infrastructure as code and configuration management
Containerised workloads, networking and access policy
Backup, restore and disaster-recovery procedures

Approach: Every environment is described in version-controlled definitions so it can be rebuilt from scratch. Access follows least privilege, secrets are stored in managed vaults, and cost is attributed to workloads rather than appearing as one monthly figure.
Suitable use cases: Teams whose infrastructure grew manually, organisations migrating from self-managed servers, or systems whose running costs have become difficult to explain.
Expected value: Environments that can be recreated and audited, with predictable deployments and understandable spend.

04Service

System architecture

The decisions that determine how a system behaves under change, load and failure — made explicitly and written down.

Scope

Component decomposition and ownership of data
Interface contracts, versioning and data flow
Consistency, transaction and failure-handling strategy
Architecture decision records and diagrams

Approach: We work from concrete requirements: expected volumes, acceptable latency, tolerance for downtime and expected directions of change. Each significant decision is recorded with the alternatives considered, so future engineers can revisit it with context.
Suitable use cases: New systems before implementation begins, and existing systems where every change now touches too many components.
Expected value: A structure that supports the next two years of change instead of resisting it, and documentation that survives staff turnover.

05Service

API and systems integration

Reliable movement of data between internal systems and third-party services, including the failure cases.

Scope

Integration mapping and source-of-truth definition
REST, GraphQL, webhook and message-based interfaces
Transformation, validation and reconciliation logic
Retry, idempotency and monitoring of data flows

Approach: We first decide where each fact lives and which system may change it. Interfaces are then built with explicit schemas, idempotent operations and reconciliation so that a temporary outage does not create silent divergence.
Suitable use cases: Organisations running several systems that each hold part of the truth, or projects blocked by a partner API with unclear behaviour.
Expected value: Consistent data across systems, fewer manual corrections, and integrations whose state can be inspected when something goes wrong.

06Service

Legacy software modernisation

Incremental replacement or restructuring of systems that still carry real work but have become costly to change.

Scope

Assessment of code, data, dependencies and operational risk
Characterisation tests to capture current behaviour
Stepwise extraction of components behind stable interfaces
Data migration planning and verification

Approach: Nothing is rewritten wholesale. We capture existing behaviour in tests, place a boundary around the part being replaced, run old and new paths together where possible, and switch traffic once results match. Each step is independently reversible.
Suitable use cases: Systems whose original authors have moved on, platforms tied to unsupported runtimes, and applications where a full rewrite has already been attempted and abandoned.
Expected value: Reduced technical risk and lower change cost without a freeze on business operations.

07Service

Technical consulting

Independent examination of an architecture, codebase or delivery practice, ending in findings you can act on.

Scope

Architecture and codebase review
Delivery, testing and release practice assessment
Technology selection and build-versus-buy analysis
Written report with prioritised findings and options

Approach: We read the code, the pipelines and the incident history rather than relying on interviews alone. Findings are ranked by risk and effort, and each one names the evidence behind it. Where we are uncertain, the report says so.
Suitable use cases: Decisions with long consequences: choosing a platform, evaluating a supplier's work, planning a rebuild, or diagnosing why delivery has slowed.
Expected value: A clear technical picture and a defensible basis for the next decision, independent of who would implement it.

08Service

Quality assurance

Testing designed around the behaviour that matters, automated where repetition makes it worthwhile.

Scope

Test strategy across unit, integration and end-to-end levels
Automated suites running in the delivery pipeline
Exploratory testing of critical and edge-case paths
Performance, load and regression verification

Approach: Tests are written to describe behaviour, not implementation, so they survive refactoring. Coverage is directed at logic with real consequences — money, permissions, data integrity — rather than pursued as a number.
Suitable use cases: Products where a defect has direct financial or legal cost, systems undergoing modernisation, and teams whose releases require lengthy manual checking.
Expected value: Faster releases with fewer regressions, and a suite that tells you what broke instead of that something did.

09Service

Maintenance and technical support

Ongoing responsibility for a running system: monitoring, corrective work, dependency updates and planned change.

Scope

Monitoring, alerting and structured logging
Defect diagnosis and correction
Dependency, runtime and security updates
Small planned improvements on an agreed cadence

Approach: Support is defined in writing: what is monitored, how issues are reported, how they are prioritised and what we commit to. Recurring incidents are treated as design problems and fixed at the source rather than absorbed as routine.
Suitable use cases: Systems without a dedicated internal team, or teams who need a second pair of hands for operational work while they focus on new development.
Expected value: A system that stays current and observable, with issues addressed at their cause instead of repeatedly patched.

10Engagement

How an engagement usually starts

Most work begins with a short assessment: we read what exists, ask a limited number of precise questions and produce a written view of the problem, the options and the risks. That document is useful even if we do not continue together.

Delivery is then agreed in increments with defined outputs. Scope that is uncertain stays explicitly uncertain until it can be examined, rather than being priced as if it were known.

Written enquiries go to [email protected].

Data centre aisle with server cabinets receding towards a lit doorway