Services
Six ways the
work is scoped.
Each description below sets out the situation it usually addresses, the kinds of deliverables involved, and the working approach. Scope is agreed per engagement; none of it implies a fixed outcome or timeline.
01
Custom software development
Typical need
An organisation's process does not fit the tools available, and the gap is being covered by spreadsheets, manual re-entry or workarounds that only a few people understand.
Possible deliverables
- Domain model and data schema documentation
- Application source in a version-controlled repository
- Automated test suite covering agreed behaviour
- Deployment configuration and environment setup
- Architecture notes and decision records
Working approach
The work starts with the rules that make the business distinctive and builds the smallest complete system that expresses them. Later features extend a working foundation, and each cycle ends with software that can be deployed.
02
Web application development
Typical need
A portal, internal tool, dashboard or platform is needed that several groups can use from different devices, with reliable access control and shareable addresses for each view.
Possible deliverables
- Responsive interface built from a consistent component set
- Server-rendered routes with real URLs and correct metadata
- Authentication and role-based access rules
- Accessibility and performance checks as part of the build
Working approach
Interface structure is agreed through low-fidelity layouts before styling. Components are built once and reused, and behaviour under slow networks, small screens and keyboard-only use is checked during development.
03
Cloud and infrastructure engineering
Typical need
Deployments are manual or fragile, environments drift apart, or there is no reliable picture of what the system is doing in production.
Possible deliverables
- Infrastructure described as code
- Continuous integration and deployment pipelines
- Logging, metrics and alerting configured to real failure modes
- Backup, restore and rollback procedures, documented and tested
Working approach
Existing setup is reviewed first, then moved piece by piece into reproducible definitions. Changes are introduced so that the running service stays available, and each procedure is exercised at least once before it is relied upon.
04
API development and systems integration
Typical need
Two or more systems need to exchange data reliably, or an external partner needs a documented way to interact with an internal service.
Possible deliverables
- Interface specification with versioning and error semantics
- Implementation with validation, authentication and rate controls
- Integration adapters for third-party services
- Reference documentation and example requests
Working approach
The contract is agreed before implementation. Failure behaviour — timeouts, retries, duplicate delivery, partial success — is designed explicitly rather than discovered in production, and every exchange is logged in a way that supports later reconciliation.
05
Workflow automation
Typical need
Staff spend recurring time on transfers, reconciliations, report generation or notifications that follow predictable rules.
Possible deliverables
- Written description of the current process and its exceptions
- Scheduled or event-driven automation for the agreed steps
- Audit records for every run, including failures
- Manual override paths where judgement is still required
Working approach
The existing process is mapped with the people who perform it, including the exceptions they handle informally. Automation is introduced step by step, running alongside the manual process until the results agree.
06
Software maintenance and technical consulting
Typical need
A system already exists but is difficult to change, its original authors are unavailable, or a decision about its future needs an independent technical view.
Possible deliverables
- Written review of architecture, dependencies, data and deployment
- Prioritised list of risks with proposed remediation
- Ongoing defect correction and dependency updates
- Advisory input on architecture, tooling or hiring decisions
Working approach
Review comes before change. Findings are written down with severity and effort so the organisation can decide what to address, and remediation proceeds in small, reversible steps with tests added around the areas being touched.
Engagement shape
Scope is agreed before work begins.
Engagements can be organised as a discovery phase, a defined build, or continuing maintenance. Whichever shape applies, the scope, the sequence of deliverables and the assumptions behind any estimate are written down and revised together as the work proceeds.
Not included
What these descriptions do not claim.
Nothing on this page promises a specific delivery date, cost, performance figure, uptime level or commercial result. Those depend on the particular problem, the systems involved and the decisions made together, and are set out in writing for each engagement.