Custom software for banks in the Philippines: four things teams get wrong
Most bank and insurance teams assume custom software takes six months, needs a signed-off requirements document first, belongs to IT and leaves with the vendor. Build a rough version early, test it with customers, and build it with your own staff.
This is for people at Philippine banks and insurers who are thinking about getting custom software built. It might be a new onboarding flow for customers, or an internal tool for branch staff.
If you have been looking into custom software for banks in the Philippines, you have probably been told it takes six months or more. You have probably also been told nothing gets built until a requirements document is signed off.
We have run workshops for Philippine financial services since 2015, and we build software with client teams. Below are four beliefs we hear on most projects, what we see happen instead, and a short list of things to try this week.
Getting a new customer journey live does not have to take six months
On a normal project, the first few months go on meetings, specs and vendor selection. By the time the new journey launches, the people who asked for it have moved on to other priorities. Often nobody wrote down the drop-off numbers it was meant to fix, so nobody can say if it worked.
A faster way is to work in short sprints. Design one journey, test it with real customers, fix what they struggle with, then build it properly.
A large insurer did exactly this with a series of five-day design sprints on its customer web journeys. Each journey was designed and tested with customers in two weeks and went live in four. The same work used to take 26 weeks or more. The client measured the results: completion rates on the new journeys rose 80 percent, and the old drop-off points disappeared.
Those numbers can be stated because the insurer measured before and after. Write down today's completion rate or turnaround time before you start, so you have something to compare against later.
You can start building before the requirements document is signed off
Most teams know how this goes. The requirements document goes round for comments for weeks. It gets signed off, the build starts, and the first time real users see anything is during testing near the end. Then someone finds a step customers cannot get past, and fixing it becomes a change request with its own cost and its own delay.
Instead, build a rough working version early. It can be a clickable mock-up or a simple screen that only half works. Put it in front of the people who will use it and watch where they get stuck. Those sticking points go into the requirements before anyone writes production code.
The insurer's sprints worked this way. Each journey was in front of customers within two weeks, long before anything went live. Problems that would have surfaced after launch were found and fixed while changes were still cheap. A rough version shows you what the requirements document missed, and that is far easier to act on than a list of comments in the margin.
Branch staff and operations can work with IT on the first version
In many banks and insurers, the business writes a request, IT builds it, and the business signs it off at the end. Branch staff often see the new system for the first time at rollout training. If it does not match how customers actually behave at the counter, they work around it, and the workarounds stay for years.
Branch staff see every day where customers get stuck. They know which form fields people leave blank and which step makes a customer give up and call. Operations staff know where the paperwork piles up behind the scenes.
Put a couple of them in the room with IT from the first version. They do not need to write code. They need to look at the rough version, say what will go wrong at the counter, and check the fixes.
With branch staff and operations working next to IT, the first version goes after the right problem. That is the same reason the insurer's journeys were tested with customers so early.
Your own team should still know how the software works after the outside team leaves
Here is a familiar pattern. The vendor delivers, hands over a document and leaves. A few weeks later a label needs changing, or a new product needs adding to a dropdown. You raise a ticket, wait for a quote, then wait for a slot in the vendor's schedule. A small change takes longer than it should, every time.
This happens because nobody on your side was close to the build. They do not know why decisions were made or where things live.
Build it together. Have someone from your team sit with the build team from the first rough version through to launch, helping to test and fix along the way. When the outside team leaves, your people know how the software works and can make small changes themselves.
This is how we work when we build prototypes, AI features, internal tools and production software with client teams. The goal is for your own staff to own what gets built after launch.
What to do this week
- Write down today's number for the journey you want to fix: completion rate, the main drop-off point, or turnaround time.
- Pick one step in that journey and make a rough version of it, even on paper, before the requirements document goes out for comments.
- Ask two branch staff where customers get stuck on that step, and add their answers to the requirements.
- Name one person from your own team who will sit with the build team from the first version.
- When you talk to vendors, ask how your team will make small changes after launch without calling them back.
Questions people ask
How long does custom software take for a bank or insurer in the Philippines?
It depends on the scope. A large insurer's customer web journeys went live in four weeks instead of 26, using five-day design sprints with customer testing inside two weeks.
Do we need a signed-off requirements document before anything is built?
No. A rough working version tested with the people who will use it shows what the document missed, and those gaps go into the requirements before anyone writes production code.
Who from the business should be involved in building it?
Branch staff and operations should work with IT from the first version. Someone from your own team should stay with the build throughout, so they can fix and change the software after launch.
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. Who we are.
