10 min read

Build or Buy Software in 2025: How to Make the Right Call

Vilim Vulama Posted on November 26, 2025

Quick Take

• Most companies today rely on large SaaS stacks, but their workflows are still scattered across various tools, making it hard to maintain consistency.
• For small and mid-sized teams, it's common to lose €10,000 - €25,000 a year on unused seats, overlapping tools, and add-ons that quietly accumulate.
• Building custom software has become faster, more predictable, and easier to maintain thanks to modern cloud tooling and AI.
• The real advantage in 2025 comes from knowing which workflows still align with SaaS and which ones should be built around the way your team actually works.

Tool stacks are expanding, subscription costs are rising annually, and important workflows are spread across several systems. Teams rely on SaaS for almost everything, yet the day-to-day work still feels scattered and expensive to maintain.

Many companies we speak with today deal with these issues. We've seen it in healthcare platforms that run clinical workflows across multiple dashboards, in property teams managing leasing and maintenance in separate tools, and in SaaS companies carrying long lists of subscriptions to support simple processes. This is the normal operating environment in 2025.

At the same time, building custom software has become faster, more predictable, and easier to maintain. With modern cloud tooling and AI speeding up development, more leaders are revisiting the build-or-buy question as the workflows and costs they manage make the decision relevant again.

In this article, we'll break down why this shift is happening, what's changed on both sides, and how to make a clear, practical decision for your own workflows.

The SaaS Overload Problem

Most companies aren't struggling because one tool is too expensive; the real issue is how many tools it takes to keep a single workflow running. Scheduling lives in one system, reporting in another, documents in a third, and spreadsheets fill the gaps. Over time, the stack grows faster than the business, resulting in increased switching, more maintenance, and greater drift between systems.

This isn't a rare case. According to BetterCloud, the average company today uses 106 SaaS apps, with large organizations often managing hundreds more. With each department building its own stack, information spreads across various tools, making it harder to keep consistent.

Costs follow the same pattern. What we see most often isn't one big expense, but the slow accumulation of smaller ones (unused seats, overlapping tools, and add-ons) purchased for single features. For small and mid-sized teams, this typically amounts to €10,000 to €25,000 of silent waste every year, even when the stack looks reasonable on paper.

SaaS also struggles when the workflow is specific or regulated. We've seen this in healthcare platforms where clinical staff rely on scheduling, documentation, and monitoring tools that need to work together in real time. Off-the-shelf products cover parts of the workflow, but not the full picture, which forces teams to jump between dashboards during critical tasks.

Similar issues appear in operations-heavy environments. In property and facility management, for example, teams often need real-time occupancy data, accurate pricing information, and maintenance tracking inside a single system. Generic SaaS tools rarely support this level of control or specialization, so companies often end up building custom processes to fill the gaps.

SaaS works well for standard, predictable problems. However, as workflows become more specific (or more critical to how a business operates), its limitations become clear quickly.

Why Building Looks More Attractive in 2025

The perception that custom software requires long timelines, large teams, and constant firefighting is fading.

• Modern tooling has significantly reduced many overheads that once made projects difficult.
• Cloud-native infrastructure handles reliability and scaling from the start.
• AI speeds up development by automating repetitive tasks, allowing engineers to focus more on the core logic.

However, this doesn't mean building is effortless. Teams still need clear requirements, a realistic roadmap, and someone who understands how the system will evolve over time. Maintenance doesn't disappear just because the initial build is faster. But the amount of complexity you need to take on has dropped significantly.

For many companies, the difference is noticeable. What once required a large engineering team spread across a year can now be delivered by a smaller senior team in a matter of months. In some cases, weeks. That's why companies spending heavily on SaaS are starting to run the numbers again. Not because SaaS is failing, but because building something tailored, faster, and easier to maintain has become far more realistic.

Build or Buy Software: A Practical Decision Framework

Leaders shouldn't have to decide whether SaaS or custom software is "better", but instead where each makes sense.

Here's a practical build-or-buy decision framework that can help with that:

1. How unique or strategic is the workflow?

This is the most important factor. The more a workflow defines how you operate, the more likely it belongs in a custom system.

• If the workflow defines how your business operates or competes → build.
• If it's standard across industries → buy.

Consider building when:

• It's part of your core value delivery
• It's a differentiator
• It affects customer experience directly
• You keep tweaking or optimizing it internally
• No SaaS tool matches your exact workflow

Consider buying when:

• The workflow is universal: payroll, HR, CRM, email, chat, accounting
• You don't compete in this area
• You don't need customization

Real World Context:

If your competitive advantage relies on a unique process, implementing it in standard software kills your edge. Using the exact same tools as your competitors means you are competing on a level playing field. Building custom software is often the only way to truly differentiate your service.

2. How complex are the integrations and data flows?

The deeper the system must connect to your environment, the less suitable SaaS becomes.

• If the system must connect deeply with your internal data, hardware, or existing platforms → build.
• If it can operate in isolation, or only needs simple syncing → buy.

Consider building when:

• Multiple systems need to sync in real time
• Data needs to move between tools constantly
• Staff rely on the system as a "source of truth"
• You need custom dashboards or workflows driven by your data

Consider buying when:

• The tool doesn't need deep integration
• It's standalone (e.g., internal comms, team collaboration)

Real World Context:

If your team is currently manually exporting CSVs from one SaaS tool to upload them into another every Friday, you have already outgrown your stack. That friction costs more than the software.

3. How fast will this workflow change in the next 1–3 years?

Rapidly evolving workflows will always outgrow SaaS roadmaps.

• If the workflow will evolve frequently → build.
• If the workflow is stable and predictable → buy.

Consider building when:

• You expect to iterate rapidly based on user feedback
• Your product or operations are still evolving
• You foresee multiple changes to workflow logic
• You are in a fast-moving industry (health, logistics, climate tech, SaaS)

Consider buying when:

• Processes are mature and unlikely to change
• The tool's roadmap is ahead of your needs

Real World Context:

A SaaS vendor might tell you a critical feature is coming next year. Can your business afford to wait that long? Building your own tool means you control the roadmap and can deploy changes next week instead of waiting for a vendor to prioritize you.

4. How sensitive is the data and liability involved?

The higher the risk, the more important full control becomes.

• If mistakes could expose you to legal, privacy, or operational risk → build.
• If compliance pressure is low → buy.

Consider building when:

• You're in healthcare, finance, aviation, climate/energy, public safety
• You handle regulated data (patients, devices, payments, identity)
• Audits, traceability, or custom compliance rules matter
• You need full control over uptime and data residency

Consider buying when:

• Data isn't sensitive
• Liability is managed elsewhere
• A secure SaaS provider is sufficient

Real World Context:

When a SaaS provider has downtime, they might offer a credit, but to your customers, it just looks like you failed. Owning the software gives you control over your own uptime and security, so you are never reliant on someone else's status page during a crisis.

5. What will the five-year cost curve look like?

SaaS costs typically scale faster than custom software ownership.

• If SaaS pricing will scale faster than your team size or usage → build.
• If costs stay flat or predictable → buy.

Consider building when:

• User count is growing
• Usage is growing
• Vendor pricing increases annually
• You need multiple add-ons or premium tiers
• You pay for seats that don't get used
• You're already spending six figures on SaaS licenses

Consider buying when:

• Your team is small
• You don't expect user growth
• You need the tool only for a limited phase

Real World Context: The "Light User" Tax

A field technician does not need a $150 enterprise license just to click one button. We often see companies buying full seats for staff who only use 5% of the tool. Building a simple custom portal for those users can often cut your license bill by 90% while improving the user experience.

Our Role in the Build or Buy Software Decision

Most leaders already know SaaS can be expensive and that tool stacks get messy. At Upheave, we help leaders determine where to continue relying on SaaS and where building custom makes more sense.

We do this by:

• Identifying which systems are core to the business and worth building.
• Calculating the long-term costs of SaaS compared to custom.
• Designing modular builds that can scale as the business grows.
• Integrating SaaS tools cleanly where they already fit well.

We aim to bring clarity to leaders, so they can make confident choices and invest where it has the most impact.

Conclusion

The conditions around the build-or-buy decision have changed. SaaS is still valuable, but stacking tools has become expensive and difficult to manage. At the same time, building custom systems is no longer the slow, risky path it used to be. With better infrastructure, smaller teams, and clearer tooling, custom software has become a practical option for far more companies.

In 2025, the advantage comes from being intentional. Use SaaS where it truly fits, and build where your workflows, costs, or customer experience demand something better. Teams that strike this balance right avoid unnecessary spending, reduce operational friction, and end up with systems that match the way they actually work.

If you're already feeling the strain of your current stack, it might be the right moment to look at which parts are worth keeping and which parts would run better if they were built around your workflow instead of someone else's.