Which Business Systems Can You Build Yourself? Sort Them by How Often the Data Changes

Hello, this is Ryuta Hamamoto from TIMEWELL.

This is the second article in a five-part series on canceling expensive SaaS subscriptions and rebuilding the functions yourself. The first one, on how to decide whether to leave a SaaS product, laid out what to check before canceling. This one answers the question that comes before it. Your company pays for dozens of SaaS tools. Which of them should you even consider rebuilding?

My answer is simple: start with the ones whose data rarely changes. Contract ledgers, internal FAQs, intranet portals, equipment and purchase requests, quote registers. The shape of the data in these systems almost never changes, and only a handful of records get written each day. Now that generative AI has cut the effort of building software, I think you can build and own these without much trouble.

There is a catch, though. The best-known framework for sorting business systems by how fast they change is Gartner's pace-layered model, and if you read it plainly, it says slow-changing core systems belong on standard packages. Say "it changes slowly, so we can build it" and you are saying the opposite of the source. So in this article I add a second axis to the speed of change: weight, meaning complexity, transaction volume, and regulatory burden. Slow and light systems such as ledgers and FAQs become build candidates. Slow but heavy ones such as accounting and payroll stay on SaaS. There is a quick-reference table by business function further down.

One disclaimer up front. I looked for a public framework that uses data update frequency to decide between building and buying, and I did not find one. The two-axis view is our own. It is also the order in which we pick candidates when we go on site as forward deployed engineers.

Systems of record, engagement, insight, and pace layers

The vocabulary for sorting business systems comes from three places.

The oldest is Geoffrey Moore's 2011 white paper, which introduced systems of record and systems of engagement. Moore described systems of record as the tools, repositories, and systems that organizations have built their business processes on for decades. Systems of engagement overlay and complement that deep investment, adding web access, usability across hardware and software platforms, and collaboration across organizations¹. A simple way to hold it: the system of record keeps accounting and order data correct, and the system of engagement is where employees and customers interact.

In 2015, Brian Hopkins of Forrester added systems of insight, defined as the business discipline and technology to harness insights and consistently turn data into effective action². Think of it as the layer that turns what piles up in the system of record, and what happens in the system of engagement, into decisions.

The pace-layered model cuts the problem differently. Gartner announced it in February 2012, and it sorts applications into three layers by how fast they change³. Systems of record are established packaged applications or legacy homegrown systems that support core transaction processing and manage the organization's critical master data. Their rate of change is low, Gartner says, because the processes are well established and common to most organizations, and often subject to regulatory requirements. Systems of differentiation support processes unique to the company or specific to an industry; they have a medium life cycle of one to three years but need frequent reconfiguration as business practices and customer requirements change. Systems of innovation are built ad hoc for new requirements or opportunities and typically last from zero to twelve months.

Moore's system of record and Gartner's system of record share a name but not an axis. Moore splits by role, recording versus engaging. Gartner splits by speed. Search for the difference between the two and you will often find them blended together. For build-or-buy decisions, Gartner's speed axis is the one that does the work.

The terms are well established in Japan too. Material presented by the Ministry of Economy, Trade and Industry at the first meeting of its legacy system modernization committee in September 2024 notes that data in core systems of record can also feed front-end systems of engagement and analytical systems of insight, and that front-end services increasingly run on SaaS as cloud adoption spreads⁴. Japan's national IT Passport exam lists both terms in its syllabus⁵.

Read plainly, the source says to buy what changes slowly

This is where my starting point runs into trouble. Gartner defines systems of record as established packages or legacy homegrown systems, and it calls for a secure and cost-effective environment to support core business processes³. Follow that logic, and slow systems that are common to most organizations are best held on standard packages, where many companies split the development cost. "The data rarely changes, so we can build it" points the other way.

Japanese public guidance leans the same direction. METI's DX Report 2 from December 2020 told companies to abandon the build-everything-yourself mindset in non-differentiating areas, standardize their processes, and use SaaS and packaged software⁶. The Digital Agency's cloud policy for government systems, DS-310, revised in May 2025, says SaaS should be considered broadly and with priority to reduce development, and even includes a heading about thoroughly adopting a "don't build" approach⁷. The modernization committee material also stresses Fit to Standard, which means moving onto new systems or SaaS and adjusting the work to fit⁴.

Company behavior matches. In IPA's DX Trends 2025 survey, Japanese companies sourcing their non-core, non-differentiating areas reported packaged software at 33.8%, SaaS at 24.4%, and in-house development at only 16.6%. On the same question, US companies reported in-house development at 40.1% and SaaS at 11%⁸. Japanese firms have covered the edges of their business with SaaS and packages.

So where is the room to say "start building from the slow ones"? The clue is inside DS-310 itself. It recommends SaaS strongly, then adds that the recommendation is not unconditional. When the number of users is expected to grow in steps, SaaS fees can become expensive in operation, so you need to check carefully whether the savings are real over the life cycle. If a managed service can deliver the same function, compare both approaches. And be especially careful with SaaS priced per account and with high-cost SaaS⁷. The same document also asks agencies to use generative AI in development.

The government's own guidance puts the reasons to choose SaaS and the conditions for not choosing it side by side. I think the way to tell the two apart is hidden in that exception.

Add a second axis: weight

Go back to Gartner's reasons why systems of record change slowly. There are two. The processes are common to most organizations. And they are often subject to regulation. Both are reasons to buy a package, but they are very different reasons.

"Buy because it is common" is about splitting development cost. One vendor building once and selling to a hundred companies beats a hundred companies building the same thing. That logic is strongest when building is expensive. As generative AI lowers the effort of building, the savings from sharing shrink for simple systems, and the monthly per-seat fee you keep paying starts to stand out.

"Buy because it is regulated" is about splitting the cost of keeping up with the law. Generative AI barely touches this. Someone has to read the amendment, turn it into a calculation spec, finish testing before the deadline, and take responsibility when it goes wrong. None of that depends on how fast you write code.

So I add a weight axis to the speed axis. I measure speed as data update frequency, split in two: how many records get written per day, and how many times a year you want to change fields, screens, or rules. I measure weight in three ways: the complexity of calculations and exceptions; transaction volume, meaning record counts, concurrent users, and what stops when the system stops; and regulation, meaning how often outside rules force changes and who is liable for errors.

	Light (simple, low volume, little regulation)	Heavy (complex, high volume, heavily regulated)
Changes slowly	1. Build candidates (ledgers, internal FAQs, intranet portals, requests, quote registers)	2. Stay on SaaS or packages (accounting, payroll, master data that core systems read)
Changes quickly	3. Build, then throw away when done (prototypes, one-off reports, campaigns)	4. Staff it properly and decide deliberately (customer-facing services, core CRM, production planning)

Mapped onto Gartner's layers, group 2 is the classic system of record, group 3 is roughly systems of innovation, and group 4 is roughly systems of differentiation. Group 1 would count as a system of record in the original, but only one of the two reasons for buying a package, "it is common," still applies. Our view is that this is where the economics flip first as generative AI makes building cheaper.

The research does not contradict this split. A 2023 experiment found that developers using GitHub Copilot finished implementing an HTTP server in JavaScript 55.8% faster, and that was a small, well-specified task⁹. METR's 2025 randomized controlled trial went the other way. Sixteen experienced developers working in large open-source repositories they had contributed to for years, averaging more than 22,000 stars and a million lines of code, took 19% longer when they were allowed to use AI. They had expected a 24% speedup beforehand, and afterward still believed they had been sped up by 20%¹⁰. In February 2026, METR estimated that late-2025 tools cut task time by 18%, but the confidence interval ran from minus 38% to plus 9%, crossing zero, and METR itself noted that selection effects obscure the true effect¹¹. Google's 2025 DORA report found AI adoption positively associated with software delivery throughput and negatively associated with delivery stability, and summed it up this way: AI does not fix a team, it amplifies what is already there¹².

My reading: on small, simple work, AI makes you faster; on large, tangled work, neither speed nor stability is guaranteed. That is why group 1 is the easy place to build, and why groups 2 and 4 call for caution.

In an earlier piece on how far to insource AI, I wrote that the things you change most often belong inside. That may sound like the opposite of this article, but the question is different. That piece was about who owns the tuning, such as prompts and review steps, and the argument was that ordering every tweak from an outside vendor stalls improvement. This one is about whether to keep paying a monthly fee or build once and own it. A slow-changing system gets touched rarely after launch, so even if outside help builds it, the burden of owning it stays small. Put the two together and you get a clean split: keep fast-moving tuning in house, and build the slow-moving containers cheaply and own them.

A quick reference by business function

Here is how it plays out function by function. The table is our rule of thumb for a typical company.

Function	Speed of change	Weight	Verdict	What decides it
Internal FAQ and knowledge base	Slow. A few new articles a week, fields fixed	Light	1. Build candidate	Whether visibility has to differ by department
Intranet portal (notices, policies, links)	Slow	Light	1. Build candidate	Whether it duplicates your existing groupware
Ledgers for contracts, equipment, certifications	Slow	Light	1. Build candidate	Whether it will store the electronic contracts themselves
Approval requests for purchases and sign-offs	Slow. Routes reviewed a few times a year	Light to medium	1. Build candidate	How many exception routes exist, and whether it posts entries to accounting
Quote register (numbers, history, link to deals)	Slow	Light	1. Build candidate	Whether the quote calculation itself is a competitive edge
Expense reimbursement	Monthly, everyone	Heavy (invoice rules, electronic record retention)	2. Stay on SaaS	You can still build your own entry screen
Time and attendance	Daily, everyone	Heavy (used daily by all, feeds payroll)	2. Stay on SaaS	You can still build your own clock-in screen
Accounting	Structure is slow, but entries are daily	Heavy (tax, invoice rules)	2. Stay on SaaS	Feed journal data in from surrounding ledgers
Payroll	Monthly, with rules changing almost every year	Heavy (tax amendments, year-end adjustment)	2. Stay on SaaS	None
Master data for items and business partners	Slow	Heavy (core systems read it)	2. Keep in the core system	Your own ledgers only read the master copy
Analytics dashboards and prototypes	Fast	Light	3. Build and discard	Whether there is a rule to delete them when done
Core CRM	Fast	Medium to heavy (whole sales team, many integrations)	4. Staff it and decide	Whether you can carve off just the surrounding ledgers

Everything in group 1 is already commonly bought as SaaS. In Japan's 2025 Communications Usage Trend Survey from the Ministry of Internal Affairs and Communications, 61.4% of companies using cloud services said they use them for internal information sharing and portals, second only to file storage and sharing at 73.3%. Payroll, financial accounting, and HR came in at 56.3%¹³. The first is a large pool of rebuild candidates. The second is where I would keep paying.

Accounting and payroll sit in group 2 because of how often the law changes. In Japan, the qualified invoice system started on October 1, 2023¹⁴. From June 2024, a flat income tax cut ran through payroll withholding, and employers had to reflect it in their withholding calculations¹⁵. The year-end adjustment in December 2025 had to handle the revised basic deduction and employment income deduction under the fiscal 2025 tax reform¹⁶. That is at least three deadline-driven changes in about two years. Accounting and payroll SaaS vendors absorb this work once for all their customers. Own the system, and you need your own people to read each amendment, turn it into a spec, and test it before the deadline. AI shortens only the implementation part. Reading the rules and carrying the responsibility do not get shorter.

Treat the verdicts as a starting point. Gartner itself says the same application may be classified differently in one company than in another, depending on its use and its relationship to the business model, and that applications move between layers as they mature³. Quotes make a good example. A register that only tracks quote numbers and history is group 1. For a manufacturer that builds up costs from drawings and processes, the quote calculation is the competitive edge, and it belongs in group 4. Same word, different layer.

Accounting and HR do not have to live entirely in SaaS

The quick reference puts accounting, payroll, and attendance in group 2, "keep the SaaS." More precisely, what stays in SaaS is the system of record and the legally required processing. Accounting and HR products bundle two kinds of work: the parts the law decides and the parts your company decides. Only the second kind is a candidate for building yourself.

Function	Keep in SaaS (or with outside professionals)	Reasonable to build yourself
Accounting	Journal entries as the record of truth, closing, tax filing, storage of electronic transaction data	The front end for expense requests, budget tracking, management-accounting rollups and screens
HR and payroll	Payroll calculation, social and employment insurance filings, year-end tax adjustment, handling of My Number (Japan's national ID)	Evaluations, goals, training, onboarding guides, internal request screens
Quotes and invoicing	Issuing invoices, matching payments, storing transaction documents	How quotes are calculated, price tables, the register that links quotes to deals

In practice, you build the screens every employee touches and pass the data to the accounting or HR SaaS through its API. Only the accounting and HR staff open the SaaS itself, so you may no longer need seats for everyone else. The more a SaaS charges per account, with the bill growing alongside headcount, the bigger the effect. In Moore's terms, you leave the system of record alone and layer your own system of engagement on top of it¹.

Quotes suit this pattern especially well. In Japan, the qualified invoice requirements apply to invoices and similar documents¹⁴, while quotes mainly face storage requirements when they are exchanged electronically¹⁷. And every company prices differently, from how it sets unit prices to how it thinks about discounts. As the previous section noted, for a manufacturer the calculation itself is a competitive edge. Keep invoicing and payment matching in SaaS, and own the part that produces the quote. In my view, that is the realistic split.

One caution. Some SaaS and packaged-software contracts charge for indirect use, where people without a license use the product through an API or an integration (often called indirect access or multiplexing). Before you move screens in-house to cut seats, check your contract for such a clause. If it is there, it changes how many seats you can actually drop.

We run our own internal portal this way: it reads data from our accounting SaaS through the API and displays it, while the journal entries themselves stay in the accounting SaaS.

When "light" is actually heavy

Before building something that looks like group 1, I check five things. Each is a way that weight hides behind a simple-looking system.

First, will it store electronic documents themselves? According to Japan's National Tax Agency, when you send or receive electronic data equivalent to documents you would have to keep on paper, including purchase orders, contracts, quotes, and invoices, you are required to keep that data electronically. The baseline rules are measures against tampering, a display or printer for viewing, and the ability to search by date, amount, and counterparty¹⁷. A contract ledger that only tracks which contract expires when stays light. If it also becomes the storage place for electronic contracts, it needs a history of corrections and deletions. That is buildable. But deciding it at the start, rather than later, changes the amount of rework dramatically.

Second, is it the master copy? In Gartner's definition, managing critical master data is the job of the system of record³. Move item, partner, or chart-of-accounts masters that accounting and ordering depend on into your own ledger, and what you thought was group 1 turns into group 2. It is safer to let your own ledger only read the master copy and leave writes to the core system.

Third, how fine-grained are the permissions, and will outsiders use it? In an experiment presented at ACM CCS 2023, a major security conference, participants with access to an AI assistant wrote less secure code than those without, and were more likely to believe their code was secure¹⁸. That was with a model from that time. Still, I do not think login, permissions, and audit logging are things to have AI write from scratch each time. They belong on a shared foundation that has already been tested. If the system opens to outsiders, like a portal for business partners, move it up one notch on the weight axis.

Fourth, what stops when it goes down? If the internal FAQ is down for half a day, work goes on. If the ledger you use to issue shipping instructions goes down, shipping stops. A system with few writes can still be heavy if an outage stops the business.

Fifth, who will own it? In the same IPA survey, 82.3% of Japanese companies pursuing insourcing named difficulty hiring and developing people as a challenge, the top answer⁸. Building may be cheaper now, but if nobody adds fields, answers user questions, and ships the few changes a year, you have just added one more orphaned app. DORA's point that AI amplifies what is already there cuts both ways. In an organization with no owner, it amplifies the lack of one.

Whatever passes these five checks gets ranked. Here is the inventory process we recommend.

1. Add five columns to your list of SaaS tools: records written per day, number of field or rule changes in the past year, related regulations, number of connected systems, and user count with pricing model
2. Place each tool in group 1, 2, 3, or 4 by speed and weight
3. Within group 1, start with tools priced per account whose cost climbs as users grow (DS-310 singles out this type⁷)
4. Confirm you can export the data, and in what format and how (the practicalities of canceling and migrating SaaS)
5. Compare five-year totals for building and owning versus continuing to pay (estimating a five-year SaaS total cost)
6. Decide where it will run (designing business apps on your own cloud tenant)

The five columns in step 1 are limited to things you can fill in from invoices, each tool's admin console, and a short conversation with the people who use it. If you are down to one or two candidates by step 3, that is a good result.

How this differs from contract development

Once you decide to build a group 1 system, who you hire changes the outcome.

A typical contract developer builds each company's ledger or FAQ from scratch and bills for the hours. But group 1 systems look alike across companies. Login and permissions, change history, search, approval steps. What differs is mostly field names and approval routes. Rebuild the skeleton every time, and every customer pays for it every time.

Our FDE team keeps that skeleton as shared machinery in the product and places only the fields and approval routes that differ as that company's configuration. Patterns we find on site go back into the product, so the next company gets its system faster and cheaper. That is why, for us, time on site is investment rather than revenue, and hours per customer should keep falling. The ending is different too. The work does not end at acceptance testing. It ends when your people can add fields and change approval routes on their own. The job is done when you no longer need us.

I think this is close to the relationship METI anticipated in DX Report 2. The report said that as user companies move to in-house development, their own staff often cannot handle it right away, so demand will grow for vendors who support the transition and transfer skills while working alongside them. It argued this should not become an on-site staffing business but a partnership that grows the team together and builds together⁶. Rebuilding a group 1 system is a good size for trying that relationship on a small scale.

What our FDE team does

Our forward deployed engineers go into the customer's workplace and turn problems into working software. Here is what we take on when rebuilding SaaS functions.

We start by sitting in on the inventory. We go through your SaaS list and invoices together, fill in the five columns, and place each tool in a group. This is also where we make clear what should not be built. Anything in group 2 comes off the rebuild list.

Next, we pick one system from group 1, and on day one we show you a working prototype running on your real data with personal information masked. We do not replace several systems at once. The engagement runs 45 to 90 days, and we agree on the exit conditions up front, for example that your staff can add fields and change approval routes themselves. Fees are set by the period, not by adding up hours.

By default the system runs in the customer's own cloud environment. The processing region is a design choice we make to match your requirements. We only use AI models and services that do not train on customer data. TIMEWELL holds ISO/IEC 27001 certification (scope: planning, development, and provision of SaaS products using AI technology).

We also plan the cancellation with you: the notice deadline counted back from the renewal date, a trial data export, and the parallel-run period. The fourth article in this series, on canceling and migrating, is the procedure we use. The full approach is on our FDE service page.

What we practice, and where we stop

We draw the same line inside our own company. We built and run our own employee portal, and it holds the contract ledger with renewal tracking, the asset ledger for PCs and equipment, a register of the SaaS tools we use, purchase and sign-off requests with approvals, travel requests, company policies, security training, weekly goals, and daily reports. It is almost exactly the group 1 list from the table. Accounting, HR and payroll administration, and issuing quotes stay on cloud SaaS. The asset ledger is ours, but the fixed asset register for accounting lives in the SaaS, and our ledger only keeps its reference number. That is the second check above, applied to ourselves: read the master copy, do not own it.

Attendance is a slightly different case. The clock-in screen lives in our own portal, while the attendance records and audit trail stay in the SaaS. It is exactly what Moore described, a system of engagement laid over a system of record. We keep quote issuance in the SaaS because it runs straight through to invoicing and payment and falls under the invoice rules. The part we own is the register that links quotes to deals.

Not everything went well. We built a daily report form into the portal, and right after launch it was barely used. We later added drafts assembled from the previous day's schedule and records, plus an afternoon reminder. Building got cheaper. Designing something people actually use did not. If you build your own, budget for that.

Here is what we decline. We do not take on projects that move the records of accounting, payroll, or attendance off SaaS into a custom build. Those are group 2, and it would leave the customer carrying the job of keeping up with the law. The same goes for moving master data that core systems read. If nobody inside the company is named to own the system after we leave, we do not start. Systems used by many outsiders, such as business partners, get treated as heavy even if they look like group 1, and we discuss the timeline and team separately.

The two-axis view has limits of its own. I found no public guideline or analyst framework that decides build versus buy by data update frequency, so this is our view and nothing more. The table is a rule of thumb for a typical company. And we are a small company, so the number of sites we can work in at the same time is limited.

Summary

• Systems of record and engagement split by role (Moore, 2011). Pace layers split by speed (Gartner, 2012). The axes are different
• Read plainly, both Gartner and Japanese public guidance put slow-changing core systems on packages or SaaS. "It changes slowly, so we can build it" contradicts the source on its own
• Gartner gives two reasons systems of record change slowly: they are common, and they are regulated. As reasons to buy a package, generative AI weakens only the first
• So add weight (complexity, volume, regulation) to speed. Slow, light systems, meaning ledgers, FAQs, intranet portals, requests, and quote registers, are the build candidates
• Accounting and payroll are slow but heavy. Deadline-driven amendments kept coming from 2023 to 2025, and staying on SaaS makes more sense
• What stays in SaaS is only the record of truth and the legally required processing. You can build the screens everyone uses and cut SaaS seats down to the specialists (check your contract for indirect-access clauses first)
• Before building, check document retention, whether it is the master copy, permissions and outside users, outage impact, and ownership

Build or buy is not a question you settle for every system at once. Add five columns to your SaaS list, find one tool that lands in group 1, and check whether it is really as light as it looks. Start there, and if it fails, it fails small.

If you want help finding your group 1 candidates, or want to rebuild in a way your team can keep running on its own, take a look at our FDE service page or book an FDE consultation. In the next article, I put numbers on it and compare five-year totals for continuing to pay versus building and owning.

Footnotes

1. New Geoffrey Moore White Paper on Future of Enterprise IT (AIIM, January 19, 2011). Descriptions of systems of record and engagement from the white paper "Systems of Engagement and the Future of Enterprise IT" ↩ ↩²

2. All your big data will mean nothing without systems of insight (Brian Hopkins, Computerworld, September 21, 2015) ↩

3. Gartner Says Adopting a Pace-Layered Application Strategy Can Accelerate Innovation (Gartner, February 14, 2012; press release as republished on MarketScreener). The three layer definitions, the reasons systems of record change slowly, the call for a secure and cost-effective environment for core processes, and the point that the same application may be classified differently by different companies all come from this release ↩ ↩² ↩³ ↩⁴

4. About the Legacy System Modernization Committee (METI Information Industry Division, material 3 for the first committee meeting, September 12, 2024, in Japanese). The SoR, SoE, and SoI slide is page 14; Fit to Standard is page 13 ↩ ↩²

5. IT Passport Examination Syllabus Ver. 6.5 (IPA, in Japanese). SoR and SoE appear as example terms under strategic goals ↩

6. DX Report 2, interim summary (METI, December 28, 2020, in Japanese). Abandoning the build-it-yourself mindset in non-differentiating areas is on page 22; support for moving to in-house development and skill transfer is on pages 24 and 25 ↩ ↩²

7. DS-310: Basic Policy on Appropriate Use of Cloud Services in Government Information Systems (Digital Agency, decided May 27, 2025, in Japanese). The caution on per-account SaaS, the life-cycle cost comparison, and the "don't build" approach come from this document ↩ ↩² ↩³

8. DX Trends 2025 (IPA, June 26, 2025, in Japanese). Sourcing methods are in Figure 2-13 (Japan non-core areas n=1,475; US n=509); insourcing challenges are in Figure 2-16 (Japanese companies pursuing insourcing, n=334) ↩ ↩²

9. The Impact of AI on Developer Productivity: Evidence from GitHub Copilot (Peng, Kalliamvakou, Cihon, Demirer, arXiv, February 13, 2023) ↩

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

11. We are Changing our Developer Productivity Experiment Design (METR, February 24, 2026) ↩

12. Announcing the 2025 DORA Report (Google Cloud, September 24, 2025) ↩

13. 2025 Communications Usage Trend Survey report (Ministry of Internal Affairs and Communications, published May 29, 2026, in Japanese). Cloud services in use are in Figure 4-3 (n=2,133, multiple answers) ↩

14. About the qualified invoice system (National Tax Agency, in Japanese) ↩ ↩²

15. Flat-rate tax reduction for payroll (National Tax Agency, in Japanese) ↩

16. Revision of the basic deduction for income tax under the fiscal 2025 tax reform (National Tax Agency, in Japanese) ↩

17. How to store electronic transaction data from January 2024 under the Electronic Books Maintenance Act (National Tax Agency, November 2024, in Japanese) ↩ ↩²

18. Do Users Write More Insecure Code with AI Assistants? (Perry, Srivastava, Kumar, Boneh, ACM CCS 2023). The assistant in the experiment was based on OpenAI's codex-davinci-002 ↩