Builds

Software designed for the people who run it after launch.

A build includes more than screens. We define information ownership, integrations, administrative paths, release evidence, recovery needs and the transition into support.

Engineers reviewing application components and release checks

Build anatomy

From a controlled slice to an operable service.

The first release should prove the hardest assumptions without creating an unmaintainable shortcut. We identify a vertical slice—interface, business rule, data path and deployment—that can be demonstrated and tested end to end.

Subsequent increments add journeys against agreed acceptance notes. Each review records decisions, defects and scope movement. Before production, named owners accept operational readiness: monitoring, backups where relevant, permissions, data migration checks, incident contacts and rollback.

WorkstreamWorking artefactsGate

ExperienceJourney maps, content model, accessible prototypes, edge-state copyRepresentative users can complete critical tasks

ApplicationVersioned source, test evidence, dependency register, environment notesAcceptance criteria pass in agreed environment

Data & integrationData map, validation rules, migration rehearsal, interface contractsReconciliation and failure paths are evidenced

OperationsRunbook, dashboards, access matrix, restore or rollback notesNamed owner accepts readiness and escalation path

Quality boundary

Controls proportional to consequence.

A public information page and a student-record workflow do not carry the same risk. We scale review depth according to data sensitivity, privilege, integration complexity, user impact and reversibility.

Peer review for material code and configuration
Environment-specific secret handling
Role and permission tests for protected workflows
Dependency and release record at handover
Known limitations written in plain language

Support boundary

Handover is a planned workstream.

Training is based on real operating scenarios, not a feature tour. We agree who receives incidents, what information a useful report contains and which changes move back into a separately estimated backlog.

Coverage, response targets and support term are stated in the proposal. Unless contracted, support is not continuous monitoring or 24-hour incident response.