Software development for banks and insurers in the Philippines: how we build with your team
We build software with your team rather than for it: prototypes, AI features, internal tools and production systems, with your developers and branch-facing staff in the build. Work starts with a baseline number so you can prove whether the new version is better.
If your new onboarding flow is still sitting in a PowerPoint, this page is about getting it built with your own developers, alongside ours. This page is about the third one.
We build software with client teams. Prototypes, AI features, internal tools, production systems. Your developers write code with ours, your branch staff see the thing early, and the work stays with you when we finish.
On-Off Group has worked with Philippine banks and insurers since 2015, including BPI, Security Bank, Metrobank, AIA, AXA, Sun Life, Insular Life and EastWest Ageas. The notes below come from that work.
What a stalled build looks like from the inside
The customer journey work was done months ago. There is a PowerPoint with the new onboarding flow in it. It was approved months ago and it is still a PowerPoint. IT says the release window is next quarter. Compliance has three open questions nobody has written down. The digital team is on its fourth meeting about scope.
Meanwhile the current onboarding flow is live and people are dropping out of it. Nobody knows where exactly, because nobody counted.
This happens to most teams we meet. The work stalls between the approved slides and the actual customer. Our job is to find the gap, put a number on it, and get something shipped that you can point at. If the number turns out to be small, we will tell you that too. A small honest number is better than a big vague one.
Get a before number in the first two weeks
The question that catches you out is "did it work?" If there is no turnaround time, completion rate or drop-off figure from before the change, the only honest answer is a shrug.
So we start there. Pick the flow. Count what it does now: how many people start it, how many finish, how long it takes, where they stop. Then get five real customers on video trying it while someone watches. Two weeks is enough for that.
The before number does two things. It tells you whether the build is worth commissioning, and it gives you something to say when your boss asks later whether it worked. On five-day design sprints with a large insurer, the client measured completion on the new web journeys up 80 per cent, and the old drop-off points gone. They could only say that because someone wrote down the old figures first.
Build a rough version before you write the business case
Most teams arrive with the idea written up in a PowerPoint, and once building starts the slides turn out to be wrong. Wrong in the details that matter: the field nobody can fill in from a phone, or the step that turns out to need a branch officer's approval.
Building the thing shows you what the slides left out. A rough working version that five people can try costs less than another round of scoping, and tells you more.
This matters most with AI features. AI on a broken customer journey just automates the failure. Fix the flow first. Then add the AI feature and watch someone try to use it. With the same large insurer, journeys that used to take six months or more were designed, tested with customers and live in four weeks. Twenty-six weeks down to four. The wrong ideas got dropped early, before anyone built them.
Your team builds it with us
The usual agency setup is a signed scope, a monthly demo and a handover pack at the end. Six months later the agency is gone, the pack is out of date, and your developers are reading unfamiliar code.
We work the other way round. Your developers commit alongside ours. Your product and operations people sit in the working sessions, not just the reviews. Your branch staff watch the usability sessions and hear the customer complain in their own words. That settles a lot of internal arguments.
It also means the skill stays with your people. After building one AI feature together, your developers know enough to plan the next one without us. If your team needs the method rather than the code, we run it as training around a live problem you already have.
In-house, agency, or a team that builds with yours
In-house is the right call when the work sits close to the core system, the queue is short and your people already know the product rules. Nobody knows the product rules like your own people.
An agency is right when the scope is genuinely fixed and you want it off your plate. A new marketing site, a defined integration.
Building with an outside team makes sense when the problem is not yet clear, when the customer journey and the software have to change together, or when your internal queue is long and you need something real in front of users sooner than that. It also makes sense when you need a before and after number to show your boss, not just delivered features. On-Off Group is a team of designers, facilitators, researchers and developers in Manila, founded by a UK designer in 2015. We do four things: training, customer research, finding where the work stalls, and building software and products.
What to do this week
- Pick one flow that matters, onboarding or claims or a branch process, and write down its current completion rate and turnaround time.
- If those figures do not exist anywhere, note that as your first finding and get someone counting.
- Book five real customers or branch staff to try the current version on video while somebody watches.
- Ask for a rough working version of the main idea before you write the business case for it.
- Name the person on your side who will still own the code after the build ends.
More on Building software
- What it means when On-Off Group builds software with your team
- Prototype or production build: which to commission next
- What building an AI feature with us involves and how long it takes
- How to take an AI prototype to production without a six month project
- Instead of a platform project: ship one customer journey, measure it, then widen
- Everything on Building software
Questions people ask
Do you replace our in-house developers?
No. Your developers stay on the build and keep the code afterwards. We bring designers, researchers, facilitators and developers alongside them so the thing still works when we leave.
Can you build a prototype before we commit to a full project?
Yes. A rough working version that five real users can try tells you more than a scoping document, and it usually changes what you end up building.
What happens if you find the gap is small?
We say so. If the numbers do not justify a build, it is cheaper to hear that in the first two weeks than after six months of work.
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.
