frog in a red bowl
28 April, 2026 //

The SaaS trap: Why the cheapest option often isn't

#Advice
#Drupal
#Insights

Daniel Johnson, Developer at Pivale Drupal agency - A man with dark hair and glasses.
Written by Daniel Johnson Backend developer

Daniel is a backend developer, with a keen focus on end-to-end testing, attention to detail and crafting bespoke ecommerce solutions. Daniel is a graduate of Keele University, with a year's study at VU Amsterdam, achieving a first class degree in Computer Science.

You're about to make a decision that feels completely straightforward. A tool exists that does exactly what you need, the pricing looks reasonable, the free trial takes about four minutes to set up, and the sales page is full of logos from companies you recognise and respect. Within a few weeks your team will be using it, and a month from now you'll probably wonder what you did without it.

This isn't a warning about that decision. That decision is, in isolation, a perfectly reasonable one. The tool probably does what it says it does, the people who built it aren't villains, and for a lot of businesses in a lot of situations it will work out just fine.

The problem isn't the decision. The problem is that it's one of several decisions that all looked equally reasonable at the time, and that nobody was looking at what they add up to.

There's an old story about a frog in a pot of water. Put the frog in boiling water and it jumps straight out. But raise the temperature slowly enough and it never notices that anything is wrong until it's too late to do anything about it. Software as a Service (SaaS) pricing is engineered to raise the temperature slowly.

No single invoice feels outrageous. Each individual tool made sense when you signed up for it. It's only when somebody finally pulls up the full picture, the combined annual spend across every platform your business is paying for, that the temperature becomes apparent.

person working at a laptop

How the water starts to heat

It usually starts with one tool. A customer relationship management system (CRM), a marketing platform, something for email automation. And then a second tool because the first one doesn't quite handle that particular thing. And then a third because connecting the first two turns out to be harder than the integration page made it look, and there's a platform that promises to act as the glue between them. Before long you've got a stack: a CRM talking to a marketing platform talking to an email tool talking to a content system, each of them maintained by a different company, each with their own pricing model, each with their own renewal date.

The first sign that something is wrong is almost never the cost. It's the integrations. The more systems you've got wired together, the higher the likelihood that at any given moment something in the chain isn't working properly. A field that stopped syncing. A webhook that silently stopped firing. Data that exists in one platform but hasn't made it to another. These aren't dramatic failures, they're quiet ones, and they tend to surface at exactly the wrong moment, when someone needs a piece of information and it's either missing or wrong.

The cost problem follows, and when it arrives it tends to arrive all at once. Several new contractors need occasional access to the system. Suddenly you're paying hundreds of pounds a month for people who log in twice a quarter, because the pricing model treats every seat (user account) as a revenue opportunity regardless of how much that seat is actually being used. Adding a user costs the vendor essentially nothing, but they've structured their tiers specifically to make headcount expensive.

You put your toe in and they bite your leg off. What started as a free trial, entirely reasonable, has become something that costs thousands every year, and that number goes up every time your business grows or the vendor decides it's time to revisit their pricing.

empty board room

The missing conversation

There's something structural happening here that's worth understanding, because it explains why smart people end up in this situation over and over again.

When a business decides to commission something bespoke, whether that's a piece of software built to its specific requirements, a system designed around its actual workflows rather than a generic template, the decision gets treated accordingly. It needs a business case. It needs a budget discussion. It needs people in the room who are thinking about the long term, not just the immediate problem.

But a SaaS subscription? That can go on a credit card. It can be approved by the person who needs it, in the same afternoon they discover it exists, without anyone else in the business knowing it happened. SaaS vendors have priced their entry points specifically to stay below the threshold that triggers any kind of formal scrutiny. The tool is cheap enough that it doesn't feel like a decision that needs a meeting.

That's not an accident. The thin edge of the wedge is priced and marketed specifically for the moment when there's no one in the room asking the long-term questions. By the time the cumulative cost is large enough to warrant a proper review, your business is already dependent on the tools, your data is already in them, and the practical cost of leaving is high enough that most people just accept the next price increase and move on.

worker building a house

Renting versus building

Think about the difference between renting a property and building one. Renting makes obvious sense in the short term. The monthly cost is manageable, you can be in and operational quickly, and you're not taking on the commitment of ownership. But what you're paying for is the right to use someone else's asset, on their terms, for as long as they're willing to rent it to you. The rent goes up when they decide it should. The rules change when it suits them. And if they decide to sell the building, or a larger landlord acquires the whole portfolio, you might suddenly find yourself in a situation you never agreed to and would never have chosen, absorbed into a new arrangement that works for everyone except the people who were actually living there.

This happens in the SaaS world with a regularity that should give any buyer pause. A product gets acquired. The roadmap changes overnight. A platform that your team has built workflows around gets sunset, or forcibly migrated into a parent ecosystem you never evaluated and would never have chosen on its own merits. When Microsoft overhauled SharePoint into its modern interface, it simply stopped honouring the custom branding and CSS configurations that developers had spent considerable time building, reverting sites to default styling without warning. Myspace, once the platform that launched the careers of artists including Arctic Monkeys and Calvin Harris, lost every piece of music uploaded in its first twelve years during a server migration, wiping out over fifty million songs from fourteen million artists permanently. You didn't sign up for that. But you're in it now, and walking away means rebuilding processes and workflows from scratch, on a platform you've had no hand in shaping, on someone else's timeline.

Building is a different kind of commitment. It costs more upfront, it takes longer before you're operational, and it requires more thought at the outset about what you're actually trying to create. But what you end up with is built to the way your business actually works, not to a generic template designed to suit the broadest possible range of customers. Every pound spent goes into something that belongs to you. And because it belongs to you, nobody can sell it from under you, nobody can change the terms, and when you need to extend it you extend it, rather than waiting for a vendor to add the feature to their roadmap or discovering that it's only available on the enterprise tier. There are platforms built specifically for this kind of long-term ownership model, designed from the ground up to grow with a business rather than to extract value from one, and they're worth knowing about before you sign the next renewal.

There's a reframe worth sitting with here. A custom-built platform isn't just a solution to a problem, it's an asset. A real, tangible business asset that grows in value as you develop it, and belongs to your organisation the way a building or a piece of equipment does. Every SaaS subscription you pay is an operating cost that could have been spent developing real and lasting assets for your business. Every pound invested in something you own is contributing to something that will still be there, still working for you, still yours, long after you've stopped thinking about the decision that created it.

graph showing cost over time of SaaS and built solutions

The cost curve

The SaaS line starts lower. That's the point of it. But it doesn't stay lower, it ramps with your growth. Unlike the custom build line, which starts higher and then flattens to a maintenance level once the initial work is done, the SaaS line climbs in step with every decision you make:

• Every time you bring on new team members
• Every time a new integration becomes necessary
• Every time you move into a new market or take on a new part of your business
• Every time the vendor decides it's time for a pricing review

And critically, every pound on that climbing line is buying you nothing that you own. You're paying for continued access to a capability that disappears the moment you stop paying for it.

The objection that usually comes up at this point is that a custom build is expensive and a known SaaS tool is cheap, and there's something to that, particularly in the early stages. But the question isn't what it costs today. The question is what it costs in year three, and what you own at the end of it. Because for a lot of businesses, especially once you start adding up the full stack rather than looking at each tool individually, the annual cost of maintaining a collection of SaaS subscriptions isn't very far from the upfront cost of a build that you'd own outright from day one. The SaaS option feels cheaper because the number is spread out and the commitment feels lighter. But you've also never stopped paying, and at the end of it you have nothing.

What building actually looks like

Most people never seriously consider a custom build, and it's not hard to understand why. The SaaS option is right there: it has a name you recognise, a pricing page you can read in two minutes, and a free trial that asks almost nothing of you to get started. A bespoke platform, by contrast, has to be imagined before it can be evaluated. It doesn't have a logo or a sales page. It starts with a conversation rather than a credit card. And so for a lot of businesses, the alternative never really enters the room, not because it has been considered and ruled out, but because the subscription was simply easier to see.

What building actually looks like, in practice, is a business that starts with a website and ends up with something considerably more useful. A school that begins with a site explaining its admissions process and, over time, builds out a parent communication portal, an events system, and a content workflow for staff, all running as a single coherent thing rather than three separate tools that have to be kept in sync. An NGO that starts with a donation page and grows into a full membership management and communications platform without ever signing up for a third-party CRM. A retailer who adds a product catalogue, then a customer account system, then a wholesale ordering portal, each new capability extending something they already own rather than adding a new subscription to the pile.

Enter Drupal, the open-source framework designed with exactly this kind of flexibility in mind.

Drupal has been powering this kind of infrastructure for over two decades, on some of the most complex and high-traffic websites in the world. It is one of the most capable open source platforms available for building the kind of digital foundation that grows with a business rather than taxing it for growing. A CRM, digital asset management (DAM), product information management (PIM), ecommerce, marketing automation, content workflows: all of it can exist within a single Drupal installation, built together, sharing the same data, maintained as one system. Not connected via a web of fragile integrations. Not licensed from four different vendors. Built, owned, and controlled by your organisation.

The question worth asking now

If you're at the point of making a decision about your digital infrastructure, whether that's your first serious platform choice or a growing suspicion that the stack you've assembled is starting to cost more than it should, the question worth sitting with isn't whether the tool you're looking at is good. It probably is. The question is what it looks like in three years, who owns the data, what happens when the next requirement comes along, and what your options are if the vendor decides to change the terms.

It's why we build on Drupal, and why we think it's the most honest answer to the question that most businesses are really asking when they start looking at their software stack: not which tools should I be using, but what would it look like to stop renting and start owning something.

With SaaS water heats up slowly, that's rather the point of it. And by the time most businesses notice the temperature, the cost of getting out is already higher than the cost of never having got in.

Daniel Johnson, Developer at Pivale Drupal agency - A man with dark hair and glasses.
Written by Daniel Johnson Backend developer

Daniel is a backend developer, with a keen focus on end-to-end testing, attention to detail and crafting bespoke ecommerce solutions. Daniel is a graduate of Keele University, with a year's study at VU Amsterdam, achieving a first class degree in Computer Science.

Julie Manning, Business Support Director at Pivale digital transformation agency - a woman with blonde hair, and a big smile.

Contact us



Or send us a message...