Shimira IT
Short answer: replacing SaaS subscriptions with your own software pays off when the subscriptions are priced per seat, you have a lot of seats, and the tools are not doing anything regulated or highly specialised. For a 40-person team it rarely pays. For a 200-person team paying for the same tools, it can pay back in under a year. The deciding numbers are your seat count, the build cost, and the running cost of the software you build, and you can work them out before you talk to anyone.
This post shows the sum, two worked examples, and the categories of software you should almost never rebuild.
Why the question keeps coming up
SaaS costs have grown into a real line item. Zylo's 2026 SaaS Management Index, based on more than 40 million licences and $75 billion of spend, found:
- Median SaaS spend per employee: $9,455 a year
- Organisations leave an average of 36% of their SaaS licences unused
- Business units, not IT, control 81% of SaaS spend
- 78% of IT leaders reported unexpected charges from consumption-based or AI pricing in the past year, and 61% had to cut projects because of unplanned SaaS cost increases
At the same time, building software has become faster. AI coding tools such as Lovable and Bolt let a founder or an operations lead produce a working internal app in days. That combination, rising subscription bills and cheaper-looking software, is why "can we just build our own?" is now a regular boardroom question.
The break-even sum
Compare what you pay for the subscriptions with what owning the replacement costs:
Payback period = build cost ÷ (annual SaaS cost − annual running cost of your own software)
The running cost is what people forget. Owned software needs:
- Maintenance: budget 15–25% of the build cost every year for security patches, dependency updates, bug fixes, and small changes. Our software maintenance cost guide explains where that figure comes from.
- Hosting and services: cloud hosting, a database, email delivery, monitoring, and backups.
- Ownership time: someone on your side who decides what changes and answers users' questions.
If the annual saving after running costs is small, the payback period stretches past the point where the software needs significant rework anyway, and buying wins.
Worked example 1: a 40-person company
A 40-person business pays for three tools that together cover its client work: a project tracker, a client portal, and a forms-and-approvals tool. Combined, they cost $75 per person per month.
- Annual SaaS cost: 40 × $75 × 12 = $36,000
- Build cost for one internal app covering the parts of all three that the team actually uses: $80,000
- Annual running cost: 20% maintenance ($16,000) plus $3,000 hosting and services = $19,000
- Annual saving: $36,000 − $19,000 = $17,000
- Payback: $80,000 ÷ $17,000 = about 4.7 years
Over five years, the subscriptions cost $180,000 and the custom software costs $80,000 + 5 × $19,000 = $175,000. That is close to even, with all the risk of a software project on one side. Verdict: keep paying for the SaaS, cancel unused seats, and revisit when the team grows.
Worked example 2: a 200-person company
The same three tools, the same $75 per person per month, but 200 people.
- Annual SaaS cost: 200 × $75 × 12 = $180,000
- Build cost, larger because of more roles, more data, and more load: $120,000
- Annual running cost: 20% maintenance ($24,000) plus $6,000 hosting and services = $30,000
- Annual saving: $180,000 − $30,000 = $150,000
- Payback: $120,000 ÷ $150,000 = about 10 months
Over five years: $900,000 in subscriptions against $270,000 to build and run. Verdict: worth a serious look, provided the replacement is scoped to what people actually use, not every feature the vendors offer.
These examples assume flat subscription prices. If your vendors raise prices each year, or move features to higher tiers, the case for replacing them gets stronger. If your seat count is falling, it gets weaker.
What the examples show
- Seat count drives the decision. Per-seat pricing scales with headcount, while owned software costs roughly the same whether 50 or 500 people use it. The more seats, the faster the payback.
- You only need to replace what you use. Most teams use a fraction of a SaaS product's features. A replacement built around your actual workflow is smaller, and cheaper, than the product it replaces.
- Running costs decide the close calls. Leave maintenance out of the sum and almost every replacement looks like a bargain.
What you should almost never rebuild
Some software is cheap to buy precisely because it is expensive to build and keep correct. Keep paying for:
- Accounting, payroll, and tax software. The rules change every year and mistakes have legal consequences.
- Email, calendars, and video calls. Commodity services with enormous reliability engineering behind them.
- Identity and sign-in. Use an established provider for logins and single sign-on; build on top of it.
- Payments. Use a payment processor. Building card handling yourself brings compliance obligations that dwarf any saving.
- Anything where the vendor's value is its network or data, such as marketplaces and data providers.
The best candidates are the opposite: tools that encode your own process, such as approvals, job tracking, client portals, internal dashboards, and the glue between systems. That is where off-the-shelf products force workarounds and where your own software fits better as well as costing less. We cover how to spot these in custom internal business software: when to build it.
The middle path: replace one tool, connect the rest
Replacing everything at once is the most common way these projects go wrong. A safer order:
- Audit seats first. With an average of 36% of licences unused, cancelling seats may save more than building anything.
- Pick the most expensive tool that encodes your own process and replace that one.
- Keep your systems of record, such as accounting and CRM, and connect the new app to them through their APIs.
- Run old and new side by side for a few weeks before you cancel the subscription.
A note on building it yourself with AI tools
It is now realistic for a non-developer to build a working replacement with an AI app builder. For internal tools with a handful of users, that can be the right answer. The risk appears when the app becomes something the business depends on: access controls that were never set, data that anyone can read, payments that misfire, and no one who understands the code when it breaks. If you go this route, run through our vibe-coded app production checklist before customer or financial data goes into it. If it's already in use and creaking, that is what our vibe-coded app rescue service is for.
Do the sum before you talk to a vendor
Gather three numbers: what you pay each year for the tools in question, how many seats you actually use, and a realistic build estimate. Our custom software development cost guide has a calculator for the third. Then apply the payback sum with running costs included.
If the payback is under two years and the tools encode your own process, replacing them is worth exploring. If it's over three years, keep the subscriptions and cut unused seats. If you want a second opinion, tell us which tools you're paying for and we'll give you an honest read, including when the answer is to keep paying for them.
Sources
- Zylo, 2026 SaaS Management Index
- Worked examples use illustrative prices and Shimira IT's typical build and maintenance ranges; substitute your own figures.