blog single

Buy, build or automate: choosing the right response

Product team comparing a vendor demo with an internal build

Published on:

May 15, 2025

TAG:

SOFTWARE DEVELOPMENT

BY:

Edgeless Team

Read Time:

6 MIN READ

post detail

When a process stops working, three responses appear in the first meeting. Buy a product, build something custom or automate the manual steps. Each has a strong case and a hidden cost. The mistake is choosing by instinct, because the right answer depends on how unusual the process is and how much of it is a source of advantage.

Three options, three different risks

Buying transfers maintenance and feature development to a vendor, but it also transfers control. You inherit their roadmap and their idea of the process. Building keeps control and fits the process, but the business owns every bug and every upgrade. Automation removes repetitive steps without replacing the system, and it works best when the process itself is sound.

The risks differ in when they appear. A purchase shows its limits during the first busy season, when a needed field is missing. A build shows its cost during the second year, when the original team has moved on. Automation shows its fragility when an input changes format and the script fails without an alert.

Write down which risk the business can absorb. A company with strong technical staff can carry a build. A company without them should be careful about owning software. A company with a stable, well documented process can automate with confidence. A company whose process changes every quarter should not automate the current version.

When buying wins

Buying wins when the need is common and the vendor is healthy. Payroll, accounting, email, basic customer relationship management and help desk software encode practices shared by thousands of businesses. The vendor learns from all of them, and that learning is part of what you pay for.

It also wins when the process is a commodity. Nobody chooses a supplier because of the way it files invoices. Spending custom development on a commodity process takes attention away from the work customers actually notice.

Check the vendor's health before the feature list. How long has it operated, how often does it ship, what do customers say about support and what does the export look like. A product that is cheap today and abandoned next year is not cheap, and a product with no export path is a future migration project.

When building wins

Building wins when the process is a real advantage and the existing tools force a workaround that costs more than the software. A scheduling model that matches how your crews actually work, a quoting flow that encodes your pricing rules, a portal that removes a recurring support call. Those are places where the fit matters to customers or to margin.

It also wins when the integration between three products is the real problem. Sometimes the business does not need a new system. It needs one place where the three systems agree, with a clear owner and an audit trail. That can be a smaller build than replacing all three.

The process is a source of advantage, not a commodity.
Existing tools require workarounds that cost real hours each week.
The data model is stable enough to design once.
The business can own maintenance or fund a partner to do it.
The integration between systems is the actual pain.
A first release can be small and still useful.

Automation is the third path

Automation is often the cheapest useful response. Moving a file, renaming a document, creating a record from an email, sending a reminder. These steps are repetitive, rule based and easy to describe. A small script or a workflow tool can remove hours a week without replacing the system of record.

The catch is that automation amplifies whatever the process already does. If the process has an exception that a person handles by judgement, the automation will either break on it or quietly do the wrong thing. Map the exceptions before automating, and keep a manual path for the cases the rules do not cover.

Build monitoring into every automation. A script that fails silently is worse than a manual step, because nobody notices until a customer does. Log the runs, alert on failures and record the last successful run in a place the team can see.

Team mapping manual steps before automating them — Automation works on a process that is already understood. The map comes before the script.

Compare total cost over five years

Add the subscription, the implementation, the integration work, the training, the internal administration and the cost of the workarounds that remain. For a build, add the initial delivery, the maintenance, the hosting, the support and the cost of the next major change. For automation, add the scripts, the monitoring and the time to fix them when an input changes.

Put the numbers in the same units. A monthly subscription multiplied by sixty is easier to compare with a build estimate than a monthly figure against a total. Include the staff time honestly, because internal time is a real cost even when it does not appear on an invoice.

Add the cost of delay. A product that can be live in three weeks may beat a build that takes six months, even if the build is cheaper over five years. The value of solving the problem earlier belongs in the comparison.

The decision in practice

Start with the process, not the technology. Document the steps, the exceptions and the people involved. Then ask which option removes the most work for the least ongoing obligation. A purchase that requires a full time administrator is not a purchase with no maintenance. A build that needs a specialist to change a price is not a build with no dependency.

Run a small test before committing. A vendor trial with real data, a two week automation of one step or a prototype of the core workflow. Each test produces evidence about fit that a proposal cannot.

The right answer is the one the business can operate for five years. A plan that looks best in the first month often costs more by year three.
Edgeless Team

Name the process owner

Every option needs a person who owns the process after the project ends. A purchase without an owner becomes a tool nobody administers. A build without an owner becomes a codebase nobody updates. Automation without an owner becomes a script that fails quietly and is discovered by a customer.

Choose the owner before the option. If the business cannot name anyone who will maintain the result, the option that needs the least maintenance is the better choice, even if it fits the process less closely.

Give the owner time in the plan. Administration, review and small changes need hours in the calendar, not a sentence in a job description. A half day a month is enough for many small systems and it prevents the drift that makes a good choice fail in year two.

A staged decision

When the answer is still unclear, stage the decision. Buy or automate the first step, measure what happens and use the evidence to decide about the rest. A staged decision costs less than a wrong commitment and often produces a better final choice because it is based on real use.

Set the review date at the start. A staged decision without a date becomes a permanent compromise. Put the review in the calendar with the numbers to check and the people who need to attend.

We help teams compare buy, build and automate options with a five year cost model and a first release that tests the riskiest assumption.

Explore software development

Write the decision down with the reasoning. When the process changes in two years, the record explains why the current system exists and what would need to be true to change it.

Buy vs Build

Automation

Operations

Buy, build or automate: choosing the right response

Let's Talk About Your Project