Our Approach | Diagnose, Design, Build and Improve

Engineering betterbusiness outcomes

Why diagnosis first

Two ways to buy a system

Most technology engagements start with a solution someone has already chosen, then bend the problem to fit it. We work the other way around: the constraint is qualified, evidenced and valued before any solution is designed. The difference decides how much risk you carry.

Solution-first buying compared with a constraint-led engagement
	Solution-first buying	Constraint-led engagement
Starting point	A solution someone has already chosen	A problem stated in business terms
First commitment	The whole build, priced on assumptions	A small diagnostic stage with defined outputs
Scope	Fixed early, when the least is known	Set stage by stage, as evidence accumulates
Evidence before build	The vendor's claims	Your current state, mapped and costed
If the diagnosis is wrong	Discovered after launch, at full cost	Caught at a gate: stop, redesign or refer out
What success means	Delivered on time and on budget	A measured change in the constrained metric

The delivery process

Eight stages, each closed by a decision gate

Every engagement moves through the same eight stages. Each has a defined purpose, and each ends with a gate: an explicit decision, made on evidence, about whether and how to continue. You commit to a stage, never to the whole journey.

01
Fit, context and qualification
Establish whether the problem is one we can materially help with, before anyone commits time or money.
Decision gateProceed only if the fit is plausible. If it isn't, we say so, and point you somewhere more useful where we can.
Activities, inputs and outputs
Key activities
A short fit check on the problem, your context and our capability
A conversation about the constraint as you currently see it
A check for conflicts, capacity and timing on our side
Client inputs
A plain-language description of the problem
Who owns it, and what solving it would be worth
Common outputs
A clear fit decision
A recommended starting scope for diagnostic work
02
Discovery and current-state audit
Map how things actually work today (systems, workflows, data and the people who run them) rather than how they're assumed to work.
Decision gateIs the constraint what it was assumed to be? Discovery regularly relocates the problem. This gate decides whether the diagnosis stands, moves or stops.
Activities, inputs and outputs
Key activities
Interviews with the people who operate the affected process
Review of the systems, integrations and data involved
Current-state mapping and evidence gathering
Client inputs
Access to the relevant systems and data, agreed in advance
Time with the team members who do the work
Common outputs
A current-state map
Documented findings
A revised, evidence-based statement of the constraint
03
Economic diagnosis
Quantify what the constraint costs and what removing it would be worth, so the investment decision is a comparison rather than a leap.
Decision gateDoes the value of removing the constraint justify the likely cost of removing it? If the numbers don't clear the bar, we recommend stopping, in writing.
Activities, inputs and outputs
Key activities
Baseline the metrics the constraint affects
Model the unit economics around the constrained process
Size the value of removing it under conservative assumptions
Client inputs
Financial and operational figures, handled under confidentiality
Agreement on which metric will define success
Common outputs
A quantified baseline
A value case with stated assumptions
The cost of doing nothing
04
Roadmap and solution strategy
Decide what to do, in what order, and just as deliberately, what not to build.
Decision gateAn agreed first slice of scope with success measures attached: approval of one stage, never of a whole transformation.
Activities, inputs and outputs
Key activities
Options analysis: build, buy, configure or change the process
Sequencing and dependency mapping
Defining the smallest first slice that produces measurable evidence
Client inputs
Budget, timing and internal-capacity constraints
Decision-maker time at the options review
Common outputs
A sequenced roadmap
A recommended starting scope
Success measures tied to the stage-three baseline
05
Design and architecture
Specify the system before building it: interfaces, data flows, integrations and who will own what.
Decision gateDesign approved and risks either accepted or mitigated. Nothing moves to build on an unexamined design.
Activities, inputs and outputs
Key activities
Solution design and architecture decisions, recorded with their reasoning
A risk register and test approach for the build
Integration design against your existing systems and vendors
Client inputs
Design review and approval
Access to internal or vendor technical contacts
Common outputs
Design documentation
Recorded architecture decisions
A delivery plan for the build stage
06
Build, integrate and validate
Implement in reviewable slices, integrated with the systems you already run and validated against the agreed measures.
Decision gateValidation passed against the agreed measures before anything is put in front of customers or staff.
Activities, inputs and outputs
Key activities
Development and integration in staged checkpoints
Testing against the agreed test approach
A change log recording what shifted and why
Client inputs
Timely feedback at each checkpoint
Test participation from the people who will use the system
Common outputs
A working, tested system
Technical and operational documentation
The change log
07
Launch, handover and adoption
Put the system live without disrupting operations, and make sure the people it's for actually adopt it.
Decision gateThe owning team can run the system without us in the room. Launch isn't complete until they can.
Activities, inputs and outputs
Key activities
A staged rollout plan matched to your operating rhythm
Training and handover documentation
Support arrangements for the settling-in period
Client inputs
Internal champions in the affected teams
Scheduling for training and cut-over windows
Common outputs
A live system
A handover pack
An adoption plan with named owners
08
Measure, optimise and scale
Verify the constraint actually moved (against the stage-three baseline) and decide what the evidence supports next.
Decision gateDid the measured result justify further investment? The evidence decides whether to scale, redesign or stop, and often reveals the next constraint.
Activities, inputs and outputs
Key activities
Measurement against the baseline and success measures
Optimisation of what the data says is underperforming
A review cadence for the metrics that matter
Client inputs
Continued access to results data
A recurring review slot with the project owner
Common outputs
Measured results against the baseline
Optimisation actions
A brief on the next constraint, if one has emerged

Stage gates

You approve stages, not transformations

No evidence, no escalation. Each gate weighs the work so far before anything further is committed, and all four outcomes below are real outcomes we plan for, not theatre.

Continue

The evidence supports the next stage. Scope and price for that stage (and only that stage) are agreed at the gate.

Redesign

The goal stands but the approach doesn't. The plan is reworked before more is spent, not after.

Stop

The economics don't clear the bar, or the constraint turns out to live somewhere a system can't fix. Stopping at a gate is a cheap, respectable outcome.

Refer out

Someone else is better placed: a specialist, an incumbent vendor, or your own team. We say so, and make the introduction where we can.

Roles and responsibilities

Who does what

Engagements go wrong when nobody can say who decides. This is the standard split of responsibilities across the four roles every engagement has; a version of it is agreed in stage one and refined at each gate.

Responsibility matrix across the four engagement roles
	Executive sponsor	Project owner	Subject experts	Web Lifter delivery
Stage-gate decisions and budget	Decides	Recommends	Consulted	Presents the evidence
Day-to-day coordination	Kept informed	Owns	Contributes	Plans with the owner
How the work happens today	Not specified	Coordinates access	Owns the knowledge	Elicits and documents
Design, build and documentation	Not specified	Reviews	Reviews	Owns
Testing and acceptance	Signs off	Owns acceptance	Tests real scenarios	Runs the test plan
Adoption and ongoing ownership	Champions	Owns	Uses and feeds back	Trains and hands over

In a smaller business the sponsor, owner and experts may be the same person. The responsibilities still need naming.

Communication and documentation

The paper trail is part of the product

Every engagement keeps a written record you can audit later: what was decided and why, what changed, what was tested, who approved what, and everything your team needs to run the system without us.

Decision log

Every material decision recorded with its reasoning and the alternatives considered, so “why is it built this way?” always has an answer.

Change log

What changed, when and why. Scope movements are visible as they happen, not discovered at invoice time.

Risk register

Known risks with owners and mitigations, reviewed at every gate rather than filed and forgotten.

Test evidence

What was tested, against which criteria, with what result: validation you can inspect, not take on faith.

Gate approvals

Each stage-gate decision recorded with who made it and on what evidence, so commitment stays deliberate.

Handover and reporting

Handover documentation written for your team, then ongoing reporting against the baseline for as long as we're engaged.

After you enquire

What happens when you get in touch

No account, no waitlist, no discovery-call ambush. Three steps, and you'll know where you stand after each one.

01
Fit check
We read your enquiry personally and reply within one business day. The first question is whether this is a problem we can materially help with. If it isn't, we say so straight away.
GateA plausible fit, or a pointer somewhere more useful.
02
Initial conversation
A short call about the constraint as you see it: the context, the symptoms, what solving it would be worth. No pitch deck and no proposal theatre, mostly questions.
GateEnough shared context to scope a sensible starting point.
03
Recommended starting scope
A written recommendation for the smallest first stage that produces evidence (usually diagnostic work) with its outputs, inputs and price defined before you commit to anything.
GateYour decision. Take it, take it elsewhere, or stop here.

Evidence

One engagement, end to end

How the process looks in practice: a delivered project for Steelmark, told with its working and mapped onto the phases above.

Payment Processing Cost Reduction

Diagnosis
The constraint
An ecommerce retailer was losing a significant percentage of revenue to payment processing and invoice platform fees. Web Lifter redesigned the entire sales and payment workflow, replacing Stripe and Paycove with a direct Westpac PayWay integration and a custom-built invoicing platform. The new architecture reduced transaction costs, streamlined operations, and delivered immediate profit improvements without requiring any increase in sales volume.
Strategy
The goal
Reduce payment processing costs and eliminate unnecessary transaction fees by redesigning the ecommerce checkout and invoicing workflow while maintaining a seamless customer experience.
Delivery
The work
- Reviewed the existing payment stack and identified opportunities to reduce transaction costs without impacting operational efficiency.
- Designed and implemented a direct integration with Westpac PayWay, replacing Stripe as the primary payment processor.
- Built a bespoke invoicing solution tailored to the client's business requirements, removing the need for third-party invoice processing services.
- Redesigned the end-to-end payment and invoicing process to reduce complexity, improve reliability, and minimise operational overhead.
Measurement
The measured result
The project reduced transaction costs from 1.7% + $0.30 charged by Stripe plus an additional 1% charged by Paycove, down to a flat 1% through Westpac PayWay.
This reduction generated tens of thousands of dollars in annual savings, directly improving profitability without requiring additional marketing spend, price increases, or sales growth. The business now retains substantially more revenue from every transaction while operating on a simpler and more efficient payment infrastructure.
63%Transaction Fee Reduction

Drawn from the published case study. The full write-up explains how each number was produced. Read the full case study

FAQ

Questions buyers actually ask

Straight answers to the things high-consideration buyers want settled before a first conversation.

Can you give us a price before the scope is defined?

For a defined first stage, yes: diagnostic work is scoped and priced before it starts, and each gate prices only the stage it opens. What we won't do is quote an entire transformation before the constraint is confirmed: any such number would be a guess dressed up as a commitment. The staged model exists so that every price you're asked to approve is attached to defined outputs.

What access to our systems and data will you need?

Only what the current stage requires, agreed in advance. Discovery typically needs read access to the systems and data involved in the constrained process, plus time with the people who run it. Access is scoped stage by stage. We don't ask for blanket credentials on day one, and sensitive material can be reviewed on your infrastructure rather than copied out.

How do you handle confidentiality?

We'll sign a confidentiality agreement before discovery begins if you want one: the economic diagnosis depends on exactly the figures most businesses protect, so guarding them is in both parties' interest. Your information is used for your engagement only, and nothing is published about your business without your written approval.

How long will it take?

Honestly: it depends on the constraint, and anyone quoting a whole-journey date before discovery is guessing. What we commit to instead is a timeline per stage, set at the gate that opens it, once the previous stage's outputs make it estimable. The early diagnostic stages are deliberately small, so you find out quickly whether the longer journey is worth taking.

We already have an internal team and vendors. How do you fit in?

We work alongside them, not around them. The responsibility split above is agreed at the start: your team keeps the domain knowledge and the ongoing ownership, incumbent vendors keep what they're good at, and we take the parts you've engaged us for. Where an incumbent is better placed to do the work, the refer-out gate exists precisely so we say that rather than duplicate them.

Would you actually tell us not to build anything?

Yes, it's a designed outcome, not a hypothetical. The economic diagnosis in stage three exists to catch projects where the value doesn't justify the cost, and the stop and refer-out gates make walking away a normal, documented decision. A recommendation not to build costs you a small diagnostic engagement instead of a large failed one.

Next step

Clarify the problem before committing to the solution.

Discuss your current constraint View Audits & Diagnostics

Why diagnosis first

Two ways to buy a system

Solution-first buying compared with a constraint-led engagement
	Solution-first buying	Constraint-led engagement
Starting point	A solution someone has already chosen	A problem stated in business terms
First commitment	The whole build, priced on assumptions	A small diagnostic stage with defined outputs
Scope	Fixed early, when the least is known	Set stage by stage, as evidence accumulates
Evidence before build	The vendor's claims	Your current state, mapped and costed
If the diagnosis is wrong	Discovered after launch, at full cost	Caught at a gate: stop, redesign or refer out
What success means	Delivered on time and on budget	A measured change in the constrained metric

The delivery process

Eight stages, each closed by a decision gate

01
Fit, context and qualification
Establish whether the problem is one we can materially help with, before anyone commits time or money.
Decision gateProceed only if the fit is plausible. If it isn't, we say so, and point you somewhere more useful where we can.
Activities, inputs and outputs
Key activities
A short fit check on the problem, your context and our capability
A conversation about the constraint as you currently see it
A check for conflicts, capacity and timing on our side
Client inputs
A plain-language description of the problem
Who owns it, and what solving it would be worth
Common outputs
A clear fit decision
A recommended starting scope for diagnostic work
02
Discovery and current-state audit
Map how things actually work today (systems, workflows, data and the people who run them) rather than how they're assumed to work.
Decision gateIs the constraint what it was assumed to be? Discovery regularly relocates the problem. This gate decides whether the diagnosis stands, moves or stops.
Activities, inputs and outputs
Key activities
Interviews with the people who operate the affected process
Review of the systems, integrations and data involved
Current-state mapping and evidence gathering
Client inputs
Access to the relevant systems and data, agreed in advance
Time with the team members who do the work
Common outputs
A current-state map
Documented findings
A revised, evidence-based statement of the constraint
03
Economic diagnosis
Quantify what the constraint costs and what removing it would be worth, so the investment decision is a comparison rather than a leap.
Decision gateDoes the value of removing the constraint justify the likely cost of removing it? If the numbers don't clear the bar, we recommend stopping, in writing.
Activities, inputs and outputs
Key activities
Baseline the metrics the constraint affects
Model the unit economics around the constrained process
Size the value of removing it under conservative assumptions
Client inputs
Financial and operational figures, handled under confidentiality
Agreement on which metric will define success
Common outputs
A quantified baseline
A value case with stated assumptions
The cost of doing nothing
04
Roadmap and solution strategy
Decide what to do, in what order, and just as deliberately, what not to build.
Decision gateAn agreed first slice of scope with success measures attached: approval of one stage, never of a whole transformation.
Activities, inputs and outputs
Key activities
Options analysis: build, buy, configure or change the process
Sequencing and dependency mapping
Defining the smallest first slice that produces measurable evidence
Client inputs
Budget, timing and internal-capacity constraints
Decision-maker time at the options review
Common outputs
A sequenced roadmap
A recommended starting scope
Success measures tied to the stage-three baseline
05
Design and architecture
Specify the system before building it: interfaces, data flows, integrations and who will own what.
Decision gateDesign approved and risks either accepted or mitigated. Nothing moves to build on an unexamined design.
Activities, inputs and outputs
Key activities
Solution design and architecture decisions, recorded with their reasoning
A risk register and test approach for the build
Integration design against your existing systems and vendors
Client inputs
Design review and approval
Access to internal or vendor technical contacts
Common outputs
Design documentation
Recorded architecture decisions
A delivery plan for the build stage
06
Build, integrate and validate
Implement in reviewable slices, integrated with the systems you already run and validated against the agreed measures.
Decision gateValidation passed against the agreed measures before anything is put in front of customers or staff.
Activities, inputs and outputs
Key activities
Development and integration in staged checkpoints
Testing against the agreed test approach
A change log recording what shifted and why
Client inputs
Timely feedback at each checkpoint
Test participation from the people who will use the system
Common outputs
A working, tested system
Technical and operational documentation
The change log
07
Launch, handover and adoption
Put the system live without disrupting operations, and make sure the people it's for actually adopt it.
Decision gateThe owning team can run the system without us in the room. Launch isn't complete until they can.
Activities, inputs and outputs
Key activities
A staged rollout plan matched to your operating rhythm
Training and handover documentation
Support arrangements for the settling-in period
Client inputs
Internal champions in the affected teams
Scheduling for training and cut-over windows
Common outputs
A live system
A handover pack
An adoption plan with named owners
08
Measure, optimise and scale
Verify the constraint actually moved (against the stage-three baseline) and decide what the evidence supports next.
Decision gateDid the measured result justify further investment? The evidence decides whether to scale, redesign or stop, and often reveals the next constraint.
Activities, inputs and outputs
Key activities
Measurement against the baseline and success measures
Optimisation of what the data says is underperforming
A review cadence for the metrics that matter
Client inputs
Continued access to results data
A recurring review slot with the project owner
Common outputs
Measured results against the baseline
Optimisation actions
A brief on the next constraint, if one has emerged

Stage gates

You approve stages, not transformations

No evidence, no escalation. Each gate weighs the work so far before anything further is committed, and all four outcomes below are real outcomes we plan for, not theatre.

Continue

The evidence supports the next stage. Scope and price for that stage (and only that stage) are agreed at the gate.

Redesign

The goal stands but the approach doesn't. The plan is reworked before more is spent, not after.

Stop

The economics don't clear the bar, or the constraint turns out to live somewhere a system can't fix. Stopping at a gate is a cheap, respectable outcome.

Refer out

Someone else is better placed: a specialist, an incumbent vendor, or your own team. We say so, and make the introduction where we can.

Roles and responsibilities

Who does what

Responsibility matrix across the four engagement roles
	Executive sponsor	Project owner	Subject experts	Web Lifter delivery
Stage-gate decisions and budget	Decides	Recommends	Consulted	Presents the evidence
Day-to-day coordination	Kept informed	Owns	Contributes	Plans with the owner
How the work happens today	Not specified	Coordinates access	Owns the knowledge	Elicits and documents
Design, build and documentation	Not specified	Reviews	Reviews	Owns
Testing and acceptance	Signs off	Owns acceptance	Tests real scenarios	Runs the test plan
Adoption and ongoing ownership	Champions	Owns	Uses and feeds back	Trains and hands over

In a smaller business the sponsor, owner and experts may be the same person. The responsibilities still need naming.

Communication and documentation

The paper trail is part of the product

Every engagement keeps a written record you can audit later: what was decided and why, what changed, what was tested, who approved what, and everything your team needs to run the system without us.

Decision log

Every material decision recorded with its reasoning and the alternatives considered, so “why is it built this way?” always has an answer.

Change log

What changed, when and why. Scope movements are visible as they happen, not discovered at invoice time.

Risk register

Known risks with owners and mitigations, reviewed at every gate rather than filed and forgotten.

Test evidence

What was tested, against which criteria, with what result: validation you can inspect, not take on faith.

Gate approvals

Each stage-gate decision recorded with who made it and on what evidence, so commitment stays deliberate.

Handover and reporting

Handover documentation written for your team, then ongoing reporting against the baseline for as long as we're engaged.

After you enquire

What happens when you get in touch

No account, no waitlist, no discovery-call ambush. Three steps, and you'll know where you stand after each one.

01
Fit check
We read your enquiry personally and reply within one business day. The first question is whether this is a problem we can materially help with. If it isn't, we say so straight away.
GateA plausible fit, or a pointer somewhere more useful.
02
Initial conversation
A short call about the constraint as you see it: the context, the symptoms, what solving it would be worth. No pitch deck and no proposal theatre, mostly questions.
GateEnough shared context to scope a sensible starting point.
03
Recommended starting scope
A written recommendation for the smallest first stage that produces evidence (usually diagnostic work) with its outputs, inputs and price defined before you commit to anything.
GateYour decision. Take it, take it elsewhere, or stop here.

Evidence

One engagement, end to end

How the process looks in practice: a delivered project for Steelmark, told with its working and mapped onto the phases above.

Payment Processing Cost Reduction

Diagnosis
The constraint
An ecommerce retailer was losing a significant percentage of revenue to payment processing and invoice platform fees. Web Lifter redesigned the entire sales and payment workflow, replacing Stripe and Paycove with a direct Westpac PayWay integration and a custom-built invoicing platform. The new architecture reduced transaction costs, streamlined operations, and delivered immediate profit improvements without requiring any increase in sales volume.
Strategy
The goal
Reduce payment processing costs and eliminate unnecessary transaction fees by redesigning the ecommerce checkout and invoicing workflow while maintaining a seamless customer experience.
Delivery
The work
- Reviewed the existing payment stack and identified opportunities to reduce transaction costs without impacting operational efficiency.
- Designed and implemented a direct integration with Westpac PayWay, replacing Stripe as the primary payment processor.
- Built a bespoke invoicing solution tailored to the client's business requirements, removing the need for third-party invoice processing services.
- Redesigned the end-to-end payment and invoicing process to reduce complexity, improve reliability, and minimise operational overhead.
Measurement
The measured result
The project reduced transaction costs from 1.7% + $0.30 charged by Stripe plus an additional 1% charged by Paycove, down to a flat 1% through Westpac PayWay.
This reduction generated tens of thousands of dollars in annual savings, directly improving profitability without requiring additional marketing spend, price increases, or sales growth. The business now retains substantially more revenue from every transaction while operating on a simpler and more efficient payment infrastructure.
63%Transaction Fee Reduction

Drawn from the published case study. The full write-up explains how each number was produced. Read the full case study

FAQ

Questions buyers actually ask

Straight answers to the things high-consideration buyers want settled before a first conversation.

Can you give us a price before the scope is defined?

What access to our systems and data will you need?

How do you handle confidentiality?

How long will it take?

We already have an internal team and vendors. How do you fit in?

Would you actually tell us not to build anything?

Next step

Clarify the problem before committing to the solution.

Discuss your current constraint View Audits & Diagnostics

From an unclear constraint to an implemented, measurable system.

Two ways to buy a system

Eight stages, each closed by a decision gate

Fit, context and qualification

Key activities

Client inputs

Common outputs

Discovery and current-state audit

Key activities

Client inputs

Common outputs

Economic diagnosis

Key activities

Client inputs

Common outputs

Roadmap and solution strategy

Key activities

Client inputs

Common outputs

Design and architecture

Key activities

Client inputs

Common outputs

Build, integrate and validate

Key activities

Client inputs

Common outputs

Launch, handover and adoption

Key activities

Client inputs

Common outputs

Measure, optimise and scale

Key activities

Client inputs

Common outputs

You approve stages, not transformations

Continue

Redesign

Stop

Refer out

Who does what

The paper trail is part of the product

Decision log

Change log

Risk register

Test evidence

Gate approvals

Handover and reporting

What happens when you get in touch

Fit check

Initial conversation

Recommended starting scope

One engagement, end to end

Payment Processing Cost Reduction

The constraint

The goal

The work

The measured result

Questions buyers actually ask

Clarify the problem before committing to the solution.

From an unclear constraint to an implemented, measurable system.

Two ways to buy a system

Eight stages, each closed by a decision gate

Fit, context and qualification

Key activities

Client inputs

Common outputs

Discovery and current-state audit

Key activities

Client inputs

Common outputs

Economic diagnosis

Key activities

Client inputs

Common outputs

Roadmap and solution strategy

Key activities

Client inputs

Common outputs

Design and architecture