When to build custom software instead of adding another SaaS tool

Build when an important, repeatable requirement remains unsupported after a serious product evaluation, the process is stable enough to define, and someone can take responsibility for the application after launch.

Buying is often the better choice. The decision turns on whether employees can finish the work using the proposed product and connections, including corrections and exceptions.

Establish the reason for a build

A missing feature is worth investigating. It is not enough by itself to justify a custom application.

First check configuration, permissions, templates, and training. Then test products that already serve the process. A difference your team can accept is different from a rule the business cannot operate without.

Hold off on a substantial build if employees disagree about approvals or the process changes every week. A prototype or process review can settle those questions before they become expensive requirements.

Also name the owner after launch. Someone must prioritize changes, manage access, and arrange maintenance. That responsibility can sit internally or in a service agreement, but it cannot be left unanswered.

Use the revision that sends everyone back to email

Consider this fictional service business. Contractors submit completion details and photos for jobs with multiple sites. Operations approves each site, then sends approved billing information to finance.

The troublesome case is a correction to one site after another site has been approved. The earlier approval must remain valid for the unchanged submission. The corrected submission needs its own review, without creating a second payable item.

Buy and configure a portal

• What it covers: Accounts, submissions, photos, and supported approval rules.
• Test that changes the choice: Can a contractor revise one returned site while preserving its history?

Buy a portal and integrate it

• What it covers: The same submission experience plus transfer to other applications.
• Test that changes the choice: Can approved site information reach the correct destination record?

Buy a portal and build the missing review tool

• What it covers: Product accounts and uploads; custom site review and connections.
• Test that changes the choice: Can reviewers approve sites separately and send only the approved version?

Build the full application

• What it covers: Submission, review, and connections designed together.
• Test that changes the choice: Are the gaps substantial enough to justify owning the whole application?

A portal that treats every site as one submission may leave reviewers coordinating corrections by email. Connecting it to accounting would not supply the missing review screen.

But that gap may justify a small tool rather than a full portal. The existing product could still provide accounts and uploads.

Have the contractor and reviewer complete the task. Check missing photos, a returned submission, a post-approval correction, and a destination that stops responding. Record the steps that remain manual.

Product fit can change the recommendation

Itransition's footwear project used Odoo for ERP and B2B ordering after discovery found that configuration and customization could meet much of the need. Testing fit made a platform-based approach a serious option.

Cass & York's Horizon Roofing application brought pricing, approvals, quote revisions, history, and generated documents into custom software.

These projects illustrate different arrangements. For your decision, the evidence is whether the arrangement handles the requirement you need.

Compare complete arrangements over one period

Choose a comparison period before collecting prices. Compare “portal plus integration” with “portal plus review tool,” for example, rather than treating each component as an independent alternative.

Copy the worksheet below for each arrangement. Name the products and services it includes. Blank fields are information to collect, not zero costs.

Arrangement:
Comparison period:
People responsible for operating it:

Setup and implementation

• Amount or effort:
• Evidence or assumption: Quote, included work, and exclusions.

Development or customization

• Amount or effort:
• Evidence or assumption: Estimate and demonstrated requirement.

Source cleanup and migration

• Amount or effort:
• Evidence or assumption: Records, effort, and responsible person.

Subscription and usage charges

• Amount or effort:
• Evidence or assumption: Price basis, expected usage, and period.

Training and rollout

• Amount or effort:
• Evidence or assumption: Included users, work, and cost.

Hosting, monitoring, and support

• Amount or effort:
• Evidence or assumption: Coverage, charges, and responsibilities.

Staff work remaining

• Amount or effort:
• Evidence or assumption: Observed hours and tasks over the period.

Export, replacement, or handover

• Amount or effort:
• Evidence or assumption: Expected exit work and estimate basis.

Add each cash cost once. A package price may already include setup, hosting, or support; mark those inclusions instead of adding them again. Subscriptions shared by several components also need one treatment.

Keep observed staff hours separate from quoted cash costs. Hours released are capacity until an identifiable spending change makes them cash savings. Include effort moved into review or exception handling.

When estimates are uncertain, record the range and its basis. Compare the options under the same workload assumptions rather than giving the favored option an easier case.

Make sure you can change your mind

Ask whether you can export records with their identifiers and history. Check what another provider would need to take over: code, deployment access, documentation, licenses, and migration work.

Use the difficult transaction to choose the arrangement, the worksheet to compare its cost, and ownership requirements to judge whether the business can sustain it.

Cass & York develops integrations and internal tools and can assess a proposed build against the existing applications. Discuss the requirement driving your build decision.