Six phases, and the first one can conclude that the project you came in asking for is not the one worth doing. That is the point of running it in this order.
You work directly with the engineer doing the build
Scope and exclusions in writing before anything starts
Your code, accounts, and data at every phase
01
Diagnose
Find the constraint before proposing anything.
5 business days
Nine diagnostic checkpoints across the seven-layer growth system, reviewed against how the business actually runs. I measure rather than assume: first-response time across recent enquiries, what analytics is and is not recording, where inquiries go, and what the site asks a visitor to believe.
What you get
A written review of all nine diagnostic checkpoints
The highest-priority constraints supported by the available evidence
A costed plan you could execute with anyone
A 30-minute walkthrough call
What I need from you
Your website
Read access to analytics and CRM if they exist
A description of how enquiries reach you
02
Map
Design the system on paper before building it in code.
1–2 weeks
A diagram of the current path and the intended one, the scope of what will change, the measures we will judge it by, and a timeline. If part of what you asked for is not worth doing, it is written down here rather than discovered halfway through the build.
What you get
A system map of current and target state
Written scope with explicit exclusions
The baseline measures we will judge the work against
A timeline with dependencies named
What I need from you
Decisions on scope
Access to the tools in scope
One named person who can approve
03
Build
Design, write, and engineer the parts that change.
4–10 weeks
Interface design, copy, and engineering happen in the same pass, by the same person, so the argument does not get lost between a copy document and a component library. Progress is visible on a staging environment throughout rather than revealed at the end.
What you get
Working software on a staging environment you can review
Weekly written progress notes
Direct access to the person building it
Source code in version control from day one
What I need from you
Feedback within an agreed window
Content and approvals
Subject-matter answers
04
Integrate
Connect the parts, including the awkward edge cases.
Within the build
Forms to intake, intake to CRM, CRM to follow-up, follow-up to reporting. Easy-to-miss edge cases get handled here: duplicate submissions, failed integrations, the enquiry that arrives at 2am, the workflow that silently stops. Every automated path gets a failure alert and a manual override.
What you get
Connected systems with failure alerting
A manual fallback for every automated path
Test records proving each path end to end
Documentation of every integration point
What I need from you
Admin access to the tools being connected
A decision on who receives failure alerts
05
Measure
Instrument before launch, not when someone asks for a report.
At launch
Conversion events, source capture, and the join from first touch to closed deal, wired in as the system ships. A baseline is recorded so later improvements have something to be compared against. Metric definitions are written down so the numbers still mean the same thing in six months.
What you get
Conversion tracking live at launch
A recorded baseline for every measure in scope
An event dictionary and metric definitions
Reporting a founder can read in two minutes
What I need from you
Analytics and Search Console access
Agreement on what counts as a qualified inquiry
06
Improve
Change one thing at a time and measure what happened.
Ongoing, optional
After handover the system is yours to run. Where an ongoing engagement makes sense it is a defined monthly scope, not unlimited work: monitoring, maintenance, and a small number of deliberate improvements each month made against the baseline.
What you get
Monitoring and alerting on the paths that matter
A prioritised backlog you control
A written monthly review against the baseline
Your code, accounts, and data, whether or not you continue
What I need from you
Priorities each month
Nothing else. There is no lock-in
Communication
One person, directly. No account manager, no relay, and no handoff to someone who was not in the room when the decisions were made. In practice that means a shared channel for day-to-day questions, a written progress note each week, and a call whenever a decision needs one rather than on a standing schedule that consumes both our time.
Access and ownership
Access requests are scoped to what the work needs and are removed at handover. You keep ownership of everything throughout: source code in your repository or transferred to it, accounts in your name, domain under your control, and data you can export. There is no proprietary layer you have to keep paying to use.
Handover
At the end you receive the code with its Git history, credentials for every account, written documentation of the system and its integrations, the measurement baseline, and the event dictionary. The test of a good handover is that another capable engineer can take it over without calling me. That is the standard it is written to.
After launch
Thirty days of support is included with every build, covering defects and adjustments to what was delivered. Beyond that, an ongoing engagement is available and optional. A well-documented system should leave an internal team able to operate the agreed scope; ongoing care is offered only where monitoring and continued improvement justify it.
A growth system audit reviews all nine diagnostic checkpoints, ranks the two or three highest-priority constraints supported by the evidence, and produces a costed plan you could execute with anyone — including someone other than me.