Should You Cancel Your Expensive SaaS and Build It Yourself? Seven Tests for the AI Era

Hello, this is Ryuta Hamamoto from TIMEWELL.

Have you ever opened a SaaS renewal quote, seen a number higher than last year's, and thought, "We could build this ourselves for less"? Now that generative AI has pushed down the cost of writing code, that thought feels more realistic than it used to.

Let me state my position up front. Most SaaS should not be cancelled. Work bound by law, like accounting and payroll, is still best left to SaaS. But for work that is billed per user, changes slowly, and runs on simple logic, rebuilding has started to make sense. The hard part is deciding where that line falls.

This article sets out seven tests for deciding whether to cancel a SaaS you already pay for and build your own replacement. It is the first of a five-part series. The other four cover how to pick candidates, how to estimate five-year cost, how to handle cancellation and migration, and how to design the system on your own cloud. I wrote about the broader question of how much AI work to keep in-house in How far to insource AI. This piece narrows the question to one thing: should you stop paying for the SaaS you use today?

Why "we could build it cheaper" is starting to sound right

Two forces make SaaS bills look bloated: list prices going up, and, for companies paying in yen, a weaker currency.

Here is one example. The Japanese arm of a major global software company raised yen prices for its enterprise software and cloud services by 20 percent across the board from April 1, 2024. It also said it may continue adjusting local-currency prices as part of a twice-yearly price review that takes the dollar exchange rate into account¹. So for a Japanese buyer, a SaaS price can move through two channels: a change in the dollar list price, and a revision of the yen price.

The exchange rate tells the rest of the story. Averaging the Bank of Japan's monthly figures by calendar year, the dollar was worth 106.78 yen in 2020, 151.50 yen in 2024, and 158.78 yen from January to August 2026 (my own calculation from BOJ data)². That is more than a 40 percent drop in the yen against 2020. Services priced in dollars cost more in yen every year even if nobody touches the contract.

Japanese companies feel this. In the 2026 edition of the IT trends survey by JUAS, an association of corporate IT users, the second most common reason for rising IT budgets was "the weak yen, rising labor costs, and vendor price increases," cited by 46.6 percent of companies in their fiscal 2025 plans³. The same survey found that the top expected benefit of insourcing system development was now "lower development cost" (41.3 percent), overtaking last year's leader, "building in-house knowledge." The report's own reading is that steep vendor price increases have made "immediate cost reduction" a fast-rising priority³.

Then came generative AI. A survey by an overseas developer-tools company of 817 of its own users (published February 2026) found that 35 percent had replaced at least one SaaS tool with something they built. Keep in mind who answered, though. These are people who already use tools for building software, so the sample leans much further toward building than the average company.

The story people like to cite is Klarna, the Swedish payments company. Its move away from a major CRM got a lot of attention and was widely read as AI replacing SaaS. But CEO Sebastian Siemiatkowski himself wrote on X in March 2025 that, by an internal estimate, the company had shut down about 1,200 SaaS tools, while stating plainly that it did not replace SaaS with an LLM and that storing CRM data in an LLM would have its limits⁴. What Klarna actually did was build an internal tech stack, using Neo4j among other things, to bring its data together as knowledge. He also wrote, "Will all companies do what Klarna does? I doubt it."⁵

To me, that explanation is the most useful part of the whole story. Klarna could drop those tools not because AI built new screens, but because it first pulled together data scattered across many SaaS products. Screens are easy to build later. If you cancel before your data is consolidated, you may just end up with more in-house tools doing the same job.

Still, staying on SaaS is usually the right call

I want to lay out the evidence against my own argument first. Leaving it out would mislead you.

Public guidance in Japan leans clearly toward SaaS. METI's DX Report 2 (December 2020) says companies should "abandon the do-it-yourself mindset" in non-differentiating areas, standardize their processes, use SaaS and packaged software, and hold down IT spending and headcount there⁶. DS-310, the Digital Agency's guideline for government information systems (May 2025), asks agencies to consider SaaS broadly and as a first option, because it cuts the amount of development⁷.

Corporate practice points the same way. According to IPA's DX Trends 2025, Japanese companies source non-core systems through packaged software 33.8 percent of the time and SaaS 24.4 percent, with in-house development at only 16.6 percent. Just 22.3 percent of Japanese companies say they are actively insourcing system development, against 46.4 percent in the US. And 82.3 percent of the Japanese companies that are insourcing say that hiring and developing people is their biggest challenge⁸.

The claim that AI makes development faster also comes with caveats. In METR's randomized controlled trial with 16 experienced open-source developers working on 246 real issues, tasks took 19 percent longer when AI tools were allowed. The developers had expected a 24 percent speedup and, even afterward, believed AI had made them 20 percent faster⁹. METR's February 2026 follow-up estimated that late-2025 tools cut task time by 18 percent, but the confidence interval runs from minus 38 to plus 9 percent, crossing zero¹⁰. The 2025 DORA research, based on nearly 5,000 technology professionals, found a positive relationship between AI adoption and delivery throughput, alongside a continuing negative relationship with delivery stability¹¹. And in a study by Veracode, a security vendor, 45 percent of code samples generated by more than 100 LLMs failed security tests¹².

Building something fast and running it safely for years are different problems. Part of what you pay a SaaS vendor covers the second one.

So why write about cancelling at all? Because DS-310 itself spells out the exception. It says SaaS is strongly recommended but not unconditionally. Where fees can become expensive during operation, for example when the number of users grows step by step, the guideline calls for a careful lifecycle-cost check on whether SaaS really saves money. If a managed service can deliver the same functions, both options should be compared. Elsewhere it specifically warns that for SaaS billed per account, and for expensive SaaS, the growth in account numbers deserves close attention⁷.

I am keeping this article inside that exception. The message is not "drop your SaaS." It is: find the services that fit the exception, and consider rebuilding only those.

Seven tests for deciding whether to cancel

Here are the seven tests I use, in one table. None of them decides the question alone. The point is to look at all seven side by side.

Test	What to look at	Signs cancellation is worth considering	Signs you should stay
1. Annual cost and price increases	Current annual fee, past price changes, currency exposure	Large annual fee, repeated increases	Small annual fee, building would clearly cost more
2. User growth and per-seat pricing	Billing unit, how fast users grow	Billed per user, user count keeps rising	Flat fee, or user count barely moves
3. How slowly data and features change	How often fields and screens change	Same fields and steps for years	You use new features almost monthly
4. Legal and accounting complexity	Keeping up with tax, accounting, and industry rules	Internal work that legal changes do not touch	Accounting, payroll, tax filing, and other frequently revised work
5. Integrations with other systems	Number and direction of connected systems	Few integrations, limited data entry and exit points	Two-way connections with many outside services
6. Who maintains it	The person who fixes it, their time, a partner	A named owner with protected time, plus a partner	Nobody can own it, or only as a side task
7. Cancellation and migration terms	Renewal date, notice deadline, data export	Full export in a usable format, plenty of time	Notice deadline is close, some data cannot be exported

1. Annual cost and future price increases

Start with what you pay now and what you are likely to pay later. It sounds obvious, but my impression is that plenty of companies look at the annual invoice without ever lining up five years of price changes and currency effects side by side.

You need three numbers: the current annual fee, how often and how much the price has changed, and, for services priced in dollars, how sensitive the bill is to the exchange rate. For a service that says it reviews prices twice a year, work out how much the annual fee moves if the dollar shifts by 10 yen. That turns a vague budget debate into a concrete one.

At the other end, cancelling a SaaS that costs a few thousand dollars a year and rebuilding it almost never pays off. Add development, maintenance time, and hosting, and you blow past the savings. In practice this test is more useful for ruling services out than for ruling them in. I cover how to run the five-year numbers in part three, Five-year SaaS TCO.

2. User growth and per-seat pricing

This is the test DS-310 singles out⁷. With per-user monthly pricing, the bill grows as the company grows, even though the features stay the same.

Let me run some illustrative numbers. At 3,000 yen per user per month, 300 users cost 10.8 million yen a year. If users grow 20 percent a year and the unit price rises 5 percent a year, you reach about 620 users in year five, an annual bill of about 27.2 million yen, and a five-year total of about 90.4 million yen. With users and price held flat, five years would cost 54 million yen, so the gap is about 36 million yen. (These are TIMEWELL's assumptions, not market data. Your prices and growth rates will differ.)

The cost of building does not double when your user count doubles. Hosting goes up, but nowhere near as steeply as per-seat billing. The gap matters most for tools everyone in the company touches, like the intranet, request forms, and registers. In Japan's 2025 Communications Usage Trend Survey, 83.5 percent of companies used cloud services at least in part, and the second most common use was "internal information sharing and portals" (61.4 percent)¹³. The tools everyone uses are exactly the ones most likely to live in the cloud.

If your user count barely grows or your contract is a flat fee, this test does not apply. Check your user forecast against your hiring plan.

3. How slowly the data and features change

The third test is how often the system changes. It is easy to get this one wrong, so let me go back to the source.

Gartner's pace-layered model, published in 2012, sorts a company's applications by how fast they change. For the slowest layer, systems of record, the original release describes "established packaged applications or legacy homegrown systems that support core transaction processing and manage the organization's critical master data," adding that "the rate of change is low, because the processes are well-established and common to most organizations, and often are subject to regulatory requirements"¹⁴. In other words, the source says slow-changing systems are usually best kept as standard packages. If you simply say "it changes slowly, so we can build it," you are saying the opposite of what the model says.

I still include this test because it becomes useful when paired with a second axis, which is test four: legal and accounting complexity. What you want is work that changes slowly and is also simple. Internal registers, FAQs, intranet portals, request intake, and quote logs tend to keep the same fields and steps for years once they are set up. For that kind of work, much of your SaaS fee is paying for the development of features you will never use.

The same Gartner release notes that "the same application may be classified differently in one company than in another"¹⁴. What is just a register at one company may be a source of advantage at another. Part two of this series, Which business systems can you build yourself?, goes deeper into picking candidates using data update frequency, which is TIMEWELL's own lens. I looked for a public or analyst framework that splits build versus buy by data update frequency and did not find one, so please read it as our view.

4. Legal and accounting complexity

Even if it looks slow-moving, work governed by law gets separate treatment. Accounting, payroll, tax filing, and time tracking all have to follow tax reforms and changes in accounting standards.

A concrete example from Japan: under the 2024 flat-rate income tax cut, relief for salaried employees was, as a rule, deducted from the tax withheld from salaries paid on or after June 1, 2024, with any amount not fully deducted in June carried over to later pay in the same year¹⁵. A company running its own payroll system would have had a few months after the tax reform to build and test that logic, and then confirm it again at the year-end adjustment. Your SaaS fee includes the cost of keeping up with changes like that.

AI can speed up the writing of code, but someone still has to read the reform, interpret it correctly, and find the exceptions. And when you get it wrong, it shows up directly in employees' pay and tax filings. I think this kind of work should stay on SaaS or packaged software.

The rule of thumb I use is simple: who sets the rules for this work, your company or the law? Your company decides the approval route for internal requests. The law decides how withholding tax is calculated. The first can be a candidate. The second, as a rule, should be taken off the list.

What comes off the list, though, is only the record of truth and the legally required processing. Even within accounting or HR software, the request screens and rollups that every employee touches are decided by your company. Build those yourself and pass the data to the SaaS through its API, and you may be able to cut SaaS seats down to the accounting and HR staff. That goes straight at test 2, per-seat pricing. How to draw the line, and which contract clause to check first, are covered in the second article in this series, Which Business Systems Can You Build Yourself?

5. How many other systems it connects to

The fifth test is integrations. This is my own view rather than anything in public guidance, but I find that connections to other systems drive the maintenance burden more than anything else.

Most SaaS products ship with connectors for single sign-on, accounting, HR master data, chat, email, and BI, and the vendor takes care of keeping up when those other systems change their specs. Build it yourself and all of that becomes your job. Every new integration is one more place where things can break.

Counting is simple. List every system that sends data into the SaaS and every system that receives data from it. If the list is long and many of the links sync both ways, most of the cost of rebuilding will go into building and maintaining integrations, not screens. If employees type into a screen and the only output is a CSV sent once a month, the job gets much easier.

Think back to Klarna. The reason it could walk away was that it consolidated its data first⁴. If you want to cancel a heavily integrated SaaS, you need a design that brings your data together first. Part five, Running business apps in your own cloud tenant, covers that design.

6. Who will maintain it once it is built

Of the seven, this is the one I weigh most heavily. Building something is easier than deciding who will keep fixing it afterward.

The Japanese numbers are sobering. In the IPA survey mentioned above, 82.3 percent of companies that are insourcing named hiring and developing people as a challenge, and 19.5 percent said moving externally built systems in-house was difficult⁸. In IPA's 2026 edition, 85.5 percent of companies said they were somewhat or seriously short of people to drive digital transformation¹⁶.

Overseas, maintenance is also the problem left standing at the end. Fred Turner, CEO of the US health insurer Curative, reportedly said he cancelled a CRM contract worth 600,000 dollars a year, built an in-house CRM in two months, and called maintenance "definitely one of the hardest challenges"¹⁷. You could argue that as building gets faster, the weight of maintenance becomes more visible.

I ask three questions under this test. Can you name one person who will fix the system? Can you protect a stated number of that person's hours each week? When a change or an outage is more than they can handle alone, is there a partner they can call? If you cannot answer all three, it is too early to cancel.

By partner I do not mean an outside contractor who builds it for you and hands it over. I mean someone who works alongside your staff until they can make changes themselves. METI's DX Report 2 makes a similar point: for technologies internal staff cannot pick up right away, it expects growing demand for vendors that help companies move to in-house development and transfer skills while working alongside them⁶.

7. Cancellation and migration terms

The last test is the contract. Even when everything else lines up, getting the cancellation steps or the timing wrong can mean paying twice for longer than planned, or losing data.

Switching is hard, and the numbers show it. In the Japan Fair Trade Commission's 2022 study of the cloud market, only 15.7 percent of businesses (86 of 548) had switched cloud providers in the previous ten years. Among those who gave a clear answer, only about 14.1 percent said they would switch if their current service raised prices by 5 to 10 percent¹⁸. That question mainly covered IaaS and PaaS users, but the pattern is clear: once you are on a cloud service, it is hard to leave.

For what to check, a good starting point is the list IPA gives for the end of a contract in its cloud safety guide for small and midsize businesses (June 2026 edition): return or download of all data, compatibility and portability of that data, complete deletion of what remains, and a guarantee that no other customer can reuse it¹⁹. DS-310 likewise tells agencies to avoid vendor lock-in by choosing services where data portability is assured and pricing is published and reasonable⁷.

In the contract itself, always check three things: the auto-renewal terms and the notice deadline; how pricing works if you cut seats and keep part of the subscription; and how many days after termination you can still get your data out. In the master agreement of one large overseas SaaS vendor that we reviewed (September 2026 version), unless an order form says otherwise, subscriptions renew for another year unless notice is given at least 30 days before the term ends; a renewal with reduced volume or term is re-priced without regard to the prior per-unit price; and the vendor has no obligation to keep your data if you do not request it within 30 days after termination. Keeping part of a subscription does not necessarily make it cheaper. Part four, How to cancel a SaaS and migrate off it, lays out a schedule that works backward from the renewal date.

How to use the seven tests

If you give all seven tests equal weight and add them up, you will make bad calls. I use them in this order.

First, tests four and six act as gates. Work that is tightly bound by law or accounting rules comes off the list no matter how strongly the other tests point toward cancelling. So does any work where you cannot name the person who will maintain it. These two matter most because failures here are costly and only surface after you have built the thing.

For what passes the gates, tests one and two tell you the money. How much will you pay over five years, and how much of that is per-seat growth? If the gap against the cost of building is small, there is no reason to cancel. Only services with a large gap move on.

Then tests three and five tell you the difficulty. The slower the changes and the fewer the integrations, the easier the rebuild and the lighter the maintenance afterward. Finally, test seven sets the timing. Even a strong candidate should wait if the notice deadline is three months away. It is safer to let that renewal go through and prepare for the next one.

And pick one candidate. Try to cancel several SaaS products at once and the migration work piles up, with the burden landing on frontline staff during parallel running. Learn the steps on the first one, confirm that maintenance actually works, then move to the second.

The other four articles in the series follow that order.

Order	Article	What it covers
1	Which business systems can you build yourself?	Picking candidate work, based on tests 3 and 4
2	Five-year SaaS TCO	Comparing total cost of building versus staying, based on tests 1 and 2
3	How to cancel a SaaS and migrate off it	Notice deadlines, data export, and parallel running, based on test 7
4	Running business apps in your own cloud tenant	Permissions, data location, and the maintenance setup, based on tests 5 and 6

Cancelling SaaS and building in-house with an FDE

Now for what we do. TIMEWELL works as an FDE (Forward Deployed Engineer) team and takes companies from this decision through the rebuild, the migration, and to the point where their own staff can run the system. An FDE is an engineer who goes into the customer's workplace and builds and deploys alongside the people who do the work. I explain the role in detail in What is an FDE.

What our FDE team does

We start by taking stock of the SaaS you use today and narrowing it down to one candidate with the seven tests. We list annual fees, billing units, user trends, integrations, renewal dates, and notice deadlines. If something fails a gate, we tell you plainly that it should stay.

Once a candidate is chosen, we show you a working prototype within the first week, running on your real data with personal information masked. We do not wait for a finished spec. Your staff try it, tell us where it differs from how they actually work, and we fix it the next day. After a few rounds you start to see which features of the SaaS people really use and which they never touch.

From there we set the parallel-running period, move the data, and work back from the renewal date to decide when to send the cancellation notice. We time-box the engagement at 45 to 90 days from the start, and we define the end condition up front: your own staff can make changes themselves.

We also make one commitment about AI. We only choose cloud services and AI models that do not use customer data for training. Where processing happens is designed case by case, weighing requirements against cost. On information security, TIMEWELL holds ISO/IEC 27001 certification (scope: planning, development, and provision of SaaS products using AI technology).

You can find more on how we work on our FDE service page.

How this differs from contract development

What happens if you cancel a SaaS and have a contractor rebuild it? Only the contractor knows how the new system works, and every change means a new quote and a new order. You escape SaaS lock-in only to walk into a maintenance contract that locks you in just as tightly. That is the outcome to avoid.

Our FDE work is structured differently in three ways. The first is what engineering hours mean. In contract development, hours are revenue, so staying longer pays. We treat FDE hours as an investment and want the hours per customer to go down over time. The second is where the learning goes. Patterns that other companies can use go back into our products as standard features, which makes the next project faster and cheaper. Procedures and vocabulary unique to your company stay yours. The third is how it ends. We do not leave at sign-off. We leave once your staff can make changes themselves. In other words, growing the "person who maintains it" from test six is part of the job.

Where this works for us, and where it does not

To be honest, this approach does not fit every company or every kind of work.

If you ask us about cancelling SaaS for accounting, payroll, or tax filing, we will not recommend rebuilding. As test four shows, once you count the cost of keeping up with legal changes, SaaS is cheaper and safer. The same goes for the core of an ERP, with its high transaction volumes and many connections.

We will not take the work if you cannot put a maintenance owner in place. We plan to leave once your team can run things, so building without an owner just leaves behind a system nobody can fix. In that case we suggest delaying the start until you can assign someone, or staying on the SaaS.

Low-cost SaaS rarely qualifies, because the cost of building plus the people to maintain it tends to exceed what cancelling saves. If the notice deadline is close, we suggest starting with preparation for the next renewal.

Here is where we drew the line ourselves. We built and run our own employee portal (daily reports, goal tracking, internal training, and so on), but we still use an outside cloud accounting service. The reasons are exactly tests four and six.

Finally, capacity. We are a small company, and our leadership team goes into customer sites directly. There is a limit to how many projects we can run at once, and I would rather say so than hide it.

Summary

• SaaS bills look bloated because of two forces at once, price increases and a weaker yen, and in Japan the top expected benefit of insourcing is now lower development cost
• Public guidance still favors SaaS by default, and the speed of AI-assisted development comes with caveats on stability and security
• DS-310 itself describes the exception: expensive SaaS that grows with per-seat billing, or functions a managed service could deliver, should be compared on lifecycle cost
• Use seven tests. Gate on legal and accounting complexity (4) and maintenance ownership (6), then look at money (1, 2), difficulty (3, 5), and timing (7)
• Pick one candidate, and consolidate your data before you build screens

What I take from Klarna is that whether you can leave SaaS is not decided by how smart the AI is. It is decided by whether you can hold your data and your maintenance in your own hands. Cancelling is just what follows.

If you want to start by taking stock of which of your current SaaS products pass these seven tests, take a look at our FDE service page or book an FDE consultation. In the next article, I will look at how to tell which work is a good candidate, using data update frequency as the lens.

Footnotes

1. A major overseas software vendor to raise prices of enterprise software and cloud services from April 2024 (@IT, December 11, 2023, in Japanese). The 20 percent increase from April 1, 2024 and the twice-yearly price review are described in this article ↩

2. Time-Series Data Search (Bank of Japan). Series FXERM07 in database FM08 (Tokyo market, USD/JPY spot at 17:00, monthly average), averaged by calendar year by the author. The 2026 figure is the January to August average ↩

3. Corporate IT Trends Survey Report 2026 (Japan Users Association of Information Systems, in Japanese). Reasons for IT budget increases are in Figure 2-1-3; expected benefits of insourcing are in Figure 7-2-6 (n=863). Fiscal 2025 survey of 4,500 listed and comparable companies, 957 responses ↩ ↩²

4. Post by Sebastian Siemiatkowski on X (March 4, 2025). The internal estimate of about 1,200 SaaS shut down, and the statement that Klarna did not replace SaaS with an LLM, are from this post ↩ ↩²

5. Report on the Klarna CEO doubting that other companies will replace a major CRM with AI (TechCrunch, March 4, 2025). The internal tech stack using Neo4j and the doubt that other companies will follow are quoted in this article ↩

6. DX Report 2, interim report (METI Study Group on Accelerating Digital Transformation, December 28, 2020, in Japanese). Use of SaaS and packages in non-differentiating areas is on p. 22; support for moving to in-house development and transferring skills while working alongside is on pp. 24-25. Translations by the author ↩ ↩²

7. DS-310: Basic Policy on the Appropriate Use of Cloud Services in Government Information Systems (Digital Agency, May 27, 2025, in Japanese). SaaS as a first option and the warning on per-account and expensive SaaS are on PDF page 16; avoiding vendor lock-in is section 3.3; the lifecycle-cost comparison is on pp. 33-34. Translations by the author ↩ ↩² ↩³ ↩⁴

8. DX Trends 2025 (Information-technology Promotion Agency, Japan, June 26, 2025, in Japanese). Sourcing methods in Figure 2-13 (non-core areas, Japan n=1,475); insourcing status in Figure 2-14 (Japan n=1,500, US n=509); insourcing challenges in Figure 2-16 (companies insourcing, n=334). Fiscal 2024 survey ↩ ↩²

9. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (METR, July 10, 2025) ↩

10. We are Changing our Developer Productivity Experiment Design (METR, February 24, 2026). Estimate for developers returning from the earlier study. The authors note that selection effects may obscure the true speedup ↩

11. State of AI-assisted Software Development 2025 (DORA). Published September 2025, based on responses from nearly 5,000 technology professionals ↩

12. 2025 GenAI Code Security Report (Veracode, July 30, 2025). A study by a company that sells security products ↩

13. Results of the 2025 Communications Usage Trend Survey (Ministry of Internal Affairs and Communications, May 29, 2026, in Japanese). Business survey, Figures 4-1 and 4-3. Covers companies with 100 or more regular employees ↩

14. Gartner Says Adopting a Pace-Layered Application Strategy Can Accelerate Innovation (Gartner, February 14, 2012, reprinted by MarketScreener) ↩ ↩²

15. The 2024 flat-rate income tax cut, for salaried employees (National Tax Agency, in Japanese) ↩

16. DX Trends 2026 (Information-technology Promotion Agency, Japan, July 30, 2026, in Japanese). Shortage of DX talent in quantity, section 4.2, Figure 4-1. Fiscal 2025 survey ↩

17. Report that Curative built its own CRM in two months and cancelled a 600,000-dollar-a-year contract with a major CRM vendor (Business Insider Japan, August 15, 2026, in Japanese). The remarks are attributed to the podcast "20VC with Harry Stebbings." The author has not reviewed the original audio ↩

18. Report on the Cloud Services Market (Japan Fair Trade Commission, June 28, 2022, in Japanese). Main report pp. 49-50, Figure 3-6. The switching questions were answered mainly by 548 IaaS and PaaS users ↩

19. Guide to the Safe Use of Cloud Services for Small and Midsize Businesses (Information-technology Promotion Agency, Japan, June 2026, in Japanese). Item 13, "Secure your data at the end of use" ↩