The delivery approach
From business need to production system — visual from the start, approved at every gate, and delivered as working software you review as it lands.
This is the detail behind step 03 of how I work — what happens when the right answer turns out to be a custom build.
01 / The principles
Four rules that stop projects going wrong.
Software projects fail for predictable reasons: the wrong thing gets built, scope is discovered too late, or you only see the product when it is too expensive to change course. Everything below is designed around preventing those failures.
See it before you build it
Mockups and workflows appear before requirements are locked. Changing a mockup is cheap; changing a system is not.
Decision gates, not surprises
The project pauses at explicit approval points. Nothing proceeds to the next, more expensive phase without your go-ahead.
Estimates that get honest
An indicative estimate early, deliberately revisited once detailed requirements exist — you always know which is which.
Fast, with layered quality
AI-accelerated engineering, with architecture, security, testing and UX review on every change — and every significant decision written down.
02 / The journey
Sixteen steps, start to finish.
Discover
Steps 1–2Understand the business before the system.
Ingest existing materials
Briefs, spreadsheets, process notes, screenshots of current systems — everything you already have is collected and analysed, so nothing has to be said twice.
Initial analysis session Client touchpoint
A working session on the business drivers, the key functionality, the roles who will use the system, and the timelines that matter — the why, not just the what.
Envision
Steps 3–5A concrete, visual view of the solution — early enough that corrections cost nothing.
Key mockups & workflow
Realistic, styled mockups of the key screens, plus a workflow view of how each role moves through the system — produced quickly, and reliably surfacing gaps a written document never would.
Initial estimate
Indicative effort and cost, with its assumptions stated — revisited after detailed requirements (steps 7–9), because detail always surfaces functionality that wasn't visible at the start.
Walkthrough Client touchpoint
A guided walkthrough of the mockups, workflow and estimate. Gaps found here are cheap to fix.
Gate — approve solution design
Step 6Approval to proceed Approval gate
An explicit go/no-go before the detailed definition work is funded. No design spend without it.
Define
Steps 7–9The detail that will drive development — requirements, refined mockups, and the breakdown into deliverable pieces.
Product requirements documents Client touchpoint
Feature-by-feature discovery sessions produce detailed requirements and refined mockups, with every significant decision captured in a short written record.
Epic & story definition
The work is broken into stories of a day to two weeks each, grouped into epics — the level you review, test, and pay against.
Compiled requirements
The final agreed definition of what is to be built and paid for — the reference point for any later scope discussion. It protects both of us.
Commit
Steps 10–11Scope, time, cost, and obligations — the full package for confirmation.
Project delivery plan
An epic-based timeline, plus your obligations named with dates — availability for clarifications, and things like DNS, hosting, email, and credentials for anything the system integrates with. These are the most common cause of slip, so they go in writing up front.
Updated estimate & agreement Approval to build
The final agreed cost, with scope and time alongside it. Your approval here is the approval to build.
Build
Step 12 — repeating per epicWorking software delivered epic by epic — no long silence followed by a big reveal.
Implementation by epics Epic reviews Progress payments
You review and accept each epic on a staging environment as it lands, and progress payments are tied to that acceptance — you pay for what has been delivered. Under the hood, every change passes automated tests plus architecture, security, quality and UX review before it is accepted. Changes to scope are welcome: they are estimated and agreed in writing, never absorbed invisibly. A brief status update arrives at an agreed cadence, typically weekly.
Review · accept · pay — repeated per epic until complete
Launch
Steps 13–15A fixed, predictable path from acceptance to live.
User acceptance testing Client touchpoint
A fixed two-to-four-week window to confirm the system is ready. Genuine defects are fixed inside it; new ideas are recorded for the roadmap rather than delaying release.
Production release Go-live approval
Migration to production — data, DNS cutover, and a documented rollback plan.
Hypercare
For a defined period after go-live — typically five to ten business days — I am on call and quickly accessible, with response expectations agreed before release.
Beyond
Step 16Retrospective & roadmap Workshop
A short workshop on what worked, what didn't, and what's next — the roadmap of future enhancements identified along the way, and an ongoing support arrangement if you want one.
Working software.
No surprises.
That is the whole system: you see the solution before you fund the design, you approve the cost before I build, and you review working software as it lands. If that sounds like how a project should run, let's talk.