Buy, connect or build? Choose the right business system

A business has a familiar moment: the team is frustrated with the current software, someone sees a polished demo, and the conversation jumps straight to buying a replacement. The demo looks simpler because it shows the tidy path. The real operation also contains revised orders, missing information, unusual approvals, supplier delays, quality checks and customers who need a clear answer while a job is still moving.

A good system decision begins with that real work. The solution might be a ready-made package, a better configuration, a connection between tools, a small layer of bespoke software or a more substantial replacement. There is no prize for choosing the most custom option. The aim is to remove a meaningful constraint without creating a larger one.

First, separate the workflow from the software

Pick one process the team wants to improve. Write down what starts it, what result should be produced, who does each step, what information they need, what decisions they make and what can go wrong. Follow a recent example from beginning to end. Include the ordinary route and an exception. Then compare what the process requires with what the current software actually supports.

This prevents a common mistake: asking a product to solve a process that the business has not agreed. If one department says a job is complete when it is built and another says it is complete after the customer signs for delivery, no software can settle that definition by itself. Agree the language and ownership before configuring fields, reports or automations.

There are four sensible moves

1. Configure the package you already have

Most teams use only a small part of the product they pay for. Roles, required fields, status definitions, forms, notifications or reports may be set up poorly—or not at all. Ask the provider or an experienced administrator to show how the current product handles the workflow before adding another subscription. Configuration is attractive when the underlying model fits and the team can work within its boundaries.

2. Connect tools that are good at different jobs

Your sales, finance and delivery systems may each be suitable for their own purpose. The problem may sit between them: a customer is entered twice, an accepted quote does not create a job, or a delivery change never reaches the invoice. An integration can move agreed data between systems and reduce rekeying. First decide which tool owns each record, what should sync and how staff will see a failed or conflicting update.

3. Add a tailored workflow or operational layer

Sometimes the business needs one clear workspace that brings existing records, tasks and decisions together. A small custom layer can guide a distinctive workflow while leaving specialist systems in place. It might manage project stages, approvals, checks or handoffs. This can protect the way the business operates without rebuilding finance, email or every other package. Its boundaries and connection points need to be clear from the beginning.

4. Replace a system when it is the limiting factor

Replacement is justified when the current product cannot support a necessary process, cannot be maintained, or prevents the business from getting dependable information. It carries real migration, training and disruption costs. Plan how open work, historical records, permissions, reports and integrations will move. A replacement can be the right answer, but a vague feeling that the software is old is not enough evidence to begin one.

Compare the cost of operating each option

The monthly licence is the most visible cost, not the whole cost. Include configuration, implementation, data migration, integrations, training, administration, support and any extra seats. Add the work the team will continue doing manually: rekeying, checking, chasing, correcting and compiling reports. Estimate the time using your own observations and the people involved. Separate real recurring work from rare incidents so one bad week does not distort the decision.

A lower subscription can still cost more to run if it leaves staff stitching the process together. A bespoke build may remove some of that work while adding responsibility for support, hosting, security updates and future changes. Ask who will own the system after the project, what ongoing costs are expected and how the business can request improvements. Compare the options over the period you genuinely expect to use them, with assumptions written down.

A practical comparison can use this calculation: annual software and support cost, plus implementation and change cost, plus the recurring manual work that remains. For each line, state how you estimated it. If the existing process already produces expensive corrections or delays, include those examples separately. The calculation will not decide for you, but it will make trade-offs visible and stop a convenient licence price from dominating the whole discussion.

Check the fit where the work gets unusual

Ask a vendor to demonstrate your actual workflow. Give them the example with a late delivery, a revised quantity or a failed quality check. See whether the product lets the right person make the change, records why it happened, alerts the next owner and preserves a useful history. Watch how many screens and duplicate fields are needed. A demo built around your best case tells you little about how the product will behave on a demanding Tuesday.

Record every workaround the demonstration requires. Some are harmless and may be temporary. Others become permanent side processes: a spreadsheet for missing fields, a shared inbox for approvals, a paper board for schedule changes or a coordinator who tells each department what changed. Those workarounds should appear in the comparison, with an owner and an estimate of the effort they create.

Separate a product gap from a rollout gap

A team can blame software for a problem caused by unclear ownership, incomplete setup or a rushed rollout. Before replacing a product, ask whether the feature exists, whether it is configured correctly, whether the relevant staff know how to use it and whether a manager expects the process to be followed. If the product already supports the work but no one owns its setup or adoption, a new product may reproduce the same problem with a different interface.

Try a short, structured review. Ask the vendor or administrator to demonstrate the exact missing step, using the same awkward example that exposed the gap. Then ask a staff member to complete it without coaching. If the feature works but people cannot find it, improve configuration and training. If the feature cannot represent the required status, rule or approval, document that limitation and assess a connection or extension. This test prevents a software purchase from being used to avoid a necessary conversation about process.

Be especially careful with requests for custom development inside a package. A small extension can be appropriate, but establish who owns it, whether it survives product upgrades, what the vendor supports and what happens if the customisation stops working. A feature delivered only by one consultant with no documentation may be harder to maintain than the original workaround.

Ask these questions before you sign

• Can the people doing the work complete the ordinary process without re-entering the same facts?
• Can we represent the approvals, checks and exceptions that matter to customers or quality?
• Can managers see current status and a named next owner without chasing the team?
• Which system owns each key record, and how do we export it if we leave?
• How are access, backups, support, upgrades and security responsibilities handled?
• What is included in implementation, and what will cost extra?
• Can we begin with one workflow and expand after real staff have used it?
• Who inside the business will own decisions and adoption after launch?

Ask for the answers in writing where they affect price, data access or business continuity. For important integrations, confirm which side initiates updates, what happens when two people edit at once, and who gets alerted if the connection stops. For critical work, agree a fallback route. The everyday failure path deserves as much attention as the happy-path product demo.

When a subscription is the right answer

Choose ready-made software when the work follows a common pattern, the package handles your necessary controls, and the team can use it without an elaborate workaround. A subscription often brings mature functionality, vendor support and frequent improvement that a small custom system would be expensive to recreate. It can also be a good way to test a process before the business knows what should become permanent.

Be honest about how much change the team can absorb. If the existing operation is under pressure, the shortest reliable route may be to configure a mainstream product and accept a few sensible limits. You can still document what the system does not cover and review those limits later. Buying software is a good decision when it takes necessary work off the team's hands and fits the way the business intends to operate.

When tailored software is worth considering

A tailored system becomes worth exploring when several signs appear together: the workflow makes the business distinctive, the same gaps survive repeated configuration attempts, important information crosses multiple teams, and the missing controls have a visible operational cost. A system might provide one shared job record, show dependencies, collect evidence at the point of work and route exceptions to an accountable person.

The case becomes stronger when the system can support a meaningful next phase rather than a collection of disconnected features. For example, a project workflow might create the base for scheduling, quality evidence, client updates and later automation. That does not mean building every future module up front. It means establishing a coherent model that can grow without making today's first phase too large.

Tailored software also asks the customer to participate. Someone must make decisions about the process, supply access to the current systems, review prototypes and test real examples. Team members need time to learn a new way of working. After launch, someone must own the relationship with the developer or support partner. If no one can take those responsibilities, start with a smaller process improvement or a standard package.

Budget for ownership after launch

Every route needs an owner once the initial setup is complete. A subscription needs someone to manage accounts, permissions, renewals and configuration. An integration needs monitoring, a clear path for failed updates and a decision about who maintains it when one connected product changes. A bespoke system needs a support arrangement, backups, security maintenance, a way to request changes and a person who can explain the workflow to new staff.

Ask the supplier what support covers, how urgent problems are handled, how releases are communicated and what happens if the relationship ends. Ask your team who can approve changes to roles, fields, rules and reports. Make sure important knowledge does not live only in a developer's head or an employee's private notes. A system that solves today's problem but has no owner can become tomorrow's fragile dependency.

Include a simple operating plan in the proposal: who uses the system, who administers it, who reviews access, who handles an outage, where the business records a problem and how improvements are prioritised. Agree how staff will ask for help. These decisions make a small solution supportable and stop routine changes turning into informal, undocumented work.

• Name the business owner and day-to-day system administrator.
• Set an expectation for support response and critical incident escalation.
• Keep workflow notes and key configuration decisions accessible to the business.
• Review access and integrations when staff roles or products change.
• Agree how the team will request, assess and approve improvements.

Make the next decision reversible

You do not need a complete five-year technology plan before improving a workflow. You do need a clear first outcome, a person accountable for it and a boundary around the records and systems involved. Write down what should be better at the end of the first phase, what is explicitly out of scope, which assumptions still need proving and how you will measure adoption.

A short discovery phase can be useful when the requirements, data or stakeholders are still unclear. It should produce something concrete: a mapped process, system and data inventory, proposed first phase, risks, options and an investment range. If the workflow is already well understood, avoid paying to rediscover it. Scope the build directly and agree what the team will review before work begins.

A simple decision rule

• Configure when the tool already models the process and setup is the gap.
• Connect when the tools are good but people are bridging them manually.
• Extend when the process needs a shared operating view or rules the packages cannot provide.
• Replace when the current platform prevents necessary work and the full transition is justified.

The best next move is the smallest one that removes the important constraint and leaves the business with a supportable system. Start by mapping one workflow, gathering actual examples and asking the team where they lose time or confidence. Then compare the routes against the operation you run, not the product category a vendor wants you to buy.

How a build runs, stage by stage

Back to the notes