An alternative to a platform project: ship one customer journey first

On-Off Group

September 2026

The practical alternative to a platform project is to pick one customer journey, record the turnaround time before you touch it, rebuild and ship that one journey with your own team, then widen using the measured result to fund the next piece.

If you are about to sign off a year of platform rebuild work, there is another way to start. Take one customer journey, measure it, ship it, then widen.

Make it the first real delivery, with a number attached, built with your own team. Not a side pilot that sits there while everyone waits for the big project to get funded.

On-Off Group builds this with your team: real screens, real data, AI features and the back end code, so your people can maintain it after.

What the platform project looks like in month five

The business case was approved. Vendors are selected. There is a workstream for data, one for integration, one for change management. There is a weekly status call where the slides are green and nothing is in front of a customer.

Meanwhile the onboarding flow still takes the same number of days it took in January. Branch staff still print things. When your boss asks whether the work is having any effect, the honest answer is that it is too early to say. It will still be too early to say next year.

Old systems do need replacing, and that work will still have to happen. The problem is spending a year and having nothing a customer can use, and no before number, so you cannot prove the good parts either.

Pick one journey, the one people complain about

Choose a single customer journey that already has a known problem. Account opening. A claim. A card replacement. Something where your service team can tell you the turnaround time off the top of their head, or at least the point where people give up.

Keep it small enough that one team can ship it, and pick one that annoys people enough that they will notice when it changes. If nobody in the bank would mention the change in a meeting, pick a different journey.

Then be strict about scope. One journey, end to end, including the internal steps. Most of the delay in onboarding is not on the customer's screen. It is the queue between two teams, the manual check, the re-keying into another system. If you only rebuild the front end you move the wait, and the turnaround time barely changes.

On a series of five-day design sprints with a large insurer, customer-facing web journeys that had previously taken six months or more were designed and tested with customers in two weeks and live in four. That is 26 weeks down to 4. Nothing about the underlying platform changed first.

Write down the before number before you build anything

This is the part most people skip. It is why a six month project ends in a slide pack and nobody can say whether it worked.

Before a single line of code, record the number you will be judged on. Days from submission to approval. Percentage of customers who finish. Calls per hundred applications. Take it from the system if you can, from a week of manual counting if you cannot. Note how you measured it, because you will need to measure it the same way again.

Also watch five real customers use the current journey on video. Not a survey. Five people, screen recorded, trying to do the thing. You will see where they stop, and you will stop arguing about it in meetings. The difference between recording five customers once and recording them every month is set out at onoffgroup.com.

If the before number turns out to be small, say so early. A journey that already works in two days does not need a rebuild, and finding that out in week one is a win.

Build a rough working version before you commit the year

A rough working version settles arguments that the slides keep going round in circles. Most teams arrive with the idea written up in a PowerPoint, and once building starts, the slides turn out to be wrong in specific ways: the data is not there, the approval step has two owners, the AI feature needs a document nobody scans.

So build the thin version first. Real screens, real data where possible, connected to enough of the back end to be honest about what it takes. Put it in front of branch staff and customers. Watch. Fix. Test again.

Then harden the parts that survived. This is where you find out whether the AI feature is worth keeping. AI on a broken journey just automates the failure, and a rough version shows you that early instead of a year in.

There is a write-up of the design sprint with Meralco, where one journey was built and tested this way.

Widen once you have the result

Once one journey is live, measure it the same way you measured it before. On those insurer journeys, completion rates rose 80 per cent and the old drop-off points disappeared.

Now the conversation with your boss changes. You are not asking for a year on trust. You are saying: this journey moved from this number to that number, here is what it cost, and here are the platform constraints we hit that will block the next one.

That list of platform constraints comes from actually shipping a journey, not from reviewing documents. Some of the platform work will still be needed. Some of it quietly drops off, because the assumption behind it did not survive contact with the real flow.

Widen one journey at a time, with a before number each time. It looks slower on the plan, but you get a live journey and a real number much sooner.

What to do this week

Name the one customer journey you would ship first, and write down who owns each internal step in it.
Pull or count the current turnaround time and completion rate, and note exactly how you measured them.
Record five real users attempting the journey as it stands today, and mark where each of them stops.
Cut the scope of the first release to what one team can build and put live, internal steps included.
Agree with your boss now which single number will decide whether it worked, before anyone builds.

Questions people ask

Which customer journey should we pick first?
Pick the one your branch staff and service teams complain about most, where you can already see a turnaround time or a drop-off point. It needs to be small enough to ship and painful enough that a change gets noticed.

What counts as a before number?
Anything you can measure the same way twice: days from application to approval, percentage of customers who finish the flow, number of calls per hundred applications. One honest number beats a page of estimates.

Does this mean the platform work never happens?
No. It happens later, with evidence. Once one journey is live and measured, you know which parts of the platform actually block the work and which were assumptions in the slides.

How fast can one journey realistically move?
On a series of five-day design sprints with a large insurer, customer-facing web journeys that had previously taken six months or more were designed and tested with customers in two weeks and live in four.

On-Off Group trains teams, tests products with real customers, finds where a transformation has stalled and builds what gets it moving, for banks, insurers and enterprises in the Philippines, since 2015. How we help with building software.