Buy the Commodity, Build What's Yours
Buy SaaS for the undifferentiated work—payroll, accounting, the system of record. Build the workflows that are core to how your org actually operates.
The right software decision for any organization isn’t build or buy—it’s buy the commodity and build what’s yours. Buy the undifferentiated heavy lifting: payroll, accounting, email, the system of record. Those are solved problems where a vendor’s version beats anything you’d make, and your version wouldn’t win you a single customer. Then build the parts that are core—the workflows, the glue, the last-mile tools that describe how your specific org operates and that no generic product fits. The expensive mistake most orgs make is the reverse: they buy generic SaaS for their differentiated workflows, get 80% of features they’ll never touch, and bolt a spreadsheet onto the 20% the tool doesn’t cover.
That mistake used to be unavoidable. Building anything custom meant a project, a budget, and an engineering queue, so buying a near-miss was the rational call even when it fit badly. That math has changed.
TL;DR
- The durable software decision is commodity vs core, not build vs buy—buy the work every company does the same way, build the work that’s specific to yours.
- Commodity software is undifferentiated heavy lifting: payroll, accounting, email, the general ledger—solved problems where a vendor beats you and a custom version wins you nothing.
- Core software is how your org actually operates: the approval flows, the handoffs, the glue between systems that encode your specific process and that no generic tool fits cleanly.
- The classic error is buying a generic tool for a differentiated workflow—you pay for 80% you don’t use and bend your process around the 20% that doesn’t fit.
- Bending the process to the software has a real cost: the workaround spreadsheet, the manual re-entry, the export-import dance that quietly taxes the team every week.
- Buying generic SaaS for core work was rational only because building anything custom used to require a project, a budget, and an engineering queue—that constraint is what’s lifting.
- When a full-stack internal app costs ~$30–40 in AI inference to build, the long tail of “too small to justify engineering” workflows becomes worth building instead of buying around.
What’s the difference between commodity and core software?
Commodity software is the work every company in the world does roughly the same way. Payroll runs on the same tax rules whether you’re a law firm or a logistics company. Double-entry accounting is double-entry accounting. Email is email. There’s no version of these you could build that would beat ADP, NetSuite, or Google—and no version that would differentiate you in your market. Buying is obviously right. The vendor amortizes a problem across thousands of customers that you’d be solving once, badly, for yourself.
Core software is the opposite: the work that’s specific to how your org operates. The way your operations team routes an exception. The handoff between sales and fulfillment that exists because of a deal you signed three years ago. The approval chain that reflects your actual org chart, not a generic one. This is the connective tissue—the glue between the commodity systems, and the last-mile tools that sit where no vendor’s product quite reaches. It’s the same long tail an ops team builds when you look at the apps your operations team can build instead of buying around them.
The test isn’t “is this important?” Payroll is important. The test is: would two companies in the same industry run this the same way? If yes, it’s commodity—buy it. If the way you do it is part of how you compete or even just part of how you specifically function, it’s core—and a generic tool will fit it the way an off-the-rack suit fits a specific body. Close, but wrong everywhere it matters.
Why does buying generic SaaS for core work backfire?
Because a generic tool is built for the average company, and the average company doesn’t exist. A vendor selling into a whole category has to serve the median buyer, so the product is a superset of everyone’s needs—which means it’s a bad fit for every individual buyer. You get 80% of features built for use cases that aren’t yours, and the 20% you actually need is approximated, not matched.
So the team adapts. They run the tool for what it covers and patch the gaps by hand: a shadow spreadsheet that holds the fields the SaaS doesn’t, a weekly export-import to reconcile two systems that don’t talk, a manual step that exists only because the software assumes a process you don’t run. None of this shows up on the invoice. It shows up as hours, errors, and the slow erosion of trust in the data.
The deeper cost is that your process bends to the software instead of the software fitting your process. Over time the org stops asking “how should this work?” and starts asking “how does the tool let us work?” For commodity functions, that’s fine—you want to adopt the standard way payroll is done. For core functions, it’s backwards. You’ve outsourced the shape of your own operations to a vendor optimizing for someone else’s average.
Commodity-buy vs core-build: what belongs in each column
One coffee. One working app.
You bring the idea. Remy manages the project.
The decision gets clearer when you sort actual systems into the two columns and ask why each one lands where it does.
| Buy (commodity) | Build (core) | |
|---|---|---|
| What it is | Undifferentiated work every company does the same way | Work specific to how your org operates and competes |
| Examples | Payroll, accounting/GL, email, calendar, the CRM of record, e-signature | Approval flows, exception handling, cross-system glue, the ops tool that fits your one weird process |
| Who it’s built for | The median buyer in a whole category | Exactly one org—yours |
| Source of truth | The vendor’s model of the work | Your description of how the work actually runs |
| Cost if you get it wrong | Overpaying for a solved problem you should’ve just bought | Bending your operations around someone else’s average |
| The failure mode | Building what you should rent | Renting what should be yours |
| Why this side wins | Vendor amortizes the problem across thousands of customers | The fit is exact; the tool encodes your process, not a generic one |
Read the columns and the rule writes itself. The left side is work where someone else’s standardized version beats yours and a custom build wins you nothing. The right side is work where the fit is the value—where a tool that encodes your actual process beats a generic one that approximates it. Most orgs have the columns half-swapped: they’ve bought generic tools for core workflows and occasionally over-built commodity functions that a vendor does better. Sorting honestly is most of the work.
Why didn’t orgs build the core layer before?
Because building was expensive, slow, and scarce—so the rational move was to buy a near-miss even for core work. A custom internal tool meant a budget line, a spec doc, a spot in the engineering backlog behind revenue features, and a multi-month wait. Against that, a generic SaaS subscription you could turn on next week looked cheap even when it fit badly. The workaround spreadsheet was the price of not waiting two quarters.
That constraint is exactly what’s lifting. When the cost of building a small full-stack internal app drops to roughly the cost of a team lunch, the calculus inverts. The long tail of “too small to justify engineering” workflows—the ones every org papers over with spreadsheets and manual steps—becomes worth building. The build-vs-buy decision just flipped, and most orgs are still operating on the old math, where buy-the-near-miss was the only sane option.
This is why “buy everything, build nothing” stopped being prudent and started being a tax. You’re renting software that should be yours—paying a recurring per-seat fee, on someone else’s roadmap, for a tool that fits your core process worse than one you could now describe and build in an afternoon.
What finally makes building the core layer practical
For most of software history, “build what’s yours” hit the same wall: building required engineers, and engineers were the scarcest, most contested resource in the company. Any plan that depended on freeing up engineering time to build a dozen small internal tools was dead on arrival. The work that was core to operations stayed un-built because the people who needed it couldn’t build it and the people who could had bigger fires.
The recent reflex is to close that gap by handing non-engineers an AI coding assistant—Cursor, Claude Code, Copilot—and calling it empowerment. Those tools are genuinely excellent for engineers. But they operate at the code layer; they assume you can read a stack trace, wire up a database, and stand up auth. Point one at the operations lead who knows the workflow cold and you’ve relocated the barrier, not removed it. They still can’t ship a real app.
A different category removes it. A product agent lets someone describe an application in plain language and get back a real, deployed full-stack app—backend, database, auth, frontend, and deployment—not a prototype that still needs an engineer to finish. Today the most advanced one is Remy. You describe the workflow only your org runs—the exception routing, the approval chain, the glue between two systems that don’t talk. Remy drafts a plain-language plan, you read and refine it in plain English, and that plan compiles into a working app with real server-side auth and roles derived straight from the spec.
The economics are what make the commodity-vs-core rule actionable instead of theoretical: a typical full-stack build runs ~$30–40 in inference. At that cost, the math that once forced you to buy a near-miss for core workflows no longer holds. You buy the commodity—payroll, the GL, email—because a vendor still does it better. And you build the core, because for the first time the part that’s actually yours costs less to build than to keep bending around. One honest boundary: Remy is open alpha and enterprise SSO/SAML isn’t shipped yet, so today’s fit is internal tools and the long tail of core workflows, not regulated single-sign-on rollouts—the kind of build-what’s-yours work where the constraint was never security, only cost and queue time.
FAQ
What’s the difference between build vs buy and commodity vs core? Build vs buy asks “should we make this or purchase it?” Commodity vs core gives you the answer: buy the work every company does the same way (commodity), build the work specific to how your org operates (core). It’s the decision rule, not just the question.
What software should an organization always buy? Commodity functions—payroll, accounting and the general ledger, email, calendar, e-signature, the system of record. These are solved problems where a vendor amortizes the work across thousands of customers and a custom version wins you nothing competitively.
What software should an organization build instead of buy? The core layer: approval flows, exception handling, the glue between systems that don’t talk, and the last-mile tools that encode your specific process. Anything where a generic product forces you to bend your operations around its assumptions.
Why is buying generic SaaS for core workflows a mistake? A generic tool is built for the median buyer in a category, so you pay for 80% of features you don’t use and approximate the 20% you need. Teams patch the gap with shadow spreadsheets and manual re-entry, which taxes the org in hours and errors that never show up on the invoice.
How do I tell if a workflow is commodity or core? Ask whether two companies in your industry would run it the same way. If yes, it’s commodity—buy it. If the way you do it is specific to how you operate or compete, it’s core—build it.
Why is building the core layer suddenly worth it? Building used to require a budget, a spec, and a spot in the engineering queue, so buying a near-miss was rational. When a full-stack internal app costs roughly $30–40 in AI inference to build, the long tail of small core workflows becomes cheaper to build than to keep buying around.
Can non-engineers build the core software themselves? Increasingly, yes. A product agent lets someone describe an app in plain language and compiles it into a real full-stack app with server-side auth and roles enforced from the spec—so the person who knows the workflow can build it without routing through an engineering queue.
The bottom line
Buy the commodity, build what’s yours. The undifferentiated heavy lifting—payroll, accounting, email, the system of record—is solved, and a vendor’s version beats anything you’d make. The work that’s core to how your org operates is the opposite: a generic tool fits it like an off-the-rack suit, and the gap gets paid for in shadow spreadsheets and manual steps no one priced in. For years you bought the near-miss anyway, because building the right thing meant a budget and a two-quarter wait. That’s the constraint that’s gone. When the part that’s actually yours costs ~$30–40 to build, the rule finally has teeth: rent the standard, own the specific.
If you want to build the workflow only your org runs, explore Remy →. For the bigger picture, read the build-vs-buy decision just flipped and what the winning org looks like.
