When replacing a SaaS with your own software pays off

Most companies carry a line of software subscriptions that nobody has questioned in years. Each one was the right call when it was signed. Together they now cost more than an engineer, they price per unit so the bill grows exactly as the business grows, and the features actually used are a fraction of what is paid for.

Build versus buy is an old question. What changed is the answer, because one side of the arithmetic moved.

What actually changed

Building software got faster. Not magically, and not free, but materially: the scaffolding, the integrations, the admin screens, the test coverage, the parts that used to eat the first two months of a project now take days. The same team ships in a quarter what used to take three.

That does not make building free. It moves the break-even line. Work that did not pencil out three years ago pencils out now, and a subscription that was obviously cheaper than building is no longer obviously anything.

Two things did not change, and anyone selling you a rebuild should say so.

Running software is a permanent cost. Hosting, monitoring, updates, someone to call at 2am. Buying moves that cost to a vendor. Building keeps it, and it does not go away after launch.

The vendor absorbs risk you may not want. Payment compliance, tax tables, deliverability, uptime guarantees, certifications your enterprise customers ask about. Some of that is genuinely expensive to take back.

The arithmetic, with the parts people forget

The honest comparison is not "subscription per year" against "project price". It is this.

Buying costs you: the subscription, multiplied by however many units you expect to have in three years rather than today, plus the per-transaction fees the subscription hides, plus the integration work you will do anyway, plus the cost of the things it cannot do that you work around manually.

Building costs you: the build, plus hosting and services, plus roughly 15 to 25 percent of the build each year to keep it alive, plus the internal time to specify it, plus the switching cost of the migration itself.

Two numbers decide it. Your growth rate, because per-unit pricing compounds against you and a built system does not. And how much of the product you use, because paying for a platform to use a fifth of it is the most common version of this mistake.

If the subscription is flat, you are not growing fast, and you use most of what it does, keep it. That is a good deal and you should not let anyone talk you out of it.

Where buying still wins

Be suspicious of a developer who wants to rebuild these.

Payments. Stripe, Shopify, Adyen. The compliance surface is enormous and the fee is worth it.

Email and SMS delivery. Deliverability is a reputation business, not a code problem.

Anything regulated that changes constantly. Tax rates, customs duties, payroll rules. You would be hiring a compliance team, not a developer.

Maps, identity, fraud scoring. Priced sensibly, hard to reproduce, and nobody has ever won a customer by having their own.

Anything that is not your business. Your accounting system does not need to be bespoke. Nobody chose you because of it.

Where building wins

The pricing scales with your success. Per listing, per seat, per booking, per order. You are paying a tax on growth for software whose cost to the vendor does not move when you grow.

You use a fraction of it. A platform bought for one capability, with the other forty in the way.

It is the actual product. When the thing customers interact with is the software, renting it means renting your differentiation, and being unable to change it is a competitive problem rather than an annoyance.

The roadmap is not yours. You have been waiting on a feature for two years, or a release broke a workflow you depend on and there was nothing you could do.

Your data is hard to get out. Which is also the clearest signal that it is time to go, and the reason to go sooner rather than later.

A worked example: a booking engine instead of a subscription

A short-term rental operator was running on Hostaway, a property management platform for the vacation rental market. Perfectly good software, and the right choice when they started.

Two things stopped fitting. The pricing scaled with the portfolio, so every property added cost before it earned anything. And the parts they actually ran their business on were a slice of the platform, with the rest sitting between them and the workflow they wanted.

We rewrote the functionality they used as their own booking engine. Bookings, availability, rates and the direct-booking flow, built around how they actually operate rather than how the platform assumed they would. They own the code and the data, and the bill stopped growing with the portfolio.

Other services in the same stack are being replaced the same way, one at a time, as each one reaches the point where the arithmetic turns. We are not rebuilding everything. We are rebuilding the ones where the sums say so.

How to do it without betting the business

Replace one capability, not the platform. Pick the one with the worst per-unit cost or the worst fit. Ship it. Then decide about the next one with real numbers instead of a projection.

Run both in parallel. The new system writes alongside the old one until the numbers match. The cutover is then a decision, not a leap.

Get the data out first. Before anything is built, export everything and confirm it is complete. If a vendor makes that hard, you have learned something important about staying.

Keep the escape hatch. Any integration you can reconnect, leave reconnectable. The goal is to stop paying for what you do not need, not to prove a point.

Specify from how you work, not from the vendor's menu. The most expensive rebuild is the one that faithfully reproduces a product you only half liked.

What you own at the end

The code, in your repository. The data, in your database. A system that costs the same whether you have fifty units or five hundred, that changes when you decide it should, and that does not have a renewal date.

That is the real return, and it is worth more than the saved subscription: software that is an asset on your side of the balance sheet rather than a line item that grows every year.

If you are looking at a renewal and wondering whether it is still the right call, send us the invoice and what you use it for. We will run the arithmetic honestly, and we will tell you to keep it if that is the answer, because a rebuild that should not have happened is not a win for anyone.