Build, Buy or Automate Around It? A Practical Technology Decision Framework for SMEs

Your team needs a better way to manage work. One vendor recommends a subscription platform. A developer proposes a custom system. Someone else suggests connecting the tools you already use. All three may be reasonable. They solve different kinds of problems.

I would start by writing down the outcome the business needs and the conditions the solution must meet. Once those are clear, the technology decision becomes much easier to explain and test.

For a Singapore SME with limited time and a small operations team, the best option also needs a realistic owner after launch. A solution that nobody can support is an unfinished decision.

Understand the three routes

Buy means adopting an existing product and configuring it for your business. This often suits established needs such as accounting, standard customer management or appointment scheduling, provided the product handles your actual requirements.

Build means creating software for a specific need. It can make sense when a valuable workflow has requirements that available products cannot reasonably meet. You also take responsibility for maintenance, security updates, testing and future changes.

Automate around it means keeping useful systems and connecting selected steps between them. For example, an approved request might create a job record and notify the assigned person. This works best when the underlying systems are reliable and support suitable integration methods.

These routes can be combined. You might buy a standard accounting package, automate the transfer of approved invoice details and build a small tool for a specialised calculation. The decision can be made by workflow rather than for the whole company at once.

First write a problem statement

“We need a new system” is too broad. Try: “Our coordinators re-enter confirmed bookings into two trackers, and technicians sometimes receive outdated instructions. We need one current job record and a reliable handover.”

Add the volume of work, the people involved, the current failure and the outcome you will measure. If the process itself is unclear, simplify it before requesting quotations. Otherwise each supplier will price a different interpretation of the problem.

Use five questions to narrow the choice

1. Is this a common business need? Test suitable existing products first when the need is well established. Ask whether changing a minor internal preference would be easier than maintaining custom software for years.
2. Which requirements are essential? Separate must-haves from preferences. An approval limit or a required export format may be essential; matching the colour of the current spreadsheet probably is not. Reject any route that fails an essential requirement before comparing scores or prices.
3. Can the current systems be connected reliably? Check available integrations, access permissions, usage limits and supported data fields. A connection that depends on copying from a changing screen may require more upkeep than one using a supported interface. Include monitoring and recovery in the proposal.
4. Who will own it after launch? Name the business owner and the support provider. Agree who handles user changes, failed jobs, backups, security updates and supplier queries. Outsourcing delivery does not remove the need for someone inside the business to accept the work and manage priorities.
5. What happens if the choice is wrong? Check how to export usable data, end the agreement and continue operating during a transition. For a custom build, confirm ownership or licence rights, access to source code, documentation and deployment accounts.

Compare the full cost over the same period

Use a consistent planning horizon, such as 24 months. Include discovery, configuration or development, migration, integration, subscriptions, staff training, support and eventual exit. Record uncertainty rather than accepting one precise-looking total.

Here is a simplified illustration in SGD, not a market quotation. A purchased product could cost S$2,000 to set up plus S$250 a month: S$8,000 over 24 months. An automation could cost S$4,000 to implement plus S$180 a month: S$8,320. A custom build could cost S$12,000 plus S$300 a month for support: S$19,200.

Those arithmetic totals exclude items such as internal staff time, taxes, extra usage and exit work. Add them where applicable. More importantly, the options are only comparable if they deliver the same required outcome. A cheaper option that cannot handle a mandatory approval is not an equivalent offer.

Ask each supplier to state assumptions, exclusions, recurring charges and what triggers a change request. For foreign-currency subscriptions, consider exchange-rate exposure as well.

Apply the framework to an actual workflow

Consider an illustrative maintenance company. Its existing accounting software works well, but confirmed jobs are copied from messages into a scheduling spreadsheet. Technicians sometimes act on outdated details.

The company could buy a field-service product if its scheduling, mobile access and job history fit the team. It could keep the accounting tool and automate an approved booking into a shared job register if that meets the immediate need. A custom build deserves consideration only if important scheduling or operating rules remain unmet and the value justifies ongoing support.

Request a demonstration using the same sample jobs for each option. Include an address change, a cancellation, missing information and a duplicate request. Ask the people doing the work to complete the tasks themselves. A smooth supplier presentation does not establish that your team can operate the system.

Write a one page decision record

• Outcome: what will improve, for whom, and how you will measure it.
• Must-haves: the requirements every acceptable option must pass.
• Options: buy, build, connect existing tools, and improve the current process without new software.
• Evidence: results from the same sample tasks, including failures and recovery.
• Cost and ownership: the planning horizon, assumptions, internal owner and support arrangement.
• Decision: the chosen approach, its trade-offs, the pilot boundary and the condition for stopping or expanding.

This record gives the owner and supplier something concrete to agree on. It also helps the business revisit the decision later without relying on memory.

Pilot the risky assumption first

Choose one team or one workflow and agree the success criteria before implementation. For example: every confirmed job appears once in the register; changes reach the assigned person; failed transfers are visible to an owner; and a cancellation does not leave an active job behind.

Measure time spent checking and fixing the new process as well as time saved. Keep a workable fallback until the pilot passes. Expand only when staff can use the workflow and the support owner can handle common problems without the original builder explaining every step.

Choose the approach you can explain

A sound decision connects a business problem to evidence, cost and ownership. Sometimes that leads to a new product. Sometimes it leads to a small connection between existing tools. Sometimes a focused build is justified.

Sources and further reading

• IMDA: SMEs Go Digital Programme
• Enterprise Singapore: Productivity and Digitalisation