Why Your SaaS Bill Keeps Growing

Since the early days of the web, getting an email signup form onto your site meant talking to a developer. Someone had to write the form, wire it to a database, handle the confirmation email, manage the unsubscribes. It was a whole thing.

Mailchimp solved it. Drop a snippet, get a form, build your list. No developer required. Then they added a template builder so you could send emails without one either. That was the whole business, and it worked because the pain it removed was real.

Every SaaS tool built since has been a variation on the same play: find something that requires a developer, remove that dependency, charge monthly for the privilege.

Today you don’t even need a developer to build the site. You spin up Squarespace on a Sunday afternoon. Connect Mailchimp for email. Drop in Google Analytics. Add a live chat widget. Hook up a booking tool. Each one arrives with a native integration or a snippet and a promise: five minutes, no developer, done.

So you do it again. And again. A/B testing. Event tracking. A CDP to tie the first two together. A Zapier workflow to fill the gap the CDP couldn’t quite close.

Before you know it you’ve got sixteen SaaS tools stacked on top of each other, glued together with Zapier, and you’ve never once had to talk to a developer.

And the pricing compounds the same way the tools do. Most platforms charge by some kind of metric that they portray as increased value. Your email tool charges by contact list size, not by sends. Some clip a percentage of every sale on top of the subscription fee as well. But are they actually delivering more value for you, or are you delivering more value to them?

You built the stack without a developer, and now there’s nobody in the building to question the invoice. The SaaS vendors know that too.

Each decision made complete sense at the time. The problem isn’t any one tool, it’s what the stack looks like twelve months later when those free trials are a distant memory. You add up the invoices and ask yourself – do I really need all of this!?

The answer depends where you are on the timeline, but it usually goes: yes, maybe, and probably not.

As you grow, those percentages grow with you. Your success benefits every vendor in your stack. And each month you’re paying for access to the full feature set of those sixteen tools whether you use them or not.

This post looks at three categories where the underlying code is more straightforward than the pricing suggests and where a custom build might serve you better in the long run.

Email Marketing: You’re Paying for Storage, Not Sends

Klaviyo, Mailchimp, ActiveCampaign and any other player in this game, they all promise sophisticated customer segmentation and automated sends.

But here’s their real business model: they charge you based on list size, not sends. You have 10,000 contacts? That’s $300/month, whether you email them once a year or once a week. All the trinkets in the store are what they use to keep you occupied with the next shiny widget to integrate. And the more integrations they convince you to plug into their platform, the more you get convinced you can’t live without it.

What they’re actually doing:

1. You define a segment (“customers who bought in the last 60 days and spent more than $200”)
2. The tool stores your entire customer database
3. When a trigger happens (new customer signs up, purchase completes), the tool checks the condition
4. If true, it sends an email

That’s not magic. It’s an if/then statement plus email storage.

In Rails, this looks like:

customers = Customer.where("last_purchase_at > ?", 60.days.ago)
  .where("lifetime_value > 200")
customers.each do |customer|
  SendWelcomeEmailJob.perform_later(customer.id)
end

The actual email delivery goes through SendGrid, Mailgun or Postmark. You pay per send, not per contact stored. The logic, the segmentation, the triggers, the decision tree all live in your codebase that you own.

The templates question is the honest counterpoint here. HTML email templates are genuinely painful to build. Drag-and-drop editors are actually useful. But you probably use at most one or two templates. Your transactional email, your newsletter, maybe a promotional variant. Once those are built, they’re done until your next re-brand. That’s a one-time investment, not a reason to pay monthly forever.

Own the customer data. Own the segmentation logic. Own the template. The email vendor is just the delivery mechanism, not the brains.

Event Tracking: A Message Queue with a Fancy UI

Segment and Mixpanel are Customer Data Platforms (CDPs) that log customer events and route them to your other tools: your email platform, your CRM, your analytics. Sounds complex. It’s a background job with a list of API calls.

Customer views a product page? Log it. Customer adds to cart? Log it. Customer abandons checkout? Log it, wait 30 minutes, trigger a recovery email.

An abandonment workflow is just event routing with a timer attached. A background job that fires if the purchase event never follows the cart event within a defined window. It’s not a separate product category; it’s a few lines of conditional logic.

This is a message queue. When an event happens in your app, you publish it. Background jobs subscribe and forward it to whatever needs it. Solid Queue handles the job processing. The forwarding logic is just API calls.

The abandonment workflow your team is so impressed by? A Solid Queue job with a 30-minute delay.

A/B Testing: What You’re Actually Paying For

Optimizely, VWO, Convert are A/B testing platforms that promise to let you experiment on your site without touching the code.

The split gem does the core mechanic natively. It uses Redis to assign and persist variants, tracks conversions, and gives you a dashboard to monitor results.

ab_test("checkout_button", "Buy Now", "Complete Purchase") do |variant|
  render_button(variant)
end
# When the user converts:
finished("checkout_button")

So what are you actually paying for with Optimizely?

The snippet. A JavaScript tag you drop on your site that lets non-technical team members inject variant code through a visual editor and no deployments required. That’s the real value proposition: running experiments without a developer.

If you have a developer on retainer anyway, you’re paying hundreds or thousands of dollars a month to avoid a conversation you should be having with them anyway. The dashboard, the reporting, the “advanced” features; most teams use them a handful of times a year.

Why SaaS Is Seductive (And Why That’s Not Wrong)

None of this is to say SaaS tools are a bad deal. The pitch is genuinely compelling.

Drop a snippet and your A/B testing is live today. No ticket, no sprint, no waiting for a developer to be available. Your marketing team can build an abandonment workflow before lunch without talking to anyone in engineering. Your email platform comes with templates, deliverability infrastructure, and a support team. Someone else handles the uptime, the security patches, the scaling.

That independence has real value. The time you’d spend briefing a developer, reviewing a change, and waiting for it to go into production is time you’re not moving the business forward.

The SaaS model is optimised for speed to capability. And at the start when you don’t know exactly what you need yet, all that capability for a monthly fee seems great.

A SaaS platform is a bus. Cheap to ride, convenient, gets most people where they’re going — slowly. A custom build is a motorcycle. You have to build it, maintain it, but it goes exactly where you need, fast.

You get on the bus and you’re moving. Zero effort, faster than walking, feels like progress. Until you’ve ridden a motorcycle.

The question isn’t whether SaaS tools are good. Most of them are. The question is whether you’re still getting that value months or years later, when the tool is embedded, the initial excitement has worn off, and you’re paying the monthly invoice out of habit rather than intention.

But something useful happens after a year or two in the stack: you know exactly what you actually use. The features you open every day and the ones you’ve never touched. The workflows that fit your business and the ones you’ve bent your business to fit. That’s the moment to start thinking about a custom solution; one built around what you actually need, that doesn’t charge you more for using it well.

Because eventually the developer conversation happens anyway. The tool doesn’t export data the way you need it. The API doesn’t support the integration you’re trying to build. The workflow you want is one tier above your current plan. You end up in a support queue with a vendor who has thousands of customers with conflicting priorities, and your specific problem isn’t on anyone’s roadmap.

The snippet got you moving. But at some point, moving fast on someone else’s platform means moving at someone else’s pace.

Each of these tools comes loaded with features for every possible use case. Templates for every industry. Workflow builders for every scenario. Integrations for tools you’ve never heard of.

You use a fraction of it. The rest sits there idle, but is on the invoice, every month.

That’s the subscription model working as intended from the vendor’s perspective. You pay for access to the full feature set whether you use it or not. Adding new capabilities to the platform doesn’t cost you more, but it doesn’t benefit you either. You’re subsidising features for other customers.

And a meaningful chunk of every subscription fee goes towards convincing the next customer to sign up, not towards the product you’re using. The sales rep who cold-emailed you, the conference booth, the G2 review campaign, the integrations team that built the connector to make the demo easier, that’s all in the price. A custom build has none of that overhead. You’re paying for the code, the hosting, and the developer’s time, but you get exactly what you need, and you own it.

A SaaS subscription? Each month you’re paying for access to features you never use, and to get their next customer onto a free trial.

A custom system? New investment goes into new features your business will use, and to get your next customer in the door.

MV Studio works with ecommerce businesses that have outgrown their stack and want to stop paying for tools they don’t use. Start with a conversation.