Custom Software vs. Off-the-Shelf: When to Keep, Extend, or Replace Your Tools

TL;DR

• Give your current vendor and alternatives the same workflow to demonstrate, including corrections and exceptions. Separate essential requirements from preferences.
• Try configuration or a better-fitting product before commissioning a custom copy of software that already exists.
• An extension needs evidence that it can read the right records, perform the required actions and handle failures. Connecting two accounts is not enough.
• Compare setup, subscriptions, support and remaining manual work over the same period. Keep cash spending separate from the value of employees' time.
• Name who will operate the result and how another supplier could take over. Owning custom code does not remove every dependency.

Start with one workflow that the tools do not handle well

Off-the-shelf software is a product sold to multiple customers, with a shared set of capabilities and configuration options. Custom software is built for your particular requirements. A business can use both: keep its accounting product and build a job-management workflow around it, for example.

Before choosing, describe the work that needs to change. For example, suppose a service company uses a CRM, a scheduling tool and accounting software. Staff copy approved jobs between them and reconcile the weekly report manually. The complaint is "our systems don't talk to each other." The requirement is more specific: an approved job must reach scheduling with the correct customer and price, and a later cancellation must appear in the report.

Trace an ordinary job, a corrected job and a cancelled job using test data. Record who enters each fact, where it is copied, which record is trusted when values differ and how long the manual steps take. Include the exceptions that consume time, not just the successful path shown in a sales demo.

Separate essential outcomes from preferences. A branch manager seeing only their branch's records may be essential. Moving a button to a preferred position may not be. A candidate that cannot meet an essential requirement needs a workable remedy before its price becomes comparable.

Compare four options, not just buy versus build

Use the same workflow to assess all four routes. The table identifies what would support each choice; it does not diagnose a system from a symptom.

When keeping or switching is enough

Ask the current vendor to demonstrate the missing behaviour in the plan you would actually buy. Include the cost of any upgrade, setup or specialist configuration. Then give an alternative supplier the same test. A feature called "approvals" does not establish that it handles your approval rules.

Challenge the process too. If two people copy the same record because nobody agreed which system owns it, first agree that rule. If a supported report removes the manual export, configure it. Neither finding justifies commissioning a new platform.

In his AWS discussion of buy versus build, Gregor Hohpe distinguishes changing how systems support the business from building a near-copy of an available product. Apply that distinction to the proposal: what necessary capability would the custom work add that configuration or another product cannot provide?

When an extension is enough

Consider an extension when the current tools can remain responsible for their main jobs. In the service-company example, the missing part might be transferring approved jobs and reconciling later changes. It does not follow that the company needs to rebuild contact management or accounting.

Ask for a small technical demonstration using the actual interfaces available to your account. Can it read the required records and stable identifiers? Can it create and correct the destination record? What happens when one service is unavailable or the same transfer is attempted again? Check the required account permissions and any plan or usage limits before accepting the estimate.

Also define what the data means. If "completed" means work finished in scheduling but invoice paid in accounting, copying that status unchanged is incorrect. Microsoft's adapter-layer guidance describes translating between systems with different meanings. It also identifies the added maintenance, latency and data-consistency work. An extension needs that work priced; it is not free infrastructure between two subscriptions.

A Caemcore example illustrates the data problem. A group with six restaurant brands in two countries had information spread across a POS system, spreadsheets, Looker Studio and a mystery-shopper service. Its finance specialist combined figures manually. We brought the information into one system with access based on each person's role. That is a concrete change in how people access information, not a measured claim about hours saved or financial return.

Compare the cost of running the same outcome

Choose a planning period and use it consistently. Record implementation, data preparation, testing, training and transition costs once. Then add the subscriptions, hosting, support and remaining manual work needed to operate each option over that period. List services that stay after the change, including a platform you still need for one retained function.

Keep two views. The technology cash budget contains supplier bills and other actual technology spending. The cost comparison including employee time adds the value assigned to manual work. Your payroll budget still needs funding; converting hours to dollars does not make those dollars available to pay a developer.

Include internal project time as well. Hohpe's earlier AWS analysis highlights the opportunity cost of assigning developers to a build instead of other work. The same question belongs in your review: what will the people supporting this change postpone?

Worked example: four ways to support the same process

Hypothetical example. Every amount and time estimate below is invented to explain the calculation. These are not supplier quotes, Caemcore prices or client results.

Suppose all four options meet the service company's essential job-handling and reporting requirements at the same volume. The retained process meets them with more manual work. Each option is assumed to launch on the same date; the comparison covers 24 months after launch, with setup and transition added once. No option is credited with extra revenue.

One-time costs include the required setup or development, data work, testing, training and handover, plus costs before launch. Monthly technical support is external spending, separate from employees' manual processing time. For the illustration, that time is valued at $30 per hour. The model holds prices and volume constant. It excludes internal implementation time, tax, financing and optional future features; add any differing internal project effort to a real comparison.

The extension's combined cost is $12,000 + 24 × ($850 + $300 + 8 × $30) = $45,360. Its technology cash subtotal excludes employee time: $12,000 + 24 × ($850 + $300) = $39,600.

On these assumptions, keeping the tools requires the least technology cash. The extension has the lowest combined cost, but its advantage over switching is only $2,880 across two years. An additional $120 per month of extension support would remove that advantage. The full replacement costs more than either route; it needs a reason beyond avoiding subscription fees.

Now test whether the time difference is useful. Releasing 52 hours a month from manual processing could create capacity for other work. It does not automatically reduce salaries. Record whether those hours avoid paid overtime, defer hiring or enable a specific task; do not count the same benefit twice as both cash savings and extra output.

For real proposals, vary the assumptions that could change the decision: paid user seats, transaction volume, residual manual hours and support effort. Account for different launch dates and the cost of operating the old process while waiting. A small advantage that disappears under a plausible support estimate is a reason to investigate, not a confident verdict.

What would justify replacing the system?

Replacement deserves a proposal when an essential requirement is blocked and the smaller alternatives cannot remove the blocker at acceptable cost and risk. Name that requirement. "We want control" is incomplete; "we need to introduce a new approval rule without waiting for the vendor's roadmap" can be investigated.

Test the limit rather than inferring it from the number of services you use. More users might change a subscription bill without changing functional fit. Several integrations might be simple exports, or one might coordinate changes in both directions with difficult recovery rules. Hours spent correcting inconsistent data may point to unclear definitions rather than inadequate software. These measures are inputs to the decision, not universal thresholds for building.

Ask the replacement proposal to show what becomes possible, which existing capabilities remain and which are deliberately removed. A lower licence bill is not a benefit if the new scope quietly excludes a report, control or integration the business still needs.

Do not approve a full replacement while the underlying process is undecided, the relevant platform capability has not been tested or nobody can fund ongoing operation. Settle the missing evidence first. A custom implementation cannot choose the business's approval rules on its behalf.

Custom software still needs an operating owner

Buying a subscription does not transfer every security task to the vendor. Microsoft's shared-responsibility guidance retains customer responsibilities for data, configuration and user access across cloud service models. Establish who manages those tasks for the product you choose rather than assuming the subscription covers them all.

For a custom system, also name who monitors failures, maintains dependencies, tests updates, restores backups and helps users when work stops. Managed hosting may cover part of that scope. Ask what is included and what still belongs to your team or development partner.

Code ownership alone is not an exit plan. Hohpe's buy-versus-build analysis also warns about dependence on your own implementation and the people who understand it. Request repository and infrastructure access, setup instructions, data-export procedures and a handover that another developer can follow. For a purchased product, test the exports and administration access needed to leave it. Compare practical ability to change suppliers, not just a promise of "no lock-in."

Replace in stages only when the boundary works

A replacement does not have to switch every function at once. Microsoft's incremental-replacement guidance describes moving functions while the old system continues to operate. It also names limits: requests must be redirectable, shared data needs a plan, and maintaining a transition may be unnecessary for a small system that is straightforward to replace.

For a business using a vendor platform, do not assume you can change its internals. Identify a workflow that can genuinely move independently. State which system accepts new records during the transition, how corrections reach the other version and what happens to new data if the switch is reversed. Keep the existing workflow available until the agreed reconciliation and recovery checks pass.

When the existing system is an AI-built or no-code app rather than a purchased business platform, our guide to fixing or rebuilding an AI-built app covers the separate question of how much of its implementation needs replacing.

Write the decision down before commissioning the work

Use this short decision brief for the current vendor, a competing product and a developer. Fill it with evidence from the same workflow, not a different wish list for each supplier.

1. Required outcome. Who must do what, which exceptions matter and what must remain unchanged?
2. Options tested. What did configuration, switching, extending and replacing each demonstrate? Mark untested claims as unresolved.
3. Comparable cost. What are the setup costs, recurring bills and remaining manual hours? Which assumptions could change the preferred option?
4. Responsibility and exit. Who operates the result, what happens when it fails and how could another supplier take over?
5. Next commitment. Which bounded step resolves the remaining uncertainty, and what result would justify proceeding?

A good next step might be a configuration change, a trial of another product or a limited integration test. Commit to a replacement when the evidence supports that scope, not because replacing everything makes the proposal easier to describe.

About Caemcore

Caemcore builds custom software for companies that outgrew off-the-shelf tools.

Internal systems, integrations, web and mobile apps, and products built from scratch. Small senior team, Warsaw-based, working with clients across the EU, US and UK.

You get a price range and a timeline before development starts, a working demo every Thursday, and a final invoice that matches the number quoted on day one.

Not sure what you need? A 30-minute call, free: what the task actually is, whether it needs building or an off-the-shelf tool covers it, a range and a timeline. You get that whether we work together or not.

FAQ

Should we wait for a feature on the vendor's roadmap?

Treat it as an option with an unresolved dependency. Ask what is committed, which plan will include it and whether you can test it before your business deadline. Keep a fallback for the period before delivery. A proposed feature is not current functionality, so do not mark the requirement as passed just because it appears in a presentation.

Can we use no-code for the custom part?

Evaluate a no-code extension against the same workflow and operating requirements as a coded one. Demonstrate permissions, corrections, failed transfers and export of the records you need. Include its subscription and a named maintainer in the estimate. The method used to build the extension does not, by itself, establish whether it is suitable for long-term use.

Do we need to migrate every historical record?

Define which records the new workflow needs and which can remain in an accessible archive. Test the relationships you must preserve, such as a customer linked to an old job and its invoice. Confirm the business's retention requirements before excluding data, and price archive access separately. Moving only active records is a scope decision, not permission to lose the rest.

What if a supplier will only quote after discovery?

Ask for a bounded discovery proposal with a price, an end point and written outputs: the demonstrated gap, viable options, assumptions and implementation scope. Confirm what evidence and documents you receive even if another team does the build. Discovery is useful when it resolves a named uncertainty; an open-ended series of meetings is harder to evaluate.

How should we review the decision after launch?

Return to the original baseline after a representative operating cycle. Compare actual bills, support effort, manual hours, exceptions and time to complete the workflow with the assumptions in the decision. Record what employees do with the time released. If an assumption was wrong, adjust the workflow or scope before treating further development as the automatic next step.

Sources

• Gregor Hohpe / AWS, Buy vs. Build Revisited, Part 2: Drawing the Line. Published 10 September 2020. Checked 12 September 2026.
• Microsoft Azure Architecture Center, Anti-Corruption Layer pattern. Checked 12 September 2026.
• Gregor Hohpe / AWS, Buy vs. Build Revisited: 3 Traps to Avoid. Published 29 July 2020. Checked 12 September 2026.
• Microsoft Learn, Shared responsibility in the cloud. Checked 12 September 2026.
• Microsoft Azure Architecture Center, Strangler Fig pattern. Checked 12 September 2026.

The Caemcore project example is based on our own project records. The worked cost comparison uses disclosed hypothetical assumptions, not market averages or measured client results.