Off-the-Shelf or Custom Build? How to Decide

The build-or-buy conversation usually starts in the wrong place. Someone demos a product, it does most of what is needed, and the discussion becomes whether the missing twenty percent is worth building around. That framing hides the decision that actually matters.

The useful question is not which option is cheaper. It is which option you can live with for the next five years, given how your business is likely to change.

Buy when the process is not yours to invent

Some processes are effectively standardised. Accounting follows rules you do not set. Email works a particular way. Payroll has statutory requirements that are the same for you as for everyone else in your jurisdiction. Video calls are video calls.

Building your own version of a standardised process is almost always a mistake. You take on maintenance for something that gives you no advantage, and every regulatory or protocol change becomes your problem instead of a vendor's.

The tell is simple: if a competitor could use the identical process and nothing about your business would change, buy it.

Build when the process is the business

The opposite case is the process that is genuinely yours: the way you price, the way you route work, the sequence your operations follow because of a constraint specific to you. Forcing that into a product designed around someone else's assumptions has a cost, and the cost is usually paid in workarounds.

Watch for the spreadsheet that sits beside the system. When a team buys a tool and then maintains a parallel spreadsheet to make it usable, the tool did not fit the process. That spreadsheet is a requirements document nobody wrote on purpose.

The costs nobody puts in the comparison

On the buy side

• Per-seat pricing as you grow. A price that is comfortable at 20 users is a different conversation at 200. Model it at the size you expect to be, not the size you are.
• Configuration is not free. Enterprise tools often need weeks of setup, and sometimes a certified consultant. That is a real project cost even though it appears under a different heading.
• Integration work. The tool has to talk to everything else you run. If it does not, you have bought a data silo.
• Getting your data back out. Check the export path before you sign, not when you are leaving. This is the cost that turns a reversible decision into an irreversible one.
• Roadmap risk. The feature you depend on is on someone else's roadmap, and so is the feature that might get deprecated.

On the build side

• Maintenance never ends. The build is the smaller number. Dependencies age, browsers change, requirements shift. Budget for the years after launch or the system quietly rots.
• You own the edge cases. Everything a mature product learned from thousands of customers, you will learn one incident at a time.
• Time to first value. A purchased tool can be live next week. A build cannot. If the problem is on fire, that difference may decide it.
• Key-person risk. Custom systems concentrate knowledge. Insist on documentation and more than one person who understands it.

The middle path most businesses actually need

Framing this as a binary is what makes it hard. In practice the answer is usually a mix: buy the standard pieces, build the part that is genuinely yours, and integrate them properly.

A common shape looks like this. Buy the accounting system, because accounting rules are not yours. Buy the communication platform, because telephony is a solved problem. Build the operational layer in the middle that reflects how your business actually runs, and connect it to both.

This is where integration stops being a technical detail and becomes the strategy. The value is not in any one system, it is in the fact that they share data instead of each holding a partial version of the truth.

A short decision test

Answer these before deciding:

• Would a competitor running this exact process be at any disadvantage? If no, buy.
• Has the team already built workarounds around an existing tool? If yes, the process does not fit the product.
• What does this cost at three times your current headcount?
• If the vendor doubled the price or discontinued the product, what would you do?
• Who maintains it in year three, and is that person in the plan?
• What has to be true for this to still be the right answer in five years?

Where low-code sits

Low-code platforms are often presented as the answer that ends the argument: the flexibility of a build without the cost. Sometimes that is true. It is worth being clear about what you are actually trading.

What you gain is speed to a working internal tool, and the ability for someone outside the engineering team to change it. For internal workflows with a handful of users and no severe performance requirements, that is a genuinely good fit and often the correct answer.

What you trade is portability and ceiling. The logic lives inside the platform in a form that does not transfer anywhere else, so switching later means rebuilding rather than migrating. Pricing usually scales with users or automation runs, which is fine at ten users and worth modelling at two hundred. And there is a complexity ceiling: past a certain point you end up doing genuine programming in an environment that is worse at it than a normal codebase.

A reasonable rule: low-code for internal tools where the process is still changing shape, conventional development for anything customer facing, performance sensitive, or central enough that being unable to leave the platform would be a strategic problem.

A worked example

A services business with about forty staff needs to quote jobs, schedule technicians, and invoice. Three obvious options.

Buy a single industry platform. Live quickly, one vendor, and the scheduling logic is built around an industry norm. If their norm matches yours, this is the best answer available and the conversation should end here.

Build everything. Perfect fit, and now you maintain quoting, scheduling, and invoicing forever, including the invoicing rules that are not yours to invent. Rarely worth it.

Split it. Buy the accounting and invoicing, because those rules are external. Build the scheduling layer, because the way this business allocates technicians is its actual operating advantage. Integrate the two so a completed job produces an invoice without anyone re-typing it.

The third option is usually right, and it is usually the one nobody costed, because build-or-buy was framed as a single decision about a single system rather than a decision per capability.

One thing to do before either

Map the process first. Buying and building are both ways of encoding a process into software, and encoding a broken process is expensive in either direction. The most common failure we see is a tool purchased to solve a process problem, where the process problem is still there afterwards with a subscription attached to it.

If mapping reveals that the process should be simpler, that is the cheapest finding available. Sometimes the correct answer to build or buy is neither.

Yoddha Lab does both sides of this from Kathmandu, Nepal: custom software development, and business process reengineering that maps the process before anything is bought or built. We also operate our own products, so we have paid the maintenance cost on the build side ourselves. See our services, or read how to scope a project before asking for a quote.