A growing business rarely wakes up needing “an ERP.” It experiences specific problems: repeated data entry, inconsistent stock balances, spreadsheets that disagree, approvals trapped in messages, or reports that take days to prepare. The right technology depends on the operating problem—not the popularity of a software category.
The decision is not a three-way contest with a universal winner. Spreadsheets, packaged enterprise software and custom applications solve different problems. They can also coexist when responsibilities are clearly defined.
1. What each option is good at
Scroll horizontally if needed to read all columns.
| Option | Strong fit | Typical weakness | Financial consideration |
|---|---|---|---|
| Spreadsheets | Small datasets, flexible analysis, temporary workflows, prototypes | Weak shared ownership, inconsistent validation, fragile change history | Low initial expense, potentially high hidden labor |
| Packaged ERP | Standardized finance, purchasing, inventory, orders and integrated enterprise processes | Process fit, licensing, change management, implementation complexity | Subscription or licensing plus implementation and support |
| Custom software | Distinct operational workflows, specialized integrations, customer-facing or industry-specific systems | Requires disciplined product ownership, testing and maintenance | Discovery, development, hosting, security, enhancements |
| Hybrid approach | Existing ERP plus specialized operational capture or reporting | Integration ownership and data boundaries | Multiple components but often lower disruption |
Important: “Custom” does not automatically mean better. A business that commissions bespoke payroll, accounting and tax functionality without a compelling reason may inherit unnecessary compliance and maintenance risk. Conversely, forcing a unique industrial process into a rigid off-the-shelf workflow can also be expensive.
2. Diagnose the real source of friction
Map a representative transaction from beginning to end. In a mining supply business, for example, an enquiry may become a quotation, approval, purchase order, delivery instruction, invoice and payment record. Ask where information originates, which system owns it, who can change it, which steps require evidence and where errors happen.
Common warning signs include:
- Multiple spreadsheets each claim to be the master list.
- Staff re-enter identical data into two or more applications.
- Approvals occur informally with no reliable audit trail.
- A report requires manual reconciliation every week.
- Important documents are stored against people rather than transactions.
- Permissions are assigned by convenience instead of responsibility.
These signals suggest better process and data architecture may be needed. They do not, by themselves, justify building software.
3. Understand total cost of ownership
Compare choices over a realistic multi-year period rather than just the first invoice. Consider licensing, discovery, migration, implementation, integration, training, hosting, backups, security, change requests, technical support and vendor exit.
A useful decision model is:
Total expected cost = acquisition + implementation + migration + integration + recurring operations + expected change cost + expected exit cost.
Do not treat each term as precisely knowable. Use ranges, record assumptions and run sensitivity scenarios. An apparently free spreadsheet can have high opportunity cost if three staff members spend hours reconciling it every week. A custom application can be cheap to launch but expensive to keep secure if no maintenance budget exists.
A hypothetical comparison
Assume a distributor handles 250 orders a month and manually spends 12 minutes correcting or re-keying each order. This is 50 staff-hours monthly (250 × 12 ÷ 60). At an illustrative fully loaded labor cost of US$5 per hour, the direct time cost would be US$250 monthly, before mistakes or lost sales. These figures are an example for calculation—not a measured Zimbabwean benchmark.
If a proposed system saves only half that work, the direct labor benefit is US$125 monthly. A large implementation would require other substantial benefits to justify itself. The model prevents decisions driven by attractive interface screenshots rather than economics.
4. Evaluate data ownership and interoperability
Before choosing a vendor, ask whether your business can export its own transaction history, associated documents, user actions and reference data in usable formats. Understand API availability, integration fees, rate limits, identity mechanisms, audit logs, backups and migration rights.
An ERP should normally remain the authority for the business functions it owns. A specialized operational system can capture additional details and pass validated information through an agreed interface. Avoid two systems independently editing the same master record unless conflict handling has been explicitly engineered.
5. When each choice makes sense
Remain with spreadsheets when the process is low-volume, decisions are reversible, one clear owner maintains the file, security exposure is modest and the manual effort is not material. Even then, establish validation rules, backup and version controls.
Use a packaged system when requirements are standard, vendor functionality meets the essential needs, established compliance support matters, and the organization can adopt reasonably standard procedures.
Commission custom software when a proven process creates competitive differentiation, the existing software cannot represent key operational facts, integrations are unusually important, or long-term ownership of the workflow is strategic. Require an explicit maintenance and exit plan.
Choose a hybrid when replacing a working finance or stock system would be wasteful but a missing workflow needs to be digitized. The integration contract becomes a first-class part of the project.
6. Procurement questions worth asking
Request a demonstration using your own representative process—not the vendor’s polished example. Require the supplier to show an error path, a correction, a permission restriction, a data export, a backup restoration and a normal report. Ask which functions are standard and which require paid customization.
Contractually clarify acceptance tests, documentation, uptime commitments where appropriate, intellectual property, access to source code if relevant, support response windows, data extraction and what happens if the vendor relationship ends.
Decision checklist
- We have measured the workflow problem.
- We know which records and processes are business-critical.
- We have estimated ongoing—not just startup—costs.
- We know what an existing system can already do.
- We know who owns the data and can export it.
- We have defined security, audit and backup requirements.
- We have tested a real workflow, including failures.
- We have an accountable internal system owner.
Frequently asked questions
Is Excel unsuitable for a business? No. It is excellent for analysis and small, flexible workflows. Risk grows when uncontrolled spreadsheets become the only shared transaction system.
Can custom software replace an ERP? Technically, sometimes. Strategically, reproducing standard enterprise functions can be a poor investment unless there is compelling evidence.
Should we integrate our existing applications instead? Often yes. Integration-first approaches can preserve investments, but only if the systems expose sufficiently reliable and authorized interfaces.
What is the first step? Document one high-cost process, its current tools and its failure points. This is more useful than asking vendors for quotations before requirements exist.
Related reading
Continue with How to Connect Business Systems, Planning a Multi-Branch Platform and Mistakes When Commissioning Custom Software.
