Core Systems: Should You Adopt a Package or Build From Scratch?

"Build It Around Our Business" Isn't Always the Right Answer

Whenever a company replaces its core system (the backbone of the business — sales management, inventory, accounting, HR, and so on), one question always comes up: do we adopt an off-the-shelf package, or build something custom from scratch just for us?

The instinct early on is to think, "Our operations are unique, so nothing will fit unless it's built specifically for us." But that very assumption is often the doorway to ballooning costs, slipping deadlines, and a system that ultimately goes unused.

This article lays out the order in which to make the decision. To put the conclusion first: there are several things you should check before you even start weighing "scratch vs. package." Let's go through them in sequence.

First — Consider the Option of Not Building at All

Developing a new system is the most expensive and time-consuming option on the table. Before you think about placing an order, take just one step back and ask whether a lighter approach could achieve the same goal.

When you weigh these, ask yourself three questions for each feature:

• How many minutes or hours per month does this task currently consume?
• How many millions of yen are you investing to cut that down?
• And fundamentally — will it actually deliver a benefit?

If you keep adding features based on a vague sense that "it'd be nice to have," costs will swell without limit. First, carve out the parts you don't need to build at all; then think about how to build the genuinely necessary parts that remain.

The Difference Between Package/SaaS and Full Scratch

Once you've decided to build, there are broadly three options. A clothing analogy makes it easy to grasp.

• Full scratch (made-to-measure): Tailored from the ground up to fit your body. Maximum flexibility, but expensive and slow.
• Package (off-the-rack): Buy a standard size and alter it slightly if needed.
• SaaS (rental): Rent it for a monthly fee. Always up to date, with low upfront cost.

Here's a point that's easy to overlook: packages and SaaS come with the industry's "standard processes (best practices)" built in from the start. Operating patterns refined across countless companies are baked into the software.

In other words, adopting a package means buying not just the software but also "the way successful companies do things."

"Fit Your Operations to the Standard" Beats "Fit the System to Your Operations"

Full scratch builds and excessive customization cost more — and not only because of the development fee itself. The more you tailor it, the more the future modifications, maintenance, and version upgrades become your burden alone.

At the same time, turning "the way we do things now" directly into a system can lock in inefficient procedures right along with everything else. Procedures that grew out of years of habit aren't necessarily the optimal ones.

This is where a different mindset helps: bring your own operations into line with the package's standard processes. This also leads to rethinking how the work is done from the ground up (BPR: Business Process Reengineering). Once you shift from "preserve the old way of doing things" to "rebuild it into the most efficient shape by today's standard," your options start to look different.

When Customization Becomes "Penny Wise, Pound Foolish"

That said, fitting everything to the package isn't always right either. The dividing line is whether the operation in question is a source of your competitive advantage.

• Operations where you don't differentiate from competitors (accounting, payroll, expense reimbursement, etc.) → fit to the standard. There's little point in being distinctive here.
• Operations that are your strength itself (proprietary production methods, handling unusual business practices, etc.) → these are worth being particular about.

Lock down the undifferentiated parts with off-the-shelf solutions, and invest only in the operations that become your strengths. This separation is the trick to getting the most out of a limited budget.

Hard-to-See Costs — The "Lump Sum" Estimate Trap

When comparing costs, judging by the first figure you're shown is risky. Be especially wary of estimates bundled as a single "lump sum."

When something is summed up in one line like "Business support features, all-in: ¥X million," you can't tell where the money is going. That makes it impossible to compare against other vendors, or to say, "We can drop this feature for now." When you receive an estimate, the first thing to request is that it be broken out into a line-item detail by feature and by phase.

The same goes for infrastructure (cloud usage fees, servers, licenses, monitoring, and so on). It tends to get lumped together as "infrastructure, all-in," but this is an area with plenty of room to cut. Because costs shift depending on whether you switch to an annual contract and how you choose your licenses, having it broken down element by element makes it far easier to evaluate.

And compare not just on upfront cost but on the total over roughly five years (TCO: total cost of ownership, including maintenance, modifications, licenses, and changes in headcount). Even when upfront cost is low, it's not unusual for the numbers to flip once heavy annual maintenance fees are factored in.

Is It Worth the Investment? — Judge by ROI

Whenever you're torn over whether to include a feature, return to this equation:

Value of the feature = reduction in operational hours + increase in revenue (or reduction in errors and inventory)

Roughly estimate "how many hours of work per month this feature eliminates" and "how much it moves order volume or unit prices," then compare against development and operating costs. As a rule of thumb, keeping a benchmark like move forward if the investment pays back within 12 months; pause and rethink if it exceeds 24 months keeps your judgment from drifting. If you keep adding features by gut feel, the entire decision-making process slows down.

The "Local Optimization" Pitfall and Data Integration

When each department adopts its own convenient tool separately, each one may be useful on its own, yet the company as a whole stops meshing.

• The same customer information ends up duplicated and managed across multiple systems.
• Data drifts out of sync as it's handed off between systems.
• Input rules differ from system to system, so the figures don't line up when you try to aggregate them.

Every department is operating correctly, yet management loses sight of the whole. This is the problem of "local optimization ≠ enterprise-wide optimization."

To prevent this, you need both: (1) consolidating data into one place (an integrated database) and (2) aligning how the work is done (standardization). The concept that delivers these two together is ERP (Enterprise Resource Planning). When you're weighing package versus build-your-own, you'll make fewer mistakes if you broaden your view beyond "just this one operation" to "whether the data across the whole company connects."

Look at the Future and Data Migration From the Start

It's not enough for the system to work at the moment you go live. Always confirm these two points at the selection stage:

• Scalability: Can it hold up as your user counts, locations, and business partners grow in the future? Confirm the future ceiling concretely — for example, "we can add up to X suppliers."
• Migratability: How will you carry over your current data? Decide things like "can it import the past X years of data via CSV?" and "will we run the old and new systems in parallel during the switchover?"

Data migration and parallel operation are classic points that balloon in cost and effort at the last minute if overlooked. Put them on the table early.

A Checklist to Confirm Before You Choose

Before you move into ordering or comparison, check whether you can answer the following questions.

• Could this be handled with an existing tool or a spreadsheet in the first place?
• Is this operation a "strength" that differentiates you from competitors, or is it a general-purpose operation?
• Is the current way really optimal? Can you fit it to a standard process instead?
• Is the estimate broken out into line items by feature and phase, structured so things can be trimmed?
• Are you comparing on the five-year total (TCO), not the upfront cost?
• Is there a realistic prospect of recovering this investment through reduced hours or increased revenue?
• Will the data connect across the whole company so that management can see the situation?
• Have you set a direction for future scale-up and data migration?

A Concrete Example: Overhauling Order Management

Suppose you're systematizing an order-management operation that's currently run on paper, fax, and Excel. Before assuming "develop the whole thing custom," look at the operation in parts.

• General parts like accounting integration and billing: Fit these to a standard package or SaaS. You don't differentiate here, and the vendor takes care of keeping up with legal changes.
• Your own proprietary inventory-allocation rules or unusual transaction terms: If this is a strength, build only that part custom (or absorb it through the settings of a highly extensible package).
• Document formats that differ by business partner: First check whether standard features can absorb them, and handle only the truly necessary cases as one-off customizations.

Simply by separating "the parts you lock down with standards" from "the parts you build custom" like this, you can cut cost and timeline dramatically compared with developing the whole thing in-house. The idea is to concentrate your resources where distinctiveness pays off, rather than building everything from the ground up.

Things to Watch For When Choosing a Package

Packages have their own pitfalls. Confirm the following before placing an order.

• Over-customization: Pile on modifications that stray from the standard, and you'll no longer be able to keep up with the vendor's version upgrades — leaving you "frozen in place." As a rule, keep modifications to a minimum.
• SaaS lock-in: Convenient as it is, confirm before signing whether you can export your data and switch to another vendor when you decide to leave.
• Don't decide without seeing the frontline: Having upper management choose the product on their own, only for it to clash with frontline operations and go unused, is a textbook failure. Interview the people who will actually use it before you choose.
• Avoid "just get every feature": Contracting for features you may never use inflates both cost and operational burden. Start with the scope you actually need, and pick a product you can expand later.

The Mindset of Proceeding in Stages

Trying to overhaul a large core system all at once in a single sweep sends both risk and cost soaring. Phased adoption is also effective: switch over the high-volume core operations first, and push peripheral operations and exception handling to later stages. By confirming the results and usability within that first scope before moving on, you avoid major rework.

Related material: Business Process Reengineering (BPR) and "how to write a business flow" are explained in detail in our freely available IT Consulting Guidebook.

Summary

More tailoring isn't always better. First, carve out the parts you don't need to build; fit undifferentiated operations to a standard (package/SaaS); and invest in custom building only for the operations that become your strengths. Break costs into line items and compare on the total, then verify with ROI whether the investment is worth it. And decide by looking not at a single operation but at whether the data connects across the whole company.

Think in this order, and you can avoid over-engineering while spending money where it's genuinely needed. When you're unsure which fits your company better, the best place to start is to take stock of your current operations and systems once, and sort out "the parts you can fit to a standard" from "the parts worth being particular about."

And whether you go with a package or build it custom, getting a rough sense of the cost early on makes internal decision-making far easier to move forward.