“It went up again.” Finance forwards the renewal notice to the owner. Starting next year, the per-seat price changes, and a feature in the current plan will only be available on the next tier up. The owner does the math. In two years the company has grown from forty people to eighty, and the monthly fee for this system has doubled along with it. Now it is going up again. His first thought: just build our own. Pay once, and never get hit by a price increase again.
I'm Johnny Yang, founder of Brightstream Technology. I have run this company for seven years. My team has delivered more than 252 projects across more than 32 industries, and we ship over NT$20,000,000 in systems a year. Over the past few years, more and more owners have told me “the SaaS raised its price, so I want to build my own.” My first answer is usually not “yes.” It is “run the numbers first.”
A SaaS price increase is not a reason to replace it. It is a time to redo the math. There are three real signals that you should build your own. One: the cost grows with headcount or transaction volume, so the more the company grows, the more you pay, and over three to five years the total is close to the cost of building plus maintaining your own. Two: more and more Excel files and manual work are growing up around the SaaS, and your core process is being bent to fit the tool. Three: your data and your rules are in someone else's hands, and you can't export them or change them. If none of the three apply, it is cheaper to stay and negotiate, or switch to a similar product. If two or more apply, building your own is worth evaluating. Even then, replace the most central, most painful process first. Do not replace everything at once.
Half of the urge to replace your SaaS is right
First, admit the feeling is valid. The discomfort of a price increase is real. They set the price. They decide which plan each feature goes in. Your only choice is to accept or leave. And the more your company depends on it, the more it costs to leave. They know that too.
Per-seat pricing has a structural problem as well. Every person you hire adds another seat to the bill, even if that person only opens the system to look at one order a day. Growth is supposed to be good news. Instead it pushes your fixed monthly costs up.
But the other half needs to be said clearly. Building your own system is not “pay once and never pay again.” After launch, someone has to handle hosting, backups, security updates, and changes in the outside services it depends on. A custom system still has a monthly fee. You are swapping a fee for a “license” for a fee for “someone who understands your system.” If you don't think this through, you may trade a SaaS that raises prices for a system nobody looks after, which starts breaking two years later.
So the question is not whether to escape the price increase. It is whether what you pay still gets you something worth the money.
Run the numbers once: how much more will you pay over three years?
You don't need precision. A few rough numbers are enough. Put the cost of staying on SaaS and the cost of building your own side by side:
| Cost item | Stay on SaaS | Build your own |
|---|---|---|
| One-time cost | Usually none, or just an implementation fee | Build cost, quoted based on spec |
| Fixed monthly cost | Subscription, may be adjusted every year | Maintenance and hosting fees |
| As the company grows | Goes up with headcount or transaction volume | Depends on how the maintenance contract is priced |
| Manual patch-up work outside the system | Hours spent on Excel cleanup and re-entering data | Should go down, depending on how well it fits |
| One-time switching cost | None if you don't switch | Data migration, training, running old and new in parallel |
| Risk of terms changing | They decide pricing and plans | Only counts as yours if the source code and hosting are in your name |
Then use a simple formula to estimate payback time:
Payback months = one-time build cost ÷ (monthly SaaS fee − monthly maintenance after building + monthly patch-up labor saved)
Say an eighty-person company pays NT$60,000 a month for its SaaS after the increase, plus about NT$10,000 a month in staff time patching gaps in Excel. If maintenance on a custom system costs NT$20,000 a month (at Brightstream, maintenance starts at NT$20,000 a month, quoted by system size), the monthly difference is about NT$50,000. If the build quotation is NT$1,500,000, payback takes about thirty months. These numbers are all assumptions. Replace them with your own.
If payback is under three years, building your own deserves a serious look. If it is over five years, staying and negotiating is more realistic, unless other signals apply. Note that if your headcount is still growing, the SaaS column keeps getting bigger, so actual payback will be shorter than your first estimate. For a fuller breakdown of long-term costs, see How to calculate the five-year total cost of an ERP. For a more detailed comparison of subscription versus one-time purchase, see Subscription ERP or custom-built? How to calculate five-year total cost.
What matters is not the size of the increase, but three signals
Even after running the numbers, owners often still hesitate, because money is only part of it. When I judge whether a company should switch, I weigh the following three signals more heavily.
Signal one: the cost grows with you, with no ceiling
One price increase is not the problem. The problem is a pricing model that makes you pay more the more you grow. If the fee is tied to headcount, orders, store count, or data volume, every step the company takes to expand pushes system costs up a tier. The question is not how much it went up this year. It is how big the company will be in three years, and what you will pay each month then.
Signal two: Excel is growing up around the system
This is the signal I weigh most. SaaS is designed to be shared by many companies. Its process is the process of “most companies.” When your process is different, your staff patch the gaps outside the system: a separate Excel file to calculate commissions, chasing progress in a LINE group, manually exporting data every week and reorganizing it.
Those patch-up hours never show up on the SaaS bill. But they are a real cost, and they are usually higher than the subscription. The more patching, the worse the tool fits your company. The price increase just brings it to the surface.
Signal three: your data and rules are in someone else's hands
Can you export your complete data at any time, in a format you can read and move somewhere else? Can you adjust your pricing rules, approval flows, and report definitions to fit your needs? If the answer to both is no, you are locked in on more than price. You are locked in on how you run the business.
You don't feel this signal day to day. You only find out when you try to change something. You want to change bonuses from revenue-based to gross-margin-based, and the system can't do it. You want distributors to check inventory themselves, and that requires upgrading to a more expensive plan. You want to analyze your data, and you can only export some of the fields. Every “can't do that” adds another manual process outside the system. Over time, half of your real operating rules live in the system and half live in your staff's heads. That is more dangerous than a price increase.
If one of these three signals applies, negotiate first, or evaluate similar alternatives. If two or more apply, building your own belongs on the table.
Not switching is also an option: how to choose between four paths
Many owners think the only choices are “put up with it” or “build our own.” There are actually two paths in between.
| Option | When it fits | What to watch for |
|---|---|---|
| Stay and negotiate | None of the three signals is clear, it's just a price increase | Trade a longer contract, prepayment, or a volume commitment for better terms, and write a cap on future increases into the contract |
| Switch to a similar SaaS | Your process is standard, this vendor is just too expensive | Data migration and retraining costs are often underestimated |
| Partly build your own | General features are fine, only the core process doesn't fit | The custom part must be able to exchange data with the SaaS |
| Build everything | All three signals apply and the company is still growing | Someone has to maintain it long term, and the source code and hosting must be in your name |
The first path is often underrated. Many owners get a price increase notice and either accept it or immediately want out. But the period before renewal is when you have the most leverage. You can trade a multi-year contract for price, prepayment for a discount, demand a written cap on annual increases, or ask them to keep the removed feature in your current plan. Even if you end up switching anyway, negotiating once shows you where their floor is and what your alternatives really are.
The one I recommend most often is the third: partly build your own. For things like accounting and HR, where everyone does it more or less the same way, keep using off-the-shelf tools. For the process that actually sets you apart and needs the most patching, such as quotations, order intake, or scheduling, build your own. You spend less and take on less risk, and once it's done you can decide whether to extend further. I cover the overall build-versus-buy framework more fully in Build your own or buy a package? A decision framework for SMEs.
Where building your own usually fails: three traps to avoid first
Before you decide to build, you should also know where builds go wrong. I have seen companies pushed into switching by a price increase end up in more pain than before. The problems usually come from three places.
Copying the SaaS feature list wholesale
The most intuitive way to write requirements is to open the SaaS you use now, list every menu and every button, and tell the developer “build this.” What you get is a more expensive, less mature copy. Many SaaS features exist to serve thousands of companies. You may never use them.
The right starting point is the reverse. First list the handful of actions your team actually does every day. Then add what those Excel files outside the system are patching. The first is your baseline. The second is your reason to build.
Trying to replace everything at once
Price increases make people angry, and when you're angry it's easy to think “let's just start over.” But the bigger the scope, the longer the timeline and the higher the risk. And on launch day, every department has to adapt to a new tool at the same time, so when something breaks, you can't tell where. Start with the most painful process, get it running smoothly, then expand. It looks slower. It is actually faster.
Counting the build cost but not maintenance
A SaaS subscription actually includes hosting, backups, security updates, and customer support. When you build your own, those things don't go away. You just have to arrange them separately. If the contract only covers the build and not who looks after it after launch, then two or three years later the system starts slowing down, throwing errors, and falling behind changes in outside services, and you are back where you started. So when you run the numbers, include maintenance, and ask exactly what it covers and how fast they respond.
You've decided to switch: what order avoids trouble?
The biggest risk in switching systems is not that the new one is bad. It is that the switch interrupts operations. The order below keeps that risk as low as possible.
- Confirm you can get your data out. Before you notify the vendor, run a full export yourself. Confirm that customers, orders, and transaction history all come out, in a format you can read.
- Inventory the Excel files and manual work outside the system. Those patches are the requirements the new system most needs to get right.
- Do the most painful process first. Don't move everything at once. Get the core process running on the new system first.
- Run old and new in parallel for a while. Run both, reconcile the numbers, and only shut off the old one once the new one is stable.
- Finish the cutover before the renewal date. Work backward from it and start at least a few months early. Don't let the renewal date force your decision.
For how to arrange the parallel run and what to watch during cutover week, see How long should old and new systems run in parallel? Planning the cutover week.
One more thing you must do before signing: make sure the source code license, hosting, and domain accounts are all written into the contract as belonging to your company. Otherwise you have just traded being locked in by a SaaS for being locked in by a developer. I cover how to write this into the contract in Who owns the code of a custom-built system?.
FAQ
How big does a company need to be for building to beat SaaS?
It's not about headcount. It's about the three signals above. A twenty-person company with an unusual core process that patches gaps in Excel every day may pay back a custom build quickly. A two-hundred-person company with a standard process and a SaaS that works well is better off staying subscribed. Judging by payback months and the three signals together is more accurate than judging by headcount.
What if I can't export my data from the SaaS?
First check what the contract and terms of service say about data export. Then actually try an export and see what you get and what's missing. For the missing parts, pull them out in batches through reports or the API while the contract is still active, and store them. Do not wait until the day the contract ends to start.
Will building my own just lock me in with the developer instead?
Yes, if the contract isn't clear. The source code license, hosting and domain accounts, and data backups must all be written as belonging to your company, and you should require documentation to be delivered. Do that, and if you later change maintenance vendors, there is something to hand over.
Can I build only part of it and keep using SaaS for the rest?
Yes, and it is often the most practical approach. Build the most central process with the most patching, keep off-the-shelf tools for general functions, and connect the two with data integration. Be careful with master data, such as customers and items. Decide which side is the source of truth, or you will end up with two sets of data that don't agree.
A price increase is a time to redo the math, not a reason to run
Whether to build your own when SaaS prices rise comes down to one sentence: don't switch because of a price increase. Switch because the tool no longer fits. Calculate payback time first, then check the three signals: is the cost growing with you, is Excel growing all around the system, are your data and rules in someone else's hands. If two or more apply, start switching with the most painful process.
If you've gotten this far and want to know how to scope and schedule a system that fits, read How ERP implementation works first, then decide how much to replace and where to start.
