Skip to content

Delivery model

A delivery model you can inspect at every stage

Digital systems fail more often through unclear scope and untested assumptions than through technology. Our process is built to remove both early.

Phases

Five phases, each with a gate

  1. 01

    Discover

    Objectives, constraints, existing systems and the decision the work must support.

    Written scope agreed before build

  2. 02

    Design

    Structure, interface and data contracts defined before implementation begins.

    Client review of structure and direction

  3. 03

    Build

    Typed, reviewable implementation in small increments against real cases.

    Working increments, not slide decks

  4. 04

    Integrate

    Connection to live systems with staging and production kept clearly separate.

    Verification before anything goes live

  5. 05

    Improve

    Measure, correct and extend once the system is carrying real work.

    Agreed maintenance and support terms

Principles

How we make decisions

Structure before surface

Content model, data contracts and states are decided before visual polish, so the design has something real to express.

Small verifiable increments

Work is delivered as working slices you can open and judge, rather than a long silent build followed by a reveal.

Evidence over assertion

Claims about performance, quality or completeness are backed by something checkable: a test, a measurement, a log.

Human approval where it matters

Automation and AI assist the work. Decisions with commercial, legal or safety weight keep a named human gate.

Built for handover

Typed components, consistent naming and a clean repository structure so your team or another developer can continue.

Separate environments

Staging and production are visibly different. Nothing experimental is left running quietly against live data.

Engagement

How work is scoped and billed

  • One-off build phases are scoped, quoted and delivered against a written scope.
  • Ongoing maintenance, hosting supervision and improvement work is handled on a retainer.
  • Changes outside an agreed scope are raised before they are built, not after.
  • Access to accounts, domains and repositories is documented and returned at handover.

Ready to scope something?

A project brief gives us enough to propose a sensible first phase, or to tell you honestly that a smaller step would serve you better.

Start a project briefRead the Hapis delivery constitution