Sheet S — Service specification

IT services provided by CHAIRBEARS HUNTON LTD

Ten service areas covering the life of a business system: designing and building it, connecting it to everything else, keeping it secure and tested, and looking after it once it is in daily use. Each entry below states what the service includes, where it typically applies, how the work is carried out and what kind of result it is reasonable to expect.

S-01
Custom software development
S-02
Web application development
S-03
Cloud and infrastructure solutions
S-04
Systems integration
S-05
Technical consulting
S-06
Software modernisation
S-07
Quality assurance
S-08
Maintenance and technical support
S-09
Cybersecurity-conscious engineering
S-10
Data and automation solutions

S-01

Custom software development

Applications designed for a specific operational process where off-the-shelf products either do not fit or would require more configuration and workaround than a purpose-built system.

What it includes

Requirements analysis and written functional specification
Domain and data modelling, including migration from existing records
Server-side application logic, scheduled processing and administrative tooling
User interfaces built around the tasks staff actually perform
Automated tests, deployment pipeline and technical documentation

Typical business use cases

Replacing a spreadsheet-based process that has outgrown its format
Internal tools for scheduling, approvals, case handling or asset tracking
Customer-facing portals that must reflect internal data accurately
Software that encodes rules specific to one organisation's obligations

Delivery approach

Discovery establishes the process and its exceptions. A specification defines scope and acceptance criteria. Implementation proceeds in reviewed increments with working software available throughout, followed by verification against the agreed criteria and a documented handover.

Expected types of outcome

Typically a system that matches the process without workarounds, reduces manual re-entry of data, and can be extended later because its structure and tests are documented. Actual results depend on the organisation's own processes and adoption.

S-02

Web application development

Browser-based applications with genuine state, permissions and workflow — the kind of software people use for hours a day rather than visit occasionally.

Delivery approach

Interface structure is agreed against real tasks before visual detail is settled. Screens are built and reviewed in sequence, with the underlying interfaces developed alongside so that each screen works against real data rather than mock-ups.

Expected types of outcome

Applications that staff can use without training documents for every screen, with permissions enforced consistently and a codebase that supports later change. Outcomes vary with the complexity of the workflow being supported.

What it includes

Front-end architecture with predictable state handling and accessible interaction
Authentication, roles and permission enforcement on the server
Responsive layouts tested across desktop, tablet and mobile
Performance work on payload size, rendering and query behaviour
Accessibility considerations including keyboard operation and contrast

Typical business use cases

Internal dashboards consolidating data from several systems
Multi-role applications where each role sees a different slice of the data
Client portals for submitting, tracking and retrieving records
Replacing a desktop application that must now be reachable remotely

S-03

Cloud and infrastructure solutions

Hosting environments that can be rebuilt from their definitions, sized against measured load, and operated without undocumented manual steps.

What it includes

Environment definitions kept in version control
Build and release pipelines with reproducible artefacts
Network, access and secret management arrangements
Backup configuration, with restores tested rather than assumed
Monitoring, alerting and log aggregation chosen around real operational questions

Typical business use cases

Moving an application off a single unmanaged server
Separating development, testing and production properly
Reducing hosting cost by matching resources to observed usage
Establishing a release process that does not depend on one individual

Delivery approach

The current environment is documented first, including the parts that exist only in someone's memory. A target design is agreed, built alongside the existing setup, and migrated with a tested rollback path rather than a single cut-over.

Expected types of outcome

Environments that can be recreated, releases that are routine rather than events, and clearer visibility of cost and load. Specific savings or uptime figures depend entirely on the starting position and workload.

S-04

Systems integration

Getting applications that were never designed together to exchange data reliably, including legacy systems and third-party services with imperfect interfaces.

What it includes

Interface analysis of each system, including undocumented behaviour
Mapping and transformation rules between differing data models
Synchronous APIs or message-based exchange, chosen to fit the reliability requirement
Error handling, retries, idempotency and reconciliation reporting
Monitoring so that a failed exchange is noticed before a user reports it

Typical business use cases

Connecting an accounting package with an operational or e-commerce system
Feeding a reporting platform from several transactional sources
Replacing manual file transfers or re-keying between departments
Adding a third-party service such as payments, messaging or document handling

Delivery approach

Integration starts with agreement on the source of truth for each field and on what should happen when systems disagree. Exchanges are built to be repeatable and safe to re-run, then validated against real data volumes before going live.

Expected types of outcome

Fewer discrepancies between systems, less manual transfer work, and failures that are visible and recoverable. The degree of improvement depends on the quality of the interfaces the existing systems provide.

S-AEngineering context

Blueprint schematic of a cloud hosting topology with firewalls, switching layers, server racks and storage clusters — Fig. S1 — Hosting and network layout

Services combine rather than compete

A single engagement rarely fits one category. Building a new application involves infrastructure, testing and eventually support; an integration project usually exposes data quality work; modernisation almost always begins with consulting. The categories exist to describe the work clearly, not to divide an engagement into separately priced parts.

Where only part of a system is within scope, the boundaries are written down: which components are being changed, which are being left alone, and who is responsible for each after delivery.

S-05

Technical consulting

Independent assessment of architecture, delivery practice and technical risk, delivered as a written report rather than a presentation.

What it includes

Review of architecture, codebase structure and data model
Assessment of delivery practice: testing, review, release and environments
Identification of technical risk, including single points of knowledge
Options analysis with cost, effort and consequence for each path
Prioritised recommendations that can be acted on incrementally

Typical business use cases

Deciding whether to repair, rebuild or replace an existing system
Technical due diligence before committing to a large piece of work
Understanding why delivery has slowed as a codebase has grown
Getting a second opinion on a proposal from another supplier

Delivery approach

Consulting is time-boxed and scoped in advance. It combines reading the system, examining its history and interviewing the people who build and operate it. Findings are shared in draft so that factual errors can be corrected before the report is finalised.

Expected types of outcome

A clear written basis for a decision, with the reasoning visible so that it can be challenged. Consulting produces understanding and options; it does not by itself change the system.

S-06

Software modernisation

Bringing ageing systems back under control incrementally, while they remain in production and in daily use.

What it includes

Behaviour mapping of the existing system before any change
Characterisation tests that capture current behaviour as a safety net
Dependency and runtime upgrades carried out in controlled steps
Structural refactoring, and gradual replacement of components behind stable interfaces
Documentation produced as understanding is recovered

Typical business use cases

Software running on an unsupported framework or runtime version
Systems where the original developers are no longer available
Codebases where a small change routinely causes unrelated failures
Preparing a monolithic application for partial replacement

Delivery approach

Modernisation avoids a full rewrite wherever the existing system still encodes valuable business rules. Work proceeds in small, reversible steps, each deployed and observed before the next begins, so the service stays available throughout.

Expected types of outcome

A system that can be changed with reasonable confidence, with supported dependencies and recorded knowledge. Timescales depend heavily on the size and condition of the existing code.

S-07

Quality assurance

Testing arranged around the behaviour that carries business risk, combining automation with targeted manual examination.

Delivery approach

Testing is planned from the risk profile of the system rather than from a coverage target. Automated checks run in the pipeline so that failures block a release, and manual testing is reserved for judgement-based questions.

Expected types of outcome

Defects found earlier and closer to their cause, and releases that carry less uncertainty. No testing approach can demonstrate the absence of defects, and none is presented as doing so.

What it includes

Unit and integration tests covering core domain logic
End-to-end tests for the workflows that must never break
Regression suites executed automatically on every change
Exploratory and edge-case testing, including awkward real-world data
Defect triage with reproduction steps and root-cause analysis

Typical business use cases

Establishing test coverage on a system that has none
Stabilising a release process where each deployment causes incidents
Validating a data migration before it becomes irreversible
Checking behaviour across browsers, devices and screen sizes

S-BVerification

Every service passes through the same delivery discipline

Regardless of the category, work moves through discovery, written specification, incremental implementation, verification against agreed criteria, and documented handover. The proportions differ — a consulting engagement is mostly discovery, a support arrangement mostly incremental change — but the sequence and the record-keeping do not.

Blueprint diagram of sequential delivery stages, each with a verification checkpoint before the next — Fig. S2 — Stage gates across the delivery sequence

S-08

Maintenance and technical support

Ongoing care of a running system: correction, updates, small improvements and help when something behaves unexpectedly.

Delivery approach

Support arrangements set out in advance what is covered, how requests are submitted and how they are prioritised. Work is logged so that recurring problems become visible and can be addressed at their root.

Expected types of outcome

Systems that stay current and predictable, with issues addressed in an orderly way instead of accumulating. Response expectations are agreed in the arrangement rather than implied.

What it includes

Investigation and correction of reported defects
Security and dependency updates applied on a regular cycle
Monitoring review and adjustment as usage patterns change
Small enhancements and configuration changes as needs evolve
Assistance to the client's own staff on operational questions

Typical business use cases

Keeping a delivered system healthy after handover
Supporting software whose original supplier is no longer involved
Providing continuity where an organisation has no in-house developer
Managing a backlog of small improvements without a full project

S-09

Cybersecurity-conscious engineering

Security handled as an ordinary part of design and implementation, rather than as an inspection performed after the system is finished.

What it includes

Threat consideration during design: who could misuse this, and how
Authentication and server-side authorisation modelled on real roles
Input validation, output encoding and safe handling of untrusted data
Secret management, credential rotation and least-privilege access
Dependency tracking and prompt application of security updates
Audit logging sufficient to reconstruct what happened after an incident

Typical business use cases

Applications handling personal, financial or commercially sensitive data
Systems exposed to the public internet or to third-party integrations
Preparing a system for a client or regulatory security review
Correcting weaknesses identified by an external assessment

Delivery approach

Security requirements are captured with functional ones and verified in the same way. Where a formal penetration test or certification is required, the work is prepared so that the assessment examines a system built with those concerns in mind.

Expected types of outcome

A reduced likelihood of common, avoidable weaknesses and clearer control over access and data. No engineering practice can eliminate security risk, and none is offered as a guarantee.

S-10

Data and automation solutions

Pipelines, reporting structures and the removal of repetitive manual steps from routine operational work.

What it includes

Extraction and consolidation of data from operational systems
Cleaning, validation and transformation with documented rules
Reporting structures separated from transactional workloads
Scheduled automation of recurring tasks, with failure alerting
Interfaces that let non-technical staff retrieve answers themselves

Typical business use cases

Monthly reports currently assembled by hand from several exports
Reconciliation between systems that hold overlapping records
Routine file processing, notification or document generation
Making operational data available for analysis without risking production

Delivery approach

Work begins with the questions the organisation needs answered and traces backwards to the data required. Pipelines are built to be re-runnable and observable, so that a bad input can be corrected and reprocessed rather than patched by hand.

Expected types of outcome

Time recovered from repetitive work and figures that reconcile between systems. The value obtained depends on the quality and completeness of the source data.

S-CData and operations

Blueprint of a data pipeline linking source systems, transformation stages, storage and reporting outputs — Fig. S3 — Source-to-report data path

Notebook with hand-drawn service diagrams open beside a keyboard and terminal at an engineer's desk — Fig. S4 — Design notes preceding implementation

S-DContact

Contact information

Written enquiries are the quickest route to a considered answer. Describe the system, the problem and the constraints you are working within, and the reply will address them directly.

Company: CHAIRBEARS HUNTON LTD
Email: edwinphillips19948@gmail.com