Build vs Buy: When to Customize Software and When to Adopt

Last updated: September 15, 2026

By Colin Boothe, CIO at Foretopia

Build vs buy software decisions hinge on whether a process is the reason customers choose you over a competitor. If it is, customize it or build it. If it isn’t, adopt the software’s standard process and change how your team works. Most mid-market build requests fail that test.

The quote was $184,000 for a custom quoting app. A building-products distributor outside Salt Lake, around $90M in revenue, three years on NetSuite. Their sales manager told me, very calmly, that NetSuite could not handle their pricing.

Okay. Show me the pricing.

That took two weeks, because the pricing didn’t exist anywhere you could point at and was spread across a spreadsheet, a laminated sheet taped inside the will-call counter, and the head of one woman who spent half of those two weeks out visiting job sites. Her initials were on every exception. When we finally wrote it all down there were 43 rules.

Then we pulled twelve months of quotes and checked which rules had actually fired. Nine of them covered almost every line that year. Thirty-one hadn’t been used once. Three contradicted each other, which finally explained a customer complaint from March that nobody had managed to trace.

Nine rules. NetSuite’s standard price levels and quantity pricing handled seven of them without a line of code, and they had been paying for those features the whole time. Nice. The other two were contract pricing on large job bids, which is genuinely how that company beats the national chains, so we built that part. A small script. Not an app.

The software was fine. The rule book was a museum.

I tell that story because it’s what the build vs buy decision looks like about eight times out of ten at companies your size. Almost nobody is really weighing a software build against a software purchase. They’re weighing a software build against changing how somebody works, and the build feels easier, because software doesn’t argue back in the meeting.

Two biases up front. My group at Foretopia writes code on NetSuite, so every “build” answer is one I get paid for. And you’re reading this on KORE1’s site, where the IT staffing team places the administrators and developers who end up owning whichever way you go. Weigh both. If this reads like a pitch for building, I did it wrong.

It pairs with a longer piece on getting more out of NetSuite before you spend on anything new. Same argument, other end. Adopt first. Customize with a reason.

There Are Four Answers, Not Two

Build vs buy is the decision between writing software your company owns and maintains, and licensing a product somebody else maintains. For mid-market business systems the real menu has four rungs: adopt the product as shipped, configure it, extend it with code on the platform, or build something separate.

Buy is never just buy. Nobody licenses an ERP and uses it untouched. Build is rarely just build, either, because the custom thing still has to talk to the ERP, the ecommerce platform, the bank, and the warehouse. So the useful question isn’t which one. It’s which rung, for which process.

Most arguments I sit in jump straight from rung one to rung four, as if the only choices on the table were living with the software exactly as it shipped or paying somebody to write the whole thing again from scratch. Rungs two and three are where most of the good answers live, and where most of the money should go. If the fight in your building is specifically workflow versus script inside NetSuite, I went through that boundary row by row in SuiteScript vs SuiteFlow.

One more distinction, since the phrase gets used for two different jobs. If you run a product engineering team deciding whether to build a capability into software you sell, Kris Drouet’s five-number framework for engineering leaders is the better lens, and there’s a free tool that plots those five numbers on one axis. This piece is about the systems you run the business on. Different money. Different failure.

Most Build Requests Are a Process Nobody Wants to Change

ERP isn’t complicated. I’ll keep saying that until somebody pays me to stop. What’s complicated is twelve people who each learned a slightly different version of order entry from whoever trained them in 2017, and who all have a perfectly good reason their version is the right one.

So when a request lands as “the system can’t do X,” I’ve learned to translate it before I price it. Nearly every time, it lands in one of three piles.

• The system can do X and nobody on the team knows where the setting is. By a wide margin this is the most common one, and the cheapest. Twenty minutes with an administrator.
• It does something close to X. Close enough, honestly, if you’d let go of a report layout your CFO’s predecessor designed.
• Sometimes X really is special. Contract pricing on job bids. A landed-cost allocation that follows how your freight actually moves.

For that last bucket I use one test. Would a customer notice if this process ran exactly like everybody else’s?

Your accounts payable approval chain fails it. Nobody has ever bought a pallet of drywall because your AP clerk routes invoices in an unusual order. Same goes for the month-end close, expense reports, payroll, sales tax, fixed assets, and most inventory counting. Those processes have a correct, boring answer, the vendor has already built it, and thousands of other companies are testing it for you every release. Adopt them. Grumble for a quarter. Move on.

Pricing on a job bid can pass. So can how fast you turn a custom order, what a customer sees when they check an order status, or how a field technician logs a warranty repair. If a competitor would have to copy it to take your customers, it’s worth spending on.

Accuserve is a good example of that second group handled well. In retail construction, knowing which jobs actually made money decides what you bid next, and for them that answer used to come out of a stack of spreadsheets, by hand, over a period of months. We didn’t stand up a separate app for it. The profitability view is built inside NetSuite and updates without anybody touching it, which is customization on the platform rather than a second system parked next to it. That difference matters more than people expect, because a second system brings its own logins, its own releases, and its own integration that somebody has to watch forever.

The thing nobody likes hearing. The process somebody fights hardest to protect is usually not in the second group. It’s just the one they understand best.

Every Customization Gets Retested Forever

NetSuite delivers two scheduled version upgrades every year. Salesforce ships three seasonal releases a year, in spring, summer, and winter. Your ecommerce platform, your WMS, and your tax engine each keep their own calendar, and none of them checked yours.

Adopted processes ride those releases for free, which, if you think about it for a minute, is most of what the subscription money is actually buying you, whether or not anybody at your company ever reads the release notes. Every rung above adopt adds something a person on your side has to check after each release, and the checking never ends, because the releases never end. Forever.

On regulated work we price that obligation as its own annual line. For one serious NetSuite integration it runs about 120 hours a year across both releases, which covers somebody reading the release preview for anything it touches, rerunning the regression tests, and writing down what happened. You probably aren’t regulated. Your number is smaller. It isn’t zero, and it’s almost never in the build quote, because a build quote describes year one and this is the bill for years two through ten.

The federal government makes a decent horror story here. In a July 2025 report the GAO noted that agencies have typically reported spending about 80 percent on operations and maintenance of existing IT, out of a federal IT budget north of $100 billion a year. Eighty percent. Just keeping the lights on. Your company isn’t the federal government, thank God. The ratio still travels. Launch is the cheap part of owning software, and every customization you add nudges a little more of your budget toward that eighty.

Then there’s the person. The Bureau of Labor Statistics puts the mean annual wage for software developers at $148,100 as of May 2025, and a developer who also understands NetSuite governance limits and your contract pricing rules is not an average developer. Rarer, too. One of them is also a single point of failure with a LinkedIn profile. When they leave, the custom code stays. The understanding of it walks out with them.

The Overrun Lives Between the Pieces

This is the part that ought to scare a CFO more than the maintenance line does.

Bent Flyvbjerg, Alexander Budzier, and four co-authors studied 5,392 IT projects for a 2022 paper in the Journal of Management Information Systems and found that cost overruns follow a power-law distribution. Lots of projects run a little over. A fat tail runs catastrophically over. The mechanism they point to is interdependency, where a problem in one technical component sets off a chain reaction through every component connected to it.

Read that as a customization policy, because it is one. Every custom field, script, and integration you add is one more connection in that web, and the math doesn’t care whether it was a two-hour favor for the warehouse manager or a six-month project with a steering committee. Most stay harmless. A few quietly become load-bearing.

Last year I opened an account where one custom checkbox, a ship-complete flag somebody added on a slow afternoon, was being read by three saved searches, a workflow, the WMS integration, and the Shopify connector. Someone in customer service changed the options in a related dropdown on a Monday. Four things broke by Wednesday. The first person to notice was a customer whose order arrived in three boxes on three different days. It sucks. Nobody had ever drawn that dependency anywhere, so it existed in exactly one place, which was production.

So the cost of a customization isn’t the build hours. It’s the build hours plus whatever the thing can break when something next to it changes, and that second number never shows up gradually.

The Accounting Argument Your CFO Will Make

I’m a CIO, not your CPA. Run this past your controller before you repeat it in a board meeting.

Two accounting quirks make building look better on paper than it is. Under FASB’s ASU 2018-15, implementation costs you capitalize for a cloud subscription get amortized in the same income statement line as the subscription fees, so they read like operating expense. Software you build for internal use is capitalized and amortized as its own asset, which tends to land below EBITDA. And the tax side swung back toward building in 2025, when the new Section 174A restored immediate deductions for domestic research and experimental spending, a category that includes software development, for tax years beginning after December 31, 2024. The IRS set out the related elections in Rev. Proc. 2025-28.

Neither one is a reason to build. Both will come up anyway, usually from somebody who has already decided what they want and is now shopping for a slide that makes the decision look like finance’s idea instead of theirs. A prettier EBITDA line does not retest your scripts.

Before Anyone Opens a Code Editor

This is the order I run it in with clients. Nothing clever. It just stops the expensive conversation from happening first.

1. Write the process down the way it actually runs today, with counts from the last twelve months. How many orders hit the exception? How many rules fired? The distributor’s 43 rules became nine at this step, and it cost nothing but two weeks of patience.
2. Run the vendor’s standard version for a month with the people who do the work, in a sandbox or on a slice of real volume. Keep a list of every time it genuinely fails, not every time somebody dislikes it.
3. Check what you already license. Go through the modules and features in your contract and find the ones nobody switched on. I’d bet lunch that at least one item on the complaint list is sitting in there, paid for.
4. Price whatever survives over five years: build hours, every vendor release of retesting, the integration, and a named owner. A person, not a department.
5. Pick the lowest rung that clears the list, and write one paragraph saying why. Put it somewhere the next administrator will actually find it.

Step three is my favorite, partly because it’s free and partly because I have watched a company approve a six-figure build for something that turned out to be a checkbox in a module they’d been paying for since the original implementation. It’s also the step that most often ends the project, happily, before anybody writes a line.

When I Tell People to Build Anyway

I lean adopt. Hard. But some of the worst accounts I’ve inherited came from the opposite mistake, somebody forcing a standard process onto work it plainly didn’t fit, so here’s where I push the other way.

Build when the software is the thing you sell. Zamp is the cleanest case I’ve worked on. What they needed was a NetSuite product of their own to put in front of customers, so we took it from design to launch in roughly five months, and they sell it through the NetSuite marketplace now. There was never a buy option there. Nobody licenses the product they’re trying to sell.

Build the seam between two systems when neither vendor owns it. Your ERP vendor supports its side of the API, and your WMS vendor supports its side. The logic in the middle, the part that decides what happens when an order shows up with a SKU the warehouse has never heard of, belongs to nobody unless it belongs to you. No rung-one answer exists for that. Somebody writes it. The only question is whether it gets written deliberately, documented, and owned, or grows by accident inside a connector’s field mappings over three years. The deliberate version is what NetSuite integration best practices walks through.

Watch the meter.

Some subscriptions are priced in a way that punishes growth: per transaction, per serial number, per API call. On one engagement the licensing was metered by units, and blocks allocated to a supplier counted against the allowance whether anyone used them or not. The pricing model was quietly making design decisions. Sometimes the cheapest honest move is a small build that keeps the metered product doing only the part it’s best at.

And yes, the AI thing. Small internal tools really are cheaper to write than they were two years ago, and my team uses AI on NetSuite development daily, which I wrote up in AI-augmented development. That knocks down the day-one cost of rungs three and four. It does nothing for the retest bill, the owner, or the interdependencies. A cheaper build is still a build, and it’s still yours.

The companies that handle all of this well have one thing in common, and it isn’t budget. Somebody’s actual job is saying no to the tenth customization request. At mid-market that is often a part-time seat, a fractional CIO a day or two a week, or an internal administrator with enough standing that the sales VP can’t walk around them. If that seat is empty, KORE1’s NetSuite administrator staffing desk fills it, and if you aren’t sure yet that it’s a full-time job, a contract administrator for six months answers that faster than another org-chart debate.

The Pushback I Get in Budget Meetings

Our partner says NetSuite can’t handle our pricing. Do I believe them?

Ask them to name the rule it can’t handle, in writing, with an example order attached. A real constraint fits in one sentence. If what comes back is a paragraph about flexibility and future growth, you’re looking at a preference with a price tag, and you should see the standard version run against your own data before you approve anything.

Isn’t custom software cheap now that AI writes most of the code?

Cheaper to write. Not cheaper to own. Code generation really has cut the first-build cost on small tools. Testing it after every vendor release, knowing what it touches, and keeping someone around who can explain it in two years all cost what they always cost.

At what point have we customized the ERP into something that isn’t really the ERP anymore?

When a routine vendor release takes your team more than a week to test, you’re there. Another tell is new hires who used NetSuite at their last job and can’t find their way around yours. The product is still underneath. Technically. You’re just paying a subscription for a platform you’ve mostly replaced with your own decisions, and doing the vendor’s regression testing for them without the discount.

SuiteApp, separate SaaS tool, or our own script. Where do we look first?

A mature SuiteApp comes first, if one exists with real customers in your industry. It runs inside NetSuite, your data stays in the account, and the publisher is on the hook for keeping it working through releases. A separate SaaS product earns second place when the job is big enough to justify its own vendor, like tax, shipping, or demand planning. Your own script goes last, although for a small, specific rule it wins more often than that ranking implies. Just not first.

Our CFO likes building because it capitalizes. Is that a legitimate reason?

Legitimate, and incomplete. The accounting treatment is real and your controller should model it. It changes where the cost shows up, not how big it is. Put the EBITDA effect and the permanent retest obligation on the same page and let the CFO decide with both halves in view.

We customized nearly everything years ago. Can we still claw our way back to standard?

You can, but plan on doing it slowly. Start with an inventory of every script, workflow, and custom field, sorted by when each one last ran. On the accounts I open, a surprising share of it hasn’t fired in a year. Switch those off in a sandbox, wait out one release cycle, then retire them for good. Whatever is left is the real conversation, one process at a time, starting with whichever one broke most recently.

Adopting Is the Harder Meeting

Build vs buy sounds like a technology decision, which is why it gets handed to IT. Mostly it isn’t one. Adopting means telling a department their way of working is changing. Building means telling finance a number. The second meeting is easier, so companies hold it far more often, and then they pay for that choice every single release for the next decade without ever connecting the bill to the meeting.

Hold the harder meeting. Mine rarely run past an hour.

Want a second read first? Send me your list of customization requests, or the quote for the build you’re about to sign, and hit me up on LinkedIn. I’ll tell you which rung each item belongs on. Takes me about fifteen minutes, and I’ll be wrong about a couple of them, which is also worth knowing.

If what you actually need is a person rather than a program, talk to KORE1’s recruiters about the seat. They’ve filled technology roles since 2005, and of the people they place, 92% are still employed in that role a year on. For a job whose whole value is remembering why you said no, that retention number matters more than usual.