Build or buy software: five questions to answer before anyone signs
Before you build or buy software, name the one slow step it fixes, the people who will use it daily, whether a product already fits, the number that proves it worked, and let a few staff try a rough version.
This guide is for anyone about to decide whether to build or buy software for their team. You might be a head of digital with a slow onboarding flow and a boss asking for something real. You might run operations and want one AI feature in front of real users instead of another meeting about scope.
The build or buy software question usually starts with price and vendor demos. In the rooms we have run for Philippine banks and insurers since 2015, the expensive mistakes happen earlier than that. They come from skipping a few plain questions.
Here are five to answer before anyone signs. Most can be settled in a short meeting with the right people in it. The fourth one, the before number, is the one most teams skip, and your boss will ask about it later.
Which slow step is it for?
On a normal working day the request sounds like this: we need a tool so the team can move faster. Vendors are invited in. Every demo looks good, because nobody agreed what the tool had to fix.
Name one slow step instead. Approving a loan. Checking a claim. Getting a new customer through onboarding. Write it down in words branch staff would recognise, and say where the step starts and where it ends.
"Faster in general" gives you nothing to buy and nothing to build. "The time between a claim arriving and someone checking it" does. You can compare tools against it, you can show it to a developer, and you can measure it.
If the room cannot agree on one step, stop there. That disagreement is more useful to sort out now than after a contract.
Who will use it every day?
The person who signs for a tool sees the demo. The people who open it every morning often see it for the first time on launch day.
Name those people. Branch staff, the claims team, the agents in the field. Then look at their working day as it actually is. How many screens do they already switch between? Are they at a desk or at a counter with a customer in front of them? Do they have ten spare minutes for a new login, or none?
A tool that suits the person signing and annoys the people using it gets worked around. Staff go back to the spreadsheet or the paper form, and the licence keeps renewing.
Ask two or three daily users to talk you through a normal shift before you look at any product. Write down what slows them down in their words. Their working day decides whether the tool gets used.
Does a product already fit?
Building something custom feels exciting, especially now that AI makes a first version quick to put together. It is still the slower and riskier route if a good product already exists.
So check the market first, and check it against how your staff actually work, using the notes from the last question. If a product fits that day closely, buy it. Paying to rebuild something you could rent is hard to defend later.
Building is worth a look when every product on the market would force staff to change how they work to suit it. For example, a claims tool that assumes every document arrives by email, when most of yours come in as photos from agents' phones.
We build software with client teams, and we still tell people to buy when a product fits. The fit with the working day matters more than the feature list.
What number tells you it worked?
This is the one most teams skip. The project starts, the tool goes live, and months later someone asks if it worked. Nobody wrote down how long the slow step took before. All anyone can do is shrug.
Pick the number before the tool goes in. Turnaround time in days is often the simplest. Completion rate on an online form works too. Measure it now, for a few weeks if you can, then measure it the same way after launch.
Small honest numbers are fine. A drop from five days to four is worth reporting if it is real.
One example from our own work: a large insurer ran a series of design sprints on customer-facing web journeys. Completion rates on the new journeys rose 80 percent, and the old drop-off points disappeared. The client measured that. The result can only be stated because someone had the old completion rate written down first.
Can a few staff try it first?
Most buying decisions are made from a PowerPoint and a vendor demo. Once real staff start using the tool, the slides turn out to be wrong in ways nobody could have spotted from the meeting room.
Before anyone signs, put a rough working version in front of a few of the people who will use it every day. For a product you are buying, that means a trial with your own cases, not the vendor's demo data. For something you are building, it means a basic version that does the one slow step and little else.
Watch them use it. Do not explain it first. Note where they get stuck, then fix and test again.
This is quicker than it sounds. On the insurer's journeys above, work that used to take six months or more was designed and tested with customers in two weeks and live in four. There is more on how those design sprints run if you want the detail.
What to do this week
- Write the one slow step the tool is for in a single sentence, with a start and an end.
- Sit with two or three daily users and note what slows them down in a normal shift.
- List the products already on the market and check each one against those notes.
- Start measuring the slow step now, before any tool goes in.
- Find a few staff willing to try a rough version and book time to watch them.
Questions people ask
When is it worth building software instead of buying it?
Buy if a product on the market already fits how your staff actually work. Building is worth a look when staff would have to change how they work to suit the product.
What should we measure before a new tool goes in?
Measure the slow step the tool is meant to fix, for example turnaround time in days, before anything changes. Then measure the same thing the same way afterwards.
Why test a rough version before signing?
Watching a few daily users try a rough working version shows problems a PowerPoint hides. A large insurer designed and tested new web journeys with customers in two weeks and had them 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. Who we are.
