Buying an existing tool is often the fastest and safest option. Custom software becomes more reasonable when the workflow is genuinely important, available products create material constraints, and the organisation is prepared to own a product after launch.

The decision should compare the full operating model, not a vendor subscription against an initial development estimate.

Define the essential workflow

Describe the users, trigger, information, rules, decisions, outputs, exceptions, and handoffs. Separate essential requirements from preferences inherited from the current process.

Ask whether the workflow is differentiating. If it is common—such as basic accounting, email, document storage, or standard customer records—a mature product may solve it better than a custom build. Custom work is easier to justify when the organisation’s method creates real value and cannot be represented responsibly in available tools.

Evaluate off-the-shelf options honestly

Create representative scenarios and test them in the product. Do not evaluate only the marketing page or feature checklist.

Review:

  • fit for the core workflow;
  • permissions and audit needs;
  • integration and export options;
  • data location, retention, and deletion;
  • accessibility and user experience;
  • configuration limits;
  • vendor support and service history;
  • pricing as usage grows;
  • contract and exit terms; and
  • the cost of adapting internal processes.

Changing a low-value internal process to fit a reliable product can be sensible. Changing a critical or regulated process to fit a weak constraint may not be.

Calculate total ownership cost

Buying may include

  • subscription and usage fees;
  • setup and migration;
  • configuration or consultancy;
  • integrations;
  • training and change management;
  • premium support;
  • data export or exit work; and
  • future price changes.

Building may include

  • discovery and product design;
  • engineering and quality assurance;
  • infrastructure and third-party services;
  • security review;
  • migration;
  • documentation and training;
  • monitoring and support;
  • maintenance and dependency updates;
  • future feature work; and
  • staff needed to own decisions.

Compare costs over a realistic period and include uncertainty. A custom product is not “finished” at launch.

Consider a configured or hybrid path

The choice is not always pure buy or build. A team may configure an existing platform, connect several systems, add a small custom service, or build a focused interface over reliable infrastructure.

A hybrid approach can reduce custom surface area while preserving the workflow that matters. It can also create new dependency and integration risks, so data ownership and failure behaviour still need to be clear.

Review integration and data ownership

List every system that creates, reads, or changes important records. Decide which system is authoritative, how conflicts are resolved, what happens during downtime, and how changes are audited.

Confirm that data can be exported in a usable format. Vendor lock-in is not only a contract issue; it can arise from proprietary workflows, inaccessible history, or undocumented integration logic.

Match risk to operational capacity

Custom software gives control and responsibility at the same time. The organisation needs owners for priorities, access, security, incidents, support, and future changes.

If no one can own the product after the delivery team leaves, buying a supported tool may be safer. If vendor constraints create unacceptable risk or prevent a critical capability, ownership of a custom system may be worth the investment.

Use a weighted decision record

Score each realistic option against agreed criteria. Weight the criteria before the team sees preferred vendor results or estimates.

Possible criteria include:

  • essential workflow fit;
  • time to useful deployment;
  • five-year cost range;
  • integration effort;
  • data and security requirements;
  • accessibility;
  • scalability;
  • vendor dependence;
  • internal ownership capacity; and
  • reversibility.

Record the evidence, assumptions, unknowns, and decision date. That record makes the trade-off reviewable when circumstances change.

Signs that buying may be better

  • The workflow is standard and mature products fit it.
  • Speed matters more than differentiation.
  • The organisation has limited product ownership capacity.
  • Compliance, reliability, or support would be expensive to reproduce.
  • Configuration can solve the essential need without harmful compromise.

Signs that custom work deserves investigation

  • The workflow is central to how the organisation creates value.
  • Available products fail essential requirements after representative testing.
  • Integration or data ownership constraints are material.
  • The organisation can fund ongoing ownership, not only launch.
  • A bounded custom component can solve the gap without rebuilding commodity functions.

The correct outcome of discovery may still be to buy. Good technical planning reduces unnecessary custom code as readily as it identifies where custom development is justified.

Compare options with a concrete scenario

Consider a hypothetical membership organisation that needs applications, renewals, payment status, document review, and member communication. One available platform handles the standard records and permissions but cannot represent a specialised approval step. A fully custom rebuild would reproduce authentication, billing, audit history, and administration before addressing the distinctive workflow.

The realistic options are not only “accept the product” or “build everything”:

  1. change the approval process to fit the platform;
  2. configure the platform and handle the exception manually;
  3. integrate a small custom approval service while keeping the platform as the system of record;
  4. select a different product; or
  5. build a custom system if the workflow, control, and long-term economics justify ownership.

The decision record should show which requirement is essential, how often the exception occurs, the consequence of delay/error, integration constraints, five-year cost ranges, exit options, and who can operate each choice. This scenario is illustrative and does not represent a Boolean Nepal client or result.

Run a proof before a large commitment

For a product, configure representative users, permissions, records, integrations, exports, and exceptions in a trial or sandbox. For a custom path, prototype the highest-risk workflow or integration rather than the easiest screen.

Define what the proof must answer, how long it will run, which costs are included, and what evidence would reject the option. A proof that cannot fail is a demonstration, not a decision test.

Common failure modes

Comparing first-year invoices only

Implementation, migration, licences, integration, support, upgrades, staff time, and exit work can outweigh the headline price. Compare a realistic ownership period and uncertainty range.

Rebuilding commodity functions

Authentication, billing, file storage, notifications, permissions, and reporting carry operational and security responsibility. Build them only when their custom behaviour creates necessary value.

Assuming integration is simple

An advertised API does not guarantee the required fields, rate, history, event model, permissions, or reliability. Test the exact data flow and failure/recovery behaviour.

Ignoring migration and exit

The decision is incomplete without data cleaning, mapping, reconciliation, cutover, rollback, export, and deletion. Ask how the organisation leaves before it enters.

Treating custom software as a one-time project

Security fixes, dependency updates, user support, monitoring, backups, provider changes, and new operating requirements continue after launch. Assign budget and ownership.

Next-step checklist

  1. Map the essential workflow and exceptions.
  2. Separate differentiating requirements from preferences.
  3. Test at least two realistic products where available.
  4. Confirm data ownership, export, deletion, and authoritative systems.
  5. Verify the exact integrations and downtime behaviour.
  6. Estimate total cost and internal effort over a realistic period.
  7. Review security, privacy, accessibility, and contractual obligations.
  8. Identify the long-term product and operational owner.
  9. Test the riskiest assumption with representative users/data.
  10. Record the decision, rejected alternatives, assumptions, and review date.

If neither path has an accountable owner, the priority is operating ownership—not procurement or development.

Primary reference