Process

Consulting and build, as one sequence.

Five phases from first workshop to handover. Each has a fixed purpose, a named deliverable and an exit criterion that can stop the programme — including the first one.

01Diagnose2–4 weeks
02Frame2–3 weeks
03Prove6–12 weeks
04Build & scale3–12 months
05Transfer & runContractual, from month one

The five phases

Diagnose

Typical duration: 2–4 weeks

Establish, in your own financial terms, what the opportunity is worth and what stands between you and it. We are equally willing to conclude that the programme should not go ahead.

What happens

Value mapping against your P&L — margin leakage, cost-to-serve, channel mix, working capital
Contextual research where the service is actually delivered: branch, call centre, warehouse, plant floor
Architecture and data review, including the constraints nobody documents
Regulatory, security and audit constraints captured as design inputs rather than late objections
Capability and operating-model assessment: who would actually build and run this

What you get

Quantified value map tied to your financial statements
Current-state architecture and constraint register
Research findings with verbatim evidence
A go / no-go recommendation with the reasoning shown

Exit criterion

A named executive sponsor agrees the value figure and the constraint list. If the business case does not hold, we say so here — in week four, not in the post-implementation review.

Frame

Typical duration: 2–3 weeks

Convert findings into a plan someone can be held to: target architecture, dependency-aware sequencing, a funding case, and a first slice scoped tightly enough to reach production this quarter.

What happens

Target architecture and the migration seam between it and what exists today
Dependency mapping, so prerequisite platform work surfaces before it becomes a critical-path surprise
Investment case with sensitivity analysis your finance team can interrogate
Team topology and the staffing plan, including which of your people join the squad
First-release scoping: one journey, one segment, real users

What you get

Target architecture and architecture decision records
Three-horizon roadmap with an explicit dependency graph
Costed investment case and commercial model
First-release backlog, estimated and ready to start

Exit criterion

Engineering, risk and finance all sign off on the same document. If any of the three cannot, the plan is not ready.

Prove

Typical duration: 6–12 weeks

Replace opinion with evidence. In week one we deploy something trivial all the way to production so that environments, credentials, security review and deployment approval surface while nothing is at stake.

What happens

Week one: a health-check endpoint deployed to production, end to end
Fortnightly increments against the first-release backlog
Risk, security and audit in the sprint review from the first one
Usability testing with real users on real devices, every increment
For AI work: an evaluation harness and an agreed human baseline before any model is built

What you get

A working vertical slice live in production
CI/CD pipeline, automated tests and observability
Measured results against the baseline agreed in Frame
A revised estimate for the rest of the roadmap, informed by actual velocity

Exit criterion

The slice is live and the numbers are measured, not modelled. If the measured result misses the baseline, we re-scope or stop — this is the cheapest point at which that decision can still be made.

Build & scale

Typical duration: 3–12 months

Extend from the proven slice to the full scope without losing the delivery rhythm — adding journeys, segments, channels and sites while the platform hardens underneath.

What happens

Fortnightly production releases, with scope negotiated against measured velocity
Progressive hardening: performance, resilience, failure testing, disaster recovery rehearsal
Cost guardrails and per-team unit economics visible weekly, not quarterly
Multi-site or multi-segment rollout in waves, each wave shorter than the last
Client engineers reviewing every pull request, from the first sprint

What you get

The full scope in production, released incrementally
Tested disaster recovery and documented recovery objectives
Architecture decision records and system documentation kept current
Accessibility conformance verified in the pipeline

Exit criterion

Load and failure rehearsal completed against realistic peak, and the client team has shipped at least one feature end to end without us in the room.

Transfer & run

Typical duration: Contractual, from month one

Make our exit a plan rather than an event. The transfer is written into the contract at kickoff: named roles, dated milestones, and a fee that steps down as each function moves to your team.

What happens

Paired operations and shadow on-call rotations
Runbooks, incident and change management processes handed over and rehearsed
Function-by-function transfer against the dated schedule agreed at kickoff
Optional managed operation to an SLA while the capability is still being built
Quarterly review of transfer progress against the contract

What you get

Dated capability transfer plan with named owners on both sides
Runbooks, on-call rotation and rehearsed incident process
Continuously maintained audit evidence pack
A client team that has been reading and reviewing the code for months

Exit criterion

Your team is paged first, resolves incidents unaided and ships features without us. If we are still running the platform in year three, that is a visible failure against a document both parties signed.

What runs through every phase

Six practices that are not confined to one stage. They are the reason the sequence above holds together rather than becoming a waterfall with new labels.

One team, one accountability line

The partner who scoped the work sits in every steering committee through go-live. There is no handover cliff between the people who advised and the people who build, because they are the same people.

Production from week one

Every phase ends in something deployed, measured or tested with real users. We deliberately front-load the boring obstacles — environments, approvals, security review — while the scope is still cheap to change.

Your engineers are in the squad

A named client engineer reviews our pull requests from the first sprint. It slows the first fortnight and removes the knowledge-transfer workshop entirely.

Every phase can end the programme

Each gate is a genuine decision point, not a formality. Stopping at the end of Diagnose costs four weeks; discovering the same thing after go-live costs the programme.

Cadence over heroics

We scope to a fortnightly rhythm the team can sustain. Crunch is treated as a planning failure and reviewed like an incident, because a burnt-out team is a delivery risk.

Say the difficult thing early

If the business case does not hold, or the timeline is fiction, you hear it at the next gate. That is the only version of this work that is worth paying for.

Every gate is a real decision point. Stopping at the end of Diagnose costs four weeks — discovering the same thing after go-live costs the programme.

How we engage

Every capability is available in three shapes. Most clients start small and expand once the first release lands.

Diagnostic sprint

2–4 weeks

A fixed-fee assessment that ends with a costed roadmap, a target architecture and a prioritized first release.

Build partnership

3–12 months

Blended squads of AslanWay and client engineers shipping to production on a fortnightly cadence against agreed outcomes.

Managed capability

12 months+

We run the platform to an SLA while your team takes over incrementally, on a schedule we agree up front.

Have a programme that has stalled between slideware and shipping?

Tell us where it is stuck. We will come back within two business days with a point of view — and an honest answer on whether we are the right partner.

Start the conversation