Custom vs off-the-shelf
Buy it, unless the process is the product
Most teams should buy, and custom only earns its place when the workflow you would have to give up is the thing your customers are actually paying for.
Ask us which one fitsWhy this is harder than it should be
Both vendors are telling the truth about different halves of your problem. The product vendor demonstrates the part that fits and calls the rest reporting; the development shop hears the part that does not fit and quotes for rebuilding all of it. Neither is lying, and neither is describing your actual month.
One question settles this more often than any feature list. Name the step in your process that would break if you did it the way the software wants, then say out loud why a competitor could not simply do it the software's way. If you cannot name that step, buy the product.
Where it bites
Where the two genuinely diverge
Feature lists rarely settle this. These are the places where the choice starts costing you something real.
The part that does not fit
Every product covers most of a workflow. The question is whether the remainder is a monthly spreadsheet someone maintains by hand, or the reason customers chose you.
Whose roadmap you are on
A product ships your missing feature when enough other customers ask for it too. Custom ships it when you fund it, which is a bill rather than a favour.
Integrations, not features
A connector list looks generous until your ERP or your payment rail is not on it. Then you are writing the webhook layer you bought the product to avoid.
Getting your data back out
Before signing, ask for a full export including history and attachments, not a CSV of the current view. That answer decides how reversible the cheap option really is.
Where data is allowed to live
If HIPAA or a data-residency clause forbids records leaving your own infrastructure, most hosted products are ruled out before anybody gets round to comparing features.
What upgrades do to you
A vendor can redesign the screen your team learned or deprecate the API version your integration calls. Custom changes nothing until you do, including the patch nobody scheduled.
How the cost behaves
Subscription cost grows with seats and usage, so it tracks your headcount. Custom is front-loaded, then quieter, provided someone is funded to keep it patched and hosted.
Time to the first real use
Buying starts on Monday. Buying also ends in a data migration and a configuration project, which is where most software rollouts actually spend their months.
The mix most projects should be
Buy the commodity parts: accounting, helpdesk, auth, CRM. Build only the workflow that differentiates you, and own the API layer joining the two together.
Trade-offs
Four dimensions that actually decide it
Read the note rather than the verdict. Each of these cuts both ways, and the choice is really about which failure you can live with.
- COST OF CHANGE
- Cheaper to buy, until the change is yours
- Changing a product means a settings screen or a plugin, and both are quick. Changing something the vendor does not offer means waiting or leaving. Custom inverts that: every change is possible, and every change is quoted.
- TIME TO LAUNCH
- Off-the-shelf wins, clearly
- A product is usable within days. Custom needs scoping before any build begins, typically 8–12 weeks to a first workable version and longer once integrations land. Configuration and data migration slow both more than teams expect.
- WHO MAINTAINS IT
- Their engineers, or someone you fund
- With a product, patching and uptime are the vendor's problem and the subscription is what you pay for that. With custom the code is yours, and so is the call when a dependency stops receiving security updates.
- WHAT BREAKS FIRST
- Their pricing change, or your bus factor
- Products break you by changing terms, retiring a plan or sunsetting the integration you depend on. Custom breaks you when the one person who understood it leaves and nobody ever wrote down how deployment works.
So which one is yours?
Most readers belong in the right-hand column, and that is the correct answer far more often than our industry likes to admit.
Choose custom software if…
- The workflow you would have to abandon is what customers actually pay for.
- You have rebuilt the same spreadsheet workaround twice and it broke both times.
- Compliance forbids the data leaving your infrastructure and no vendor offers self-hosting.
- The software is the product you sell, not the tool sitting behind it.
Choose off-the-shelf if…
- An existing product covers most of the job and the gap is reporting.
- You cannot name who would maintain custom code a year from now.
- Your process is still changing every quarter and has not settled yet.
- The work is a commodity: payroll, accounting, email, helpdesk, CRM.
Frequently Asked
Questions
Common questions from teams deciding whether to buy software or build it.
No, and the comparison usually gets set up wrong. A subscription looks small per seat and then grows with headcount, while custom is front-loaded and afterwards mostly hosting and maintenance. The honest way to compare is to pick the size you expect to be in three years, cost both options at that size, and include the internal hours currently spent on workarounds. For a single commodity function, buying almost always wins that arithmetic. For a workflow you run at scale, it often does not.
Yes, and it is the path we recommend most often. Run the product until you can point at the specific thing it will not do, then build only that piece and connect it to what you already have. The one thing to check first is the export path, because a migration is only affordable if you can get history and attachments out in a usable format. Ask for that before you sign, not on the day you are leaving.
Often it is custom software with worse tooling. Once you are writing scripts, custom objects and plugin code inside somebody else's platform, you carry the maintenance burden of a build without a repository, a test suite or a straightforward way to roll a change back. It can still be the right call, because you keep the vendor's core and their patches. The point where it stops being right is the first upgrade that breaks your customisations and nobody can explain why.
That is the genuine risk of custom, and it is managed by handover rather than by hope. Insist on the source in your own repository, a written architecture note, the deploy pipeline, and a runbook covering restore and rollback. If a new team cannot get the system running locally from that documentation inside a day, the handover was theatre. We hand over on those terms, and you should hold any studio you hire to the same standard.
Because a build that should have been a subscription ends badly for both sides, and we would rather lose that project than run it. We work on both halves of this, including the Integrations and Custom API Development that joins a bought product to a built one, so the advice costs us nothing. The projects worth doing are the ones where no product exists for what you actually do. A second CRM is not one of them.
Have a project in mind?
Fixed price after a paid discovery — no hourly billing. A real engineer reads every enquiry, and we reply within 24 hours.