Buy vs build - what to do?

It is a recurring question for any company scaling or expanding; to solve a problem should I buy some software or build it in house? It is a tough question that requires deliberation. Now we will run through the key factors you should consider, peppered with advice from experience of working in a range of companies.

Be real about your requirements:

Ask yourself what the biggest pain points are and just tackle those - building in house can result in project scope creep. Your problem might not be as unique as you thought it was.

Consider what really matters to your business - it can be one, many or all of;

• operational efficiencies,
• unblocking the path to scale your business or expand your product rate,
• meeting regulatory requirements,
• solving a resourcing/specialism shortfall,
• speeding up time to live.

Stakeholders in the business will likely have different drivers, depending on their role. The CFO will want to drive efficiencies, whereas the CPO and CCO will want to speed up time to live.

No matter what is driving your decision making, here are the key aspects to consider when making the call to buy in out-the-box software rather than building something in-house:

Spend money to make money

Benefit cost analysis is key to make the decision that’s right for your business.

On one side, look at how the one off integration cost and SAAS platform fee add up. That being said, fees can creep up over time - watch out for getting locked into a costly contract and incurring ever increasing fees. How is that going to increase over time as your volumes or processing requirements grow? On the other hand, what is the cost of designing, aligning any cross team dependencies, building, and critically maintaining the service?

Time to live for is critical to get to market and validate your product quickly. A SAAS fee is realistically going to be less than the cost of designing, planning, implementing and maintaining a solution in house, particularly when you consider the business upside and revenue that can be generated as a result.

To make a good cost benefit analysis decision, take the whole cost of your contract or take a 2-3 year picture of all the provider costs and compare that versus the in-house cost in order.

Look out for future you

Bear in mind your company mission and roadmap. Will this provider be able to support your expansion plans and grow with you? Expanding into new territories or launching new product lines will incur additional operational and financial complexity - consider how a provider will be able to cater for that growth, versus the alternative of hiring for more people to solve that yourself.

Building integrations in-house can mean you get tied into one payments provider or bank. This is because transaction data and integrations are never implemented in exactly the same way between providers, making the effort of building an alternate integration daunting.

Paralysis when trying to grow your business is a real risk, as we see regularly when companies want to expand into new territories, get a regulatory license or near a new funding round. If your finances aren’t in a shape that will support you, you’ll be in trouble.

The curse of orphan services

Building something quick and dirty in house is often the most effective option at the time. You can cater to all your needs and have as much custom logic as you like. Fast forward a few months and you’re stuck with a service that’s super costly to maintain and causing you incidents, as you can’t afford to dedicate resource just to looking after that service.

Conversely, to ensure your own reliability is not compromised by any suppliers, always make sure they meet your SLAs, plus any specific security or data processing requirements.

Look beyond the initial build and consider who will maintain it, and what that cost will really be.

Some things you just don’t need to know

Have you got the in house capability and capacity to solve this problem, or would your team be better off focussing on your core product offering?

There is no globally implemented standard for payments processing. However there is not shortage of different payments methods and providers. Translating data between them is frankly a nightmare. You can sink a team into analysing, building and maintaining data mapping logic and processing, if you have resource to spare. However that is not a reality unless something is going wrong with your roadmap and strategy.

Find a supplier that’s an expert in the problem you’re trying to solve, and then you can focus on what really matters.

Ultimately it comes down to keeping focussed on what you’re trying to solve.

If you’re still stuck, create a matrix with the key decision factors, map out your needs with strict prioritisation vs the options you’re considering, to get a clear view of what really matters:

• Time to live - what resources do you have available?
• Cost of implementation - do you have enough expertise in house? How long is this going to take to go live?
• Cost of maintenance - will you need a team dedicated towards this?
• Requirements - product/technical/security

🗣️ Talk to us about how we can handle your reconciliation and payments pains for you.