Start with the main business decisions
Business system requirements guide
Defining what a business system must do is the single most consequential step before any development or procurement begins. Requirements are not a wishlist of features pulled from competitor products; they are a structured description of the processes the system must support, the data it must handle, the roles that interact with it, and the rules that govern its behaviour.
A practical requirements document starts with the current process, not the proposed solution. Map what happens today: who does what, what information they need, what decisions they make, and where the handoffs occur. Only then identify where the current approach fails — delays, errors, missing information, lack of visibility, or steps that simply cannot scale. The gap between the current state and the desired state is what the system needs to close.
For each process, specify the data that flows through it. Where does it come from? Who creates it? Who is allowed to view or edit it? How long must it be kept? These questions matter because they determine database design, access controls, and compliance obligations. A requirement that states "users can manage client records" is too vague. A requirement that states "an account manager can update a client's billing address, but only a finance user can change the payment terms" is precise enough for a developer to build against and a tester to verify.
Integrations deserve their own section in any requirements document. Most business systems do not operate in isolation. They receive data from or send data to accounting software, email platforms, payment processors, or other internal tools. For each integration, state the direction of data flow, the trigger (real-time event, scheduled batch, manual action), the specific fields involved, and what should happen if the other system is unavailable.
Finally, attach acceptance criteria to every requirement. An acceptance criterion is a testable statement that defines when the requirement is met. If the requirement is that the system generates monthly invoices, the acceptance criteria might specify which data is included, the format of the output, who receives it, and what happens if a client has no billable activity that month. Without acceptance criteria, you cannot objectively determine whether the delivered system does what you paid for.
When a business needs a custom system
Most businesses start with spreadsheets, email, and whatever off-the-shelf tools their team already knows. That approach works until it does not. The shift toward a custom system is rarely driven by a single event; it accumulates through a series of problems that standard software cannot resolve without contortion.
The clearest signal is a process that the business has repeatedly tried to fit into existing software and failed. If your team spends significant time working around limitations — exporting data to spreadsheets for manipulation, maintaining separate shadow records, or using email threads as a workflow tracker because the official tool does not support the required steps — the process itself is telling you that no available product models it accurately.
Another indicator is competitive differentiation in how you operate. If your business wins or retains clients because of a particular workflow, reporting capability, or service model that generic tools cannot replicate, then forcing that workflow into standard software means gradually eroding the advantage. A custom system preserves and enforces the process that makes the business distinct.
Regulatory or contractual requirements can also necessitate a bespoke approach. Certain industries require specific audit trails, data-handling procedures, or access controls that off-the-shelf products either do not offer or offer only in enterprise tiers with features you do not need alongside ones you cannot disable. Building to your exact compliance profile is often more controllable than retrofitting a product designed for a different regulatory context.
Scale is a less reliable signal than it appears. Many businesses assume they need a custom system because they have grown, when in fact a better-configured off-the-shelf tool would suffice. The question is not how large the business is, but whether its processes are standard enough to be served by products built for a market. If the answer is no, custom development becomes a rational investment rather than an indulgence.
Build vs buy business software
The build-versus-buy decision is often presented as a simple cost comparison, but the real trade-offs run deeper. Buying off-the-shelf software gives you a working product immediately, a vendor responsible for maintenance and updates, and a community of other users who have already uncovered the worst bugs. Building gives you exact alignment with your processes, full control over the roadmap, and no dependency on a vendor's product strategy.
Cost is the most commonly misunderstood factor. A bought system has a visible licence or subscription cost and a less visible cost of configuration, integration, training, and ongoing adaptation. A built system has a visible development cost and a less visible cost of long-term maintenance, hosting, and the risk that initial requirements miss something important. Comparing only the headline numbers produces a misleading result.
Time-to-value favours buying in most cases. An off-the-shelf system can be operational in weeks, assuming your processes are close enough to what it expects. A custom system typically requires months of discovery, development, and testing before it handles real work. If the business problem is urgent and a standard tool can address it adequately, building is difficult to justify on timeline alone.
Control and flexibility favour building. When you buy, you are subject to the vendor's release cycle, pricing changes, and strategic priorities. A feature you depend on might be deprecated, a pricing tier might be restructured, or the vendor might be acquired. When you build, you own the source code (assuming the contract is structured correctly) and decide what changes to make and when. That control has genuine value, but only if the business has the capacity to direct and maintain the system over time.
The decision often comes down to how different your processes are from what the market provides. If your requirements sit within the mainstream of what a product category offers, buying is usually the lower-risk path. If your requirements sit outside that mainstream — not because they are more complex in general, but because they are different in specific ways that matter to your operation — building becomes the more honest choice.
Common types of business system: CRM, ERP, HR and inventory
Business systems are usually categorised by the function they serve. Understanding these categories helps when scoping requirements, because the category determines what a system is expected to handle and where its boundaries lie.
CRM systems
Customer Relationship Management systems track interactions with prospects and clients through the sales pipeline and beyond. At their core, they manage contacts, opportunities, and communication history. More sophisticated implementations extend into onboarding, contract management, and post-sale service. The value of a CRM lies in giving the business a single, consistent view of each customer relationship rather than a fragmented picture spread across individual inboxes and spreadsheets. CRM is covered in detail in the next article in this guide.
ERP systems
Enterprise Resource Planning systems connect the operational backbone of a business: finance, procurement, order fulfilment, and often production or service delivery. An ERP is not a single application but a suite of integrated modules that share a common data model. The principle is that a sales order entered in one module flows through to invoicing, inventory adjustment, and procurement without manual re-entry. ERPs tend to be large, expensive, and slow to implement, which makes them most common in mid-size and large organisations where the volume of cross-departmental data justifies the investment.
HR systems
Human Resources systems manage employee data from recruitment through to departure. Core functions include maintaining personnel records, tracking leave and absence, managing payroll inputs, and storing documents such as contracts and compliance certificates. More capable systems add performance management, expense processing, and onboarding workflows. For UK businesses, HR systems must handle the specific requirements of HMRC payroll reporting, pension auto-enrolment, and right-to-work checks, which makes the choice of system partly a compliance decision.
Inventory and stock management systems
Inventory systems track what a business holds, where it is held, and how it moves. For businesses that hold physical stock, these systems manage purchase orders, goods received, warehouse locations, pick-and-pack processes, and stock adjustments for damage or shrinkage. For businesses that sell services rather than goods, the equivalent is often a resource or capacity management system that tracks availability of people, equipment, or time slots. The critical requirement in any inventory system is accuracy: if the system's view of stock does not match reality, every downstream process — ordering, fulfilment, financial reporting — is compromised.
How business systems fit into a company's digital strategy
Individual business systems do not operate in isolation, yet many organisations treat them as independent purchases. A CRM is selected by the sales team, an accounting system by finance, an HR tool by people operations, and the result is a collection of disconnected applications that each hold part of the picture but cannot share it efficiently.
A digital strategy provides the connective tissue. It does not need to be a lengthy document; it needs to answer a small number of practical questions. Which systems are core to the business and which are peripheral? Where does data need to flow between systems, and in what format? Who is responsible for each system's operation, and who is accountable for the connections between them? What happens when a system fails or needs to be replaced?
The most common structural mistake is allowing data silos to form. When the CRM holds client contact details, the accounting system holds billing details, and the support portal holds service history, no single system can answer a basic question like "what is the total value of this client to our business?" without manual reconciliation. Integrations — whether through APIs, file transfers, or middleware — are not optional extras; they are the mechanism by which separate systems function as a coherent whole.
Another strategic consideration is the lifecycle of each system. Business systems age. The technology they are built on becomes unsupported, the vendor changes direction, or the business outgrows what the system can do. A digital strategy anticipates this by ensuring that no single system is irreplaceable: data can be exported, integrations can be reconfigured, and the business is not held hostage by a tool that no longer serves it.
Off-the-shelf vs bespoke business software
Understanding the characteristics of off-the-shelf and bespoke software helps clarify what each actually delivers, beyond the build-versus-buy decision framework.
Off-the-shelf software is built for a market segment. Its features reflect what the vendor believes most customers in that segment need, informed by sales feedback, support tickets, and competitive pressure. The advantage is that the product has been tested across many implementations and refined over time. The limitation is that it is designed for an average customer who does not exist. Your business will match some features precisely, use others awkwardly, and find that certain things you need are simply not provided.
Configuration is the mechanism by which off-the-shelf software is adapted. Most products offer settings, custom fields, workflow builders, and integration options that allow a degree of tailoring without code changes. The question is whether the available configuration points cover the gaps between the product's model and your process. If they do, off-the-shelf is a pragmatic choice. If the gaps require workarounds that undermine data integrity or user experience, the product is being forced into a role it was not designed for.
Bespoke software is built for one organisation. Its features reflect exactly what that organisation has specified, which is both its strength and its risk. The strength is precise fit: the system models your process as it actually works, not as a product designer imagined it might. The risk is that the specification itself may be incomplete, incorrect, or based on a process that should have been rethought rather than automated. Building a bespoke system to replicate a flawed process simply makes the flaw more efficient.
Maintenance trajectories differ significantly. Off-the-shelf products receive ongoing updates from the vendor, but those updates are driven by the vendor's priorities, not yours. Bespoke systems receive updates only when you commission them, but those updates are entirely under your control. Over a period of years, an off-the-shelf system may drift toward or away from your needs depending on the vendor's direction, while a bespoke system will stay exactly where you left it — which is an advantage only if you continue to invest in keeping it relevant.
How to assess whether your current systems are fit for purpose
Assessing existing systems is not a technical audit; it is a business process audit that happens to involve software. The starting point is to identify the processes each system supports and then evaluate whether those processes are working as the business needs them to.
The most reliable indicator of a system that is no longer fit for purpose is the volume and nature of workarounds. If staff routinely export data to spreadsheets to perform calculations or produce reports that the system cannot generate, the system is failing to deliver part of its value. If they maintain parallel records because the official system does not capture the information they actually need, the system has lost credibility with its users. Workarounds are not a sign of user incompetence; they are a sign that the system's design does not match the work.
Data quality is another diagnostic. If the same client or product appears under different names, if records are incomplete because users skip fields they consider irrelevant, or if reports require manual correction before they can be shared, the system's data model is misaligned with the business's information needs. Poor data quality is often treated as a user discipline problem when it is actually a system design problem.
Integration failures are a clear warning sign. If data must be manually transferred between systems on a regular basis, if reconciliation between two systems is a recurring task, or if staff are unsure which system holds the authoritative version of a piece of information, the systems are not working together. The cost of these failures is often hidden because it shows up as staff time rather than a line item on a software invoice.
Security and compliance deserve explicit attention, even if they are not the reason for the assessment. A system that was fit for purpose when it was deployed may have become a liability if it no longer receives security updates, if it stores data in ways that conflict with current UK data protection requirements, or if its access controls have not kept pace with changes in the organisation's structure. These are not theoretical risks; they are practical obligations that any system assessment should address, with current specialist review where the business lacks in-house expertise.
The outcome of a fit-for-purpose assessment is not automatically a decision to replace. Sometimes the conclusion is that the current system is adequate but poorly configured, underutilised, or undermined by a lack of training. Sometimes the conclusion is that a targeted modification or a new integration would resolve the problem without a full replacement. The value of the assessment lies in distinguishing between situations where the system is the problem and situations where the system is being misused or undersupported.