Build vs buy software: custom or off-the-shelf?
You have three choices, not two: buy it, build it, or build a thin layer on top of the system you already pay for.
The short answer
Buy the software your competitors run the same way you do, build only the part that is how you win, and connect the two through the vendor's public API before you replace anything.
Payroll, email and accounting fail the "is this how we win?" test for almost every business you could name. Someone else runs them at a standard you won't beat, so buy them and stop thinking about them.
Most people skip the middle option. You keep QuickBooks, Salesforce, ServiceTitan, Procore, Clio, Toast or whatever you run for what it does well. Then you build the thin layer that makes it yours: the rule, the report or the handoff your team still does in a spreadsheet.
So custom software beats off-the-shelf software in two places only. One is that layer. The other is when no product will agree with the systems you already run.
Off-the-shelf, integrate around it, or custom build
Each row is a bill that lands after you decide. You won't find the middle column in most comparisons.
| What you are weighing | Off-the-shelf | Integrate around it | Custom build |
|---|---|---|---|
| Fit to how you work | Close, then never closer. You bend to it. | The product handles the standard work. Your layer handles the rest. | Exact, and it stays exact as you change. |
| Setup effort | Configuration and training. | A scoped build against one or two APIs. | A full build, with nothing usable on day one. |
| Data ownership | In the vendor's database, out through their export. | Core records stay with the vendor. Your layer's data is yours. | All of it is yours: the database, the schema, the code. |
| Integration with what you run | Whatever their API and app store allow. | Built on the public API of QuickBooks, Salesforce, Procore or whatever you run. | Whatever your other systems expose. |
| Who maintains it | The vendor, on their roadmap. | The vendor for the core. You, or a partner on an SLA, for the layer. | You, or whoever you pay to. This is the cost people miss. |
| Exit cost | Their export format and a migration you did not scope. | Low. Switch the core product and rewire one layer. | Your code and data, which is only an exit if it is documented. |
| Compliance evidence | Their audit reports, which auditors accept quickly. | Theirs for the core, yours for the layer. | Yours to produce. Slower, and you control what it says. |
| The failure nobody plans for | The vendor is acquired and drops the feature you depend on. | The vendor changes an API version and your layer needs an update. | The one engineer who understood the data model leaves. |
Which one is your situation?
Four questions about your business rather than your preferences. Answer them honestly and you'll usually find the result is obvious.
Would a competitor run this process the same way you do?
How many systems must this agree with?
Who will own it in two years?
Has anyone tried a product for this already?
Every outcome
- Buy it
- Your process is standard and a product already handles it. When you buy, somebody else pays for the maintenance, the security patches and the compliance paperwork. Spend your engineering where it changes the outcome.
- Build it
- Your process is how you compete, or no product will agree with the systems you already run. You'll need custom software development, and the question that matters most is who maintains it afterwards.
- Buy the base, build the layer
- You buy the parts that are solved and build the thin layer that makes them yours. Shift Link runs on Supabase for identity and storage, and the custom code is the compliance rule that decides who may work a shift.
Buying
Where it wins
- It works the day you pay for it.
- Maintenance, security patching and uptime are somebody else's payroll.
- Auditors accept a vendor's certifications faster than they accept your documentation.
- You find out quickly whether the process was worth automating at all.
Where it hurts
- You bend your process to the product, and every year the gap between them widens.
- Per-seat pricing grows with headcount whether or not the value does.
- Integration stops where their API stops, and their roadmap is not yours to move.
- A vendor acquisition can cancel the feature your operation depends on, with no appeal.
Building
Where it wins
- It fits the process exactly, and keeps fitting when the process changes.
- It can agree with every system you already run, including the old one nobody wants to touch.
- You own the data model, so reporting is a query rather than a support ticket.
- The advantage is yours instead of being available to every competitor for the same monthly fee.
Where it hurts
- Nothing exists on day one, and the useful version takes longer than the demo.
- Maintenance is now your bill. This is the cost that sinks build decisions, not the build itself.
- You produce your own compliance evidence, which is slower than pointing at a vendor's certificate.
- Undocumented code isn't an asset. It's a system only one person can fix.
- Name itWrite the process down first.
- ShopTry two products properly.
- MeasureWhat percent of the job did they do?
- SplitBuy the base. Build the gap.
- AssignName who owns it in year two.
Teams skip the shopping step and build something that already existed. Others skip the last step and buy a system nobody owns.
Rules that settle most of these
Ask yourself which cost you'd rather carry for five years. Your options are a subscription that grows with headcount, a thin layer that needs an owner, or a whole system that needs one.
- 01Buy it if a competitor could run the same process on the same product and nothing would change for your customers.
- 02Integrate around it when the product does most of the job and you're re-keying the rest into a spreadsheet.
- 03Build custom when the process is the reason customers pick you, or when no product agrees with the systems you already run.
- 04Do neither if nobody has written the process down yet. Software can't fix a rule your team doesn't agree on.
- 05Buy it, whatever the analysis says, if you can't name the person who owns the custom version in year two.
By industry: is custom software better than the system you run?
- Procore or Buildertrend →General contractors
- Procore alternatives →Subcontractors and mid-size GCs
- ServiceTitan for HVAC →HVAC contractors
- ServiceTitan for plumbers →Plumbing and electrical contractors
- JobNimbus or AccuLynx →Roofing contractors
- Jobber →Landscaping and lawn care
- Routeware →Waste and recycling haulers
- Bullhorn or Avionte →Staffing and recruiting agencies
- Karbon or TaxDome →Accounting and CPA firms
- Clio →Law firms
- Guidewire or Duck Creek →MGAs and carriers
- In-house AI team →Digital and marketing agencies
- A standard WMS →3PL warehouses
- SafetyChain or TraceGains →Food and beverage manufacturers
- An ERP for a job shop →Manufacturers and job shops
- An ERP for a repair yard →Shipyards and ship repair
- Quorum or Enverus →Oil and gas operators
- AppFolio or Buildium →Property management companies
- Mindbody or Mariana Tek →Gyms and fitness studios
- Zenoti or Boulevard →Med spas
- Urable or Detail Pilot →Auto detailing businesses
What we tell people who ask us to build
We still talk people out of building, and the reason is always the same: nobody can name who owns it in year two. If you can't name that person, buy the product and live with the workarounds.
Our most common answer is the split. Shift Link runs on Supabase for identity and storage. Its custom part is the rule on top: nobody gets a shift until the UK Right-to-Work check clears and their documents are current. You can't buy that rule, because it belongs to one staffing firm. The firm reports 70% less manual compliance verification since the platform replaced its spreadsheets.
Your cost question gets the same answer on every engagement. You start with a free scoping call, then a fixed-fee Blueprint, credited in full against the build. An engineer reads your systems and APIs, then writes the plan and the price. If the plan isn't one you'd act on, you don't pay for it. Builds are then fixed-price per milestone, accepted against written criteria.
Some of the systems we have shipped
Common questions
01Is custom software better than off-the-shelf software?+
Custom software is better only for the part of your business that is how you win. It also wins where no product fits the systems you already run. For everything standard, you're better off with off-the-shelf software, because the vendor carries the maintenance. Most of the businesses we work with end up with both: a bought core and a custom layer on its API.
02Can I keep my current system and add custom software?+
Yes, and it's usually the right answer. You keep the product for what it does well. Then you build a layer on its public API for the rule, report or handoff it can't handle. That keeps your maintenance bill small, because you only own the part nobody else could sell you.
03How much does custom software cost?+
There is no honest number before an engineer has read your systems. So you start with a free scoping call and then a fixed-fee Blueprint, credited in full against the build. The Blueprint fixes your scope and your price. If the plan isn't one you'd act on, you don't pay for it.
04When is off-the-shelf the right answer?+
Off-the-shelf is right when a competitor could run the same process on the same product and your customers wouldn't notice. It's also right when you can't name who will own a custom system in two years. Run your real process through a trial, and if less than about a fifth of the work is left over, buy it.
05Does buying protect us from vendor risk?+
Buying moves the risk rather than removing it. A vendor can be acquired, raise prices or retire the feature you built an operation around, and you get no vote. Building moves that risk onto your ability to keep an owner assigned, which is at least a risk you can see.
Related
- Custom software development →Where we do this work, and what happens after launch.
- How we work →The scoping call, the fixed-fee Blueprint and milestone acceptance.
- Best custom software development companies →How to compare the firms that build this.
- Airtable vs custom build →Same question, asked at the low-code level.
- ChatGPT Enterprise vs custom AI →Buy vs build for an AI system.
