Custom Software vs Off the Shelf: A Buyer's Decision Framework

Buy off the shelf, unless the thing you are automating is how you compete. That one rule resolves most of the custom software vs off the shelf question before anyone books a discovery call, and it points at buying far more often than an agency blog usually admits.

Our bias runs the same way. Talking someone out of a build they do not need is cheaper for them and less painful for us than delivering a bespoke system a product could have handled for a subscription. What follows is the set of questions we use to get there, in the order we ask them. The same fork appears one level down when the thing in question is a website rather than a back-office system, and we wrote that one up as AI website builder versus professional website development.

The short version

Software you buy is cheap because the vendor spreads the cost of building it, maintaining it, securing it and supporting it across every other customer. You are renting a share of an engineering team. For anything that is merely plumbing, that is an excellent deal and you will not beat it.

Software you build is expensive because you fund all of that yourself. It is worth funding when the process encodes something a competitor cannot copy off a pricing page, or when the product you would otherwise buy has stopped fitting badly enough that the workarounds cost more than a build would.

Everything else is detail. Here is the detail.

Six questions that settle custom software vs off the shelf

Answer these honestly, in writing, before you speak to a vendor of either kind. Most teams find the answer emerges around question three.

1. Is this process how you win, or just how you operate?

Payroll is not a differentiator. Neither is expense approval, holiday booking, invoicing your own suppliers, or storing documents. Thousands of companies have solved those and you will not beat them by starting now. We publish a free invoice generator for exactly that reason: the job is a commodity, and nobody should be commissioning a bespoke version of it.

The processes worth building are the ones a competitor would have to reverse-engineer. The pricing logic only you understand. The way work gets routed to the right person. The scoring model your margin depends on.

A useful test: if you described the process to someone else in your industry, would they nod because everyone does it that way, or would they want to know how you do it? Nodding means buy.

2. How many other systems does it have to talk to?

Integration load is the most reliably underestimated cost in this decision, and it cuts both ways.

Bought products come with connectors for the popular systems and nothing for the unpopular ones. If your stack is mainstream, that is a large saving handed to you for free. If you run anything unusual, or an older system with no public API, you will end up paying for middleware, a connector subscription, or a developer writing the integration anyway. That quietly funds part of a custom build without any of the benefits of one.

Count the systems. For each, write down whether the product has a supported integration, an API you would have to write against, or nothing at all. Three entries in the "nothing" column and the economics start moving.

3. What does the licence cost look like at the headcount you expect?

Most business software is sold per user per month. Salesforce, to take the obvious example, publishes its Sales Cloud editions as a per-user, per-month price billed annually. That model is comfortable at ten seats and a serious line item at two hundred. Check current pricing yourself rather than trusting any figure in an article, including this one.

Do the arithmetic over the horizon you actually plan for, not just this year:

annual licence cost = seats x price per seat per month x 12

three-year cost = licence cost for years 1, 2 and 3 at projected seat growth
                + implementation and data migration
                + per-transaction or per-record fees
                + the higher tier you get pushed onto for the one feature you need

That last line catches people. Feature gating means the capability you require is rarely in the tier you first priced. Find out which tier contains it before you model anything.

Then compare that number with a build plus its running costs over the same three years. Sometimes the subscription still wins comfortably and the conversation is over. Sometimes it does not, and the answer is still not automatically "build", because seat count is only one input.

4. Where does configuration stop and code begin?

Every product has a configuration ceiling. Custom fields, workflow rules, templates, permissions: all of it bends until it does not. The failure mode is not hitting the ceiling. It is hitting it quietly and then building around it.

Signs a bought product has already stopped fitting:

• People export to a spreadsheet to do the actual work, then paste the results back in
• A field named something like notes_2 is holding structured data
• Someone maintains a document explaining which fields to ignore
• A part-time contractor keeps the scripts that patch the gaps
• Training a new starter on the workarounds takes longer than the work itself

Those workarounds have a salary cost and an error rate, and they never appear in a cost comparison because nobody invoices for them. If three or more are true today, you are already paying for custom software. You are just paying for it in the worst available form.

5. How do you get out, and what does leaving cost?

Ask every vendor three questions and write the answers down.

Can you export your complete data set, including history and attachments, in a structured format rather than a report? Does the API expose everything the interface shows, or only the parts the vendor found interesting? What happens to your data when the contract ends, and how long do you have to collect it?

Vague answers are themselves the answer. The cost of leaving is proportional to how much of your business logic lives inside the product, and if that logic can only be read through their screens, migrating means reconstructing it from observation.

Custom software has its own version of this problem and it deserves naming rather than glossing. If the code is undocumented, depends on one person, or is written against a framework nobody else uses, you have swapped vendor lock-in for supplier lock-in. The protections are partly contractual and partly technical: own the repository and the intellectual property outright, insist on a stack with a large hiring pool, and make documentation a deliverable rather than a favour.

6. Who maintains it on a Tuesday in three years?

Bought software is maintained by the vendor. Security patches, browser changes, compliance updates, all handled by people whose job that is. Most of your subscription pays for this and it is genuinely valuable.

Custom software is maintained by whoever you arrange. Dependencies need updating, certificates expire, a payment provider changes an API, and someone has to answer when a user says a button stopped working.

If your plan for that is "the agency who built it, probably", the build is not scoped yet. This question kills more speculative builds than any other, and it should. A system with no named maintenance owner degrades into a liability within about two years.

The total cost nobody quotes you

Both options carry costs that sit outside the quote. This is the honest shape of them.

The last row is the one to internalise. Subscription cost scales with how many people use the thing. Custom cost scales with how complicated the thing is. A small team with a complicated process and a large team with a simple process point in opposite directions, and that single observation often settles the decision.

The hybrid answer most comparisons skip

Treating this as one choice for the whole business is the mistake underneath most articles on the subject. Almost nobody should build everything, and almost nobody should buy everything either.

Buy the commodity. Accounting, payroll, email, helpdesk, document storage, calendars. You are not going to out-engineer those categories and there is no prize for trying.

Build the differentiator. The one workflow that is genuinely yours, wired into the bought systems through their APIs. It is a far smaller build than a full platform, it ships sooner, and it leaves the compliance-heavy plumbing with vendors who are paid to keep up with it.

The risk does not disappear, it moves. In a hybrid stack your exposure sits in the integrations rather than the features, so the diligence changes shape: every bought product in the chain needs a documented API, a sane rate limit and a real export path. Confirm those before you design anything, not after.

What that looks like in practice

Where a bespoke build is doing real work, the pattern holds. HisaabKar is a multi-tenant invoicing platform where the accounting behaviour is the product: payments allocate to the oldest outstanding invoices first and carry any remainder as credit, stock is costed FIFO and reconciled on every invoice edit, and the same invoice renders in English or Urdu with a full right-to-left layout. None of that is a checkbox in a generic invoicing tool. It is the reason the product exists at all.

GeoTagImg is the same argument in a different shape. Image metadata is written in the visitor's browser rather than on a server, and admins change daily limits, coupons and analytics IDs from a backend panel instead of waiting for a redeploy. Neither of those is a setting you can buy. Both builds are written up in full in our case studies.

That is the test in one sentence. If you removed the custom part, would the thing still have a reason to exist? For HisaabKar, no. For a company that wants its own holiday booking form, yes, obviously, and they should go and buy one.

If you sit somewhere in between, the useful next step is scoping the smallest version of the differentiating piece. Our custom software work starts there deliberately, because a narrow first build tells you whether the idea survives contact with your own team before the full budget is gone. If that narrow first build already exists as an AI-generated prototype, the question shifts to what has to be rebuilt before it can carry real users. The broader software development service covers the part after that, when the thing has to keep working.

The decision rule

Buy it if the process is plumbing, your stack is mainstream, your headcount is modest and configuration still fits.

Build it if the process is your edge, or if you are already paying for custom software in spreadsheets and workarounds while getting none of the benefits.

Do both if you can be honest about which parts are which. For most businesses, that is the answer.

If you are still unsure, the cheapest experiment is to buy the closest product for a year and document precisely where it hurts. That document is the best scoping brief a development agency will ever receive, and it costs a subscription instead of a project.

The same instinct applies once you are building. We wrote the honest case against headless WordPress for exactly this reason: the expensive option is easy to justify in theory and much harder to live with afterwards.