Buy vs build: why we think most businesses get this decision wrong

The annual software audit. You know the one. Someone in finance pulls together a spreadsheet of every SaaS subscription the company pays for. The room goes quiet. Slowly, people start asking: "Wait, do we still use that?" and "Who signed up for this?" and the inevitable "How much are we spending on this stuff?"

At Dain, we see this conversation play out constantly. And what strikes us isn't the total spend, though that's often eye-watering. It's how resigned everyone seems. As if paying £50,000 a year for tools that half-work and don't talk to each other is just the cost of doing business.

It isn't. But unpicking it requires asking a question most companies avoid: should we have built this ourselves?

The subscription fatigue is real

Let's start with what's changed.

Five years ago, the default advice was simple: buy, don't build. Why would you spend months developing something when you can sign up to a tool this afternoon? SaaS was the answer to everything. Need a CRM? Buy one. Project management? There's an app for that. Reporting? Analytics? HR? Payroll? Just add another line to the subscription list.

And for a while, it made sense. The tools were cheap enough. The time saved was real. Nobody wanted to be the company that wasted six months building something they could have bought for £99 a month.

But then a few things happened.

The £99 plans became £299 plans. Then £499. Then "contact us for enterprise pricing." Features that used to be included became add-ons. Per-seat licensing meant your costs scaled with your headcount whether the value did or not. And suddenly that tool you signed up for in 2019 is costing you £15,000 a year and you're not even sure if anyone uses it properly.

The same tool, three price points

We're now seeing C-levels and exec teams hitting genuine subscription fatigue. Not just frustration at the cost, but exhaustion at the complexity. Every tool requires its own login, its own training, its own admin. Data lives in fifteen different places. Nothing integrates cleanly. And the promise of "it just works" feels like a joke.

The question nobody asks early enough

Here's what frustrates us: the buy vs build conversation usually happens too late.

By the time someone asks "should we build this ourselves?", the company has already been paying for a tool that doesn't quite fit for three years. They've built workarounds on top of workarounds. Staff have learned to live with the limitations. The switching cost feels enormous, not because it is, but because nobody can remember what life was like before.

The right time to ask the question is before you buy. And the question isn't "is there a tool for this?" There's always a tool. The question is: "Will this tool actually do what we need, or will we spend the next five years bending our processes around its limitations?"

Most companies skip this. They Google the problem, find three vendors, sit through some demos, pick the one with the nicest interface, and sign a contract. Six months later, they're hiring someone to manually export data from that system into another because the integration doesn't work properly.

Our unpopular opinion: building is often cheaper than buying

We know this sounds counterintuitive. The received wisdom is that building software is expensive and time-consuming, while buying is quick and predictable. And for some things, that's true. We're not suggesting you build your own email client or accounting software.

But for the tools that sit at the heart of how your business actually operates? The ones that manage your specific workflows, your specific data, your specific reporting needs? Building often wins.

Here's why.

The true cost of buying is hidden. That £1,000 a month subscription looks cheap until you factor in:

• The time your team spends working around its limitations
• The manual data entry because it doesn't integrate with your other systems
• The consultants you hire to configure it
• The training costs every time they push an update that changes how everything works
• The productivity lost when it goes down and you have no control over when it comes back

We've seen companies paying six figures a year for software that actively makes their teams slower. Not because the software is bad, but because it was never designed for how they work.

Custom software costs less than you think. The horror stories about custom development, the two-year projects that went three times over budget and still didn't work, those are real. But they're usually the result of trying to build something massive all at once, with unclear requirements, handed off to an agency who disappears after launch.

That's not how we work. We start small. We build the thing you actually need, not the thing with 200 features you might use someday. We iterate based on real feedback from real users. And critically, we build it so you can maintain and extend it. You're not dependent on us forever.

A focused tool that does exactly what you need, built in weeks rather than months, often costs less than two years of subscription fees for something that doesn't.

You own it. This is the bit people underestimate. When you buy software, you're renting. You're subject to their pricing changes, their roadmap decisions, their support quality, their uptime. If they get acquired, you're at the mercy of the new owner. If they pivot, your feature requests go to the bottom of the pile. If they go bust, you're scrambling.

When you build, you own the IP. You control the roadmap. You decide what gets built next based on what your business needs, not what their product team thinks will attract new customers. No more waiting eighteen months for a feature that would take a developer two weeks.

When buying still makes sense

We're not ideological about this. Sometimes buying is the right answer.

When it's genuinely commoditised. Email, calendars, basic document storage, accounting. These are solved problems. The tools are mature, the integrations are standardised, and the cost of building would be absurd. Don't build your own Google Workspace.

When speed matters more than fit. If you're a startup trying to validate an idea, you don't need perfect tools. You need to move fast. Buy the quickest thing that works, prove the concept, and figure out the long-term solution later. The mistake is forgetting to revisit that decision once you've grown.

When the problem is genuinely complex and outside your expertise. Payroll calculations, tax compliance, payment processing. These involve constantly changing regulations and significant liability if you get them wrong. Unless that's your core business, buy from specialists.

When the maintenance burden would distract from your core work. Building software is one thing. Maintaining it is another. If you don't have the in-house capability to support what you build, you're trading subscription fees for contractor fees. Sometimes that's still the right call, but go in with your eyes open.

The honest pros and cons

We've put together the real trade-offs, not just the headline benefits, but the flipside of each. Because nothing is straightforward with this decision.

Internal software build

Pros

Cons

Vendor software buy

Pros

Cons

The hybrid approach most people miss

Here's what we often recommend: buy the commodity stuff, build the core stuff, and invest heavily in integration.

Your business probably doesn't need custom accounting software. But it might need a custom dashboard that pulls data from your accounting software, your CRM, your project management tool, and your ops system, because that view doesn't exist anywhere else and it's the thing that would actually help you make decisions.

That's not a massive development project. That's a few weeks of focused work. And it can transform how your leadership team understands the business.

Or maybe you need a booking system. The off-the-shelf options are fine for generic use cases, but they don't handle your specific workflow, the way you allocate resources, the approval steps, the data you need to capture. You can either force your process into their structure, or build something that fits how you actually work.

We've seen companies save tens of thousands a year by building exactly what they need instead of paying for platforms with hundreds of features they'll never touch. More importantly, we've seen teams get faster, less frustrated, and more focused, because they're not fighting their tools every day.

The real risk nobody talks about: vendor lock-in

Let's talk about something the sales reps don't mention in demos.

When you build your business processes around a vendor's tool, you're creating dependency. Your data is in their format. Your workflows are shaped by their assumptions. Your team's expertise is in their interface. Every month that passes, the switching cost grows.

This gives vendors enormous power. They know you're not going to leave over a 20% price increase. They know you'll grumble about the new UI but eventually adapt. They know that even if a competitor offers something better, the pain of migration will keep you where you are.

We've worked with companies who wanted to leave a platform they'd outgrown but couldn't, because three years of data was locked in proprietary formats, because their entire team was trained on that specific tool, because the integrations they'd built would all need to be rebuilt.

That's not a technology problem. It's a strategic risk that got ignored until it was too late.

How we approach this at Dain

When a client comes to us with a buy vs build question, we don't start with the technology. We start with three questions.

What's the strategic goal?

Not "we need a CRM". That's a solution, not a goal. What are you actually trying to achieve? Better customer retention? Faster sales cycles? Clearer pipeline visibility? The goal shapes everything. Sometimes the answer isn't a new tool at all. It's fixing the data quality in what you already have.

Where does this sit in your business?

If it's core to how you operate and compete, you probably want control over it. If it's a supporting function that looks the same in every company, you probably don't need to build it. The mistake is treating everything as either core or commodity. Most businesses have a few things in the middle that deserve more thought.

What's the five-year cost of each path?

Not just the sticker price. The implementation cost. The training. The integrations. The workarounds. The time spent on manual processes the tool doesn't handle. The opportunity cost of your team fighting software instead of doing their actual jobs.

When you do this analysis honestly, building wins more often than people expect.

The conversation is shifting

We're seeing more companies come to us having already decided they want to build. Not because they've read a blog post about it, but because they've lived through the alternative. They've experienced the vendor who hiked prices after acquisition. The platform that deprecated the feature they relied on. The integration that broke and took weeks to fix because it wasn't their system.

They've done the maths on what they're spending and realised they could have a full-time developer for less than their annual SaaS bill, and that developer could build exactly what they need.

This isn't a universal shift. Plenty of companies are still buying everything and will continue to. But for organisations who take their operations seriously, who see their systems as a competitive advantage rather than a cost centre, the conversation has changed.

The bottom line

Buy vs build isn't a religious debate. It's a strategic decision that deserves serious analysis, not default assumptions.

If you're experiencing subscription fatigue, if your tools don't talk to each other, if your team spends more time on workarounds than actual work, it might be time to ask whether the "easy" option of buying has actually made things harder.

We're not saying build everything. We're saying build the things that matter, buy the things that don't, and stop assuming that paying for software means it's working for you.

Frequently asked questions

Isn't building software risky? What if the project goes over budget?

The horror stories about custom software usually involve massive, vaguely-defined projects with no clear ownership. We work differently: small, focused builds with clear scope, regular check-ins, and working software delivered in weeks rather than months. The risk is manageable when you're not trying to boil the ocean.

We don't have developers in-house. How would we maintain custom software?

This is a valid concern and part of the decision. We build with maintainability in mind: clean code, good documentation, standard technologies. Some clients bring us back for updates, others hire developers once they see the value. We're also happy to train your team. But if ongoing maintenance feels impossible, that should factor into whether building is right for you.

What if we build something and then a perfect off-the-shelf solution launches?

Then you evaluate it like any other option. The difference is you'll have something that works in the meantime, you'll own the IP, and you'll have a much clearer understanding of your actual requirements, which makes evaluating new tools easier, not harder.

How do we convince leadership that building is worth the upfront investment?

Show them the five-year cost comparison. Add up what you're currently spending on subscriptions, implementation, training, integrations, and the hidden cost of workarounds. Compare that to a realistic build cost plus maintenance. When you frame it as total cost of ownership rather than upfront cost, the numbers often speak for themselves.

Where do we start if we want to explore this?

Start with your pain points. Which tools frustrate your team most? Where is data falling through the cracks? What manual processes are eating up time? That's usually where the biggest opportunities are. We're happy to help you map this out. Book a discovery call and we'll take a look together.