Software decisions in smaller businesses tend to fail in one of two directions.
Some companies run for too long on spreadsheets, email and memory. The business grows, the workarounds multiply, and one day a key person goes on leave and nobody can find the latest price list. Others swing the other way, commissioning a custom platform or an enterprise system that costs more to configure and maintain than the problem it solved.
The right answer usually sits between those extremes, and it depends less on technology than on four questions. How standard is the process? How often does it change? How many people and systems depend on it? Who will look after it?
Four options, honestly described
Spreadsheets: still adequate more often than vendors admit
A spreadsheet remains a sensible tool when one or two people own the data, the process is simple, volumes are modest and nothing else depends on it in real time. A quotation calculator used by a single estimator, or a monthly management report, can live happily in a spreadsheet.
Spreadsheets become a liability when several people edit the same file, when the file is the system of record, when version confusion causes errors, or when critical logic exists only in one person's formulas.
Standard SaaS: usually the right default
For common business functions — accounting, CRM, HR and payroll, helpdesk, e-commerce, project management — off-the-shelf software-as-a-service is usually the best starting point. The vendor carries hosting, security patching and maintenance, and the product reflects how thousands of other businesses run the same process.
The trade-off is adaptation. A SaaS product works best when the business is willing to adopt its standard process with modest configuration. Heavy customisation of a SaaS platform often combines the costs of buying and building.
No-code and low-code: good for connecting and extending
No-code and low-code tools — workflow automation platforms, form builders, configurable databases and internal app builders — are well suited to filling gaps between standard systems: routing an enquiry from a web form into the CRM, generating a job sheet from an approved quotation, or creating a simple internal approval app.
They allow non-developers to move quickly. The risks are fragility and invisibility. Automations built by one enthusiastic employee can become critical infrastructure that nobody else understands. They need documentation, ownership and a basic change process, like any other system.
Custom software: justified by differentiation, not discomfort
Custom development is justified when the process is genuinely distinctive and creates competitive advantage, no suitable product exists, or standard software cannot handle the operational complexity without unacceptable compromise. Examples include a proprietary pricing engine for configured industrial products, or a customer-facing platform that is the service being sold.
It is rarely justified merely because existing products feel imperfect. Custom software carries ongoing responsibilities: hosting, security, updates, bug fixes, documentation and, critically, someone who understands the code two years from now.
The costs people forget
Comparing a monthly subscription against a one-off development quote is misleading. A fairer comparison looks at total cost over three to five years.
Cost SaaS Low-code Custom build
Upfront Low (set-up, migration, Low to moderate High (design, training) development, testing)
Ongoing Subscription per user Platform fees; Hosting, maintenance,
or volume maintenance by staff security,
enhancements — often
a significant share of
the original build cost
each yearCost SaaS Low-code Custom build
Who maintains it Vendor You, or a contractor You, or a contractor
Risk if a key person Low Moderate to high High unless well leaves documented
Integration and data ownership
Whatever you choose, ask three questions before committing:
- 1. Can the data get out? Check export options and API access. If the business cannot extract its customer, order or financial data in a usable form, it does not fully control it.
2. Can it connect? A new tool that cannot exchange data with the CRM, accounting or operations
system will create duplicate entry. That is the problem we examine in our article on why CRM,
ERP and operations systems don't talk to each other.- 3. What is the common identifier? Customer IDs, job numbers and product codes should be consistent across systems, or integration becomes guesswork.
Security without an IT department
Smaller businesses do not need an enterprise security team, but they do need basic discipline: single sign-on or at least enforced multi-factor authentication, role-based access, removal of access when staff leave, reliable backups and a short list of who administers each system.
SaaS shifts much of the infrastructure security burden to the vendor, but not account security or data access. Custom software shifts all of it to you. The US NIST Cybersecurity Framework 2.0 includes a quick-start guide written for small businesses, which is a useful, vendor-neutral checklist.
Vendor lock-in and scalability
Lock-in is not automatically bad. Committing to a good platform is often efficient. The risk lies in lock-in without exit: proprietary data formats, punitive contract terms or essential processes embedded in tools that cannot be migrated. Before buying, understand how you would leave.
Scalability works the same way. Ask whether the tool will cope with three times today's users, transactions and complexity, not ten times. Most small businesses will change systems at least once as they grow, and designing for an imagined future often costs more than migrating later.
A compact decision matrix
Situation Usually the best fit
Simple process, one owner, low volume, nothing Spreadsheet depends on it
Common business function; willing to adopt Standard SaaS standard practice
Gaps or handoffs between existing systems; No-code / low-code automation repetitive manual steps
Situation Usually the best fit
Moderately specific internal process; few users; Low-code app, with documented ownership changes often
Distinctive process that creates competitive Custom build, with a maintenance plan advantage; no product fits
Heavy SaaS customisation is being considered Pause — revisit whether the process should change, or whether a different product fits
Two illustrative scenarios
An engineering services firm with 15 staff quotes from spreadsheets, tracks projects in email and invoices in accounting software. The likely answer is a standard CRM and project-management tool, with low-code automation turning accepted quotations into project records and completed milestones into invoice drafts. Custom software is unlikely to be justified.
A technical field-service company with 60 staff sells configured service contracts with complex pricing based on equipment type, location and response time. Standard field-service software handles scheduling and job records well, but cannot reproduce the pricing logic that differentiates the business. A sensible answer may be to buy the field-service platform and build a small, well-documented pricing module that integrates with it.
Conclusion
The best software decision is rarely the most sophisticated one. Start with the simplest tool that reliably supports the process, buy where the process is standard, automate the handoffs between systems, and build only where the business is genuinely different. Above all, decide who will own each system before you choose it.
Omnidite Advisory helps businesses select, connect and automate software platforms in ways that fit their operations and resources.
Sources & references
This article provides general information and commercial commentary, not legal, investment, regulatory, medical or certification advice. Illustrative examples and calculations are not actual customer engagements or quotations.
Discuss this topic ↗