Off-the-shelf or custom ERP and inventory software? How small businesses should decide

Past a certain size, spreadsheets stop coping: stock counts do not match, sales and the warehouse hold different versions of the same order, and month-end close keeps several people late checking figures. That is when most owners face the same question: buy an off-the-shelf inventory or ERP package, or have one custom-built? Companies succeed both ways — and companies on both paths have paid for systems nobody ends up using. The difference is rarely the software itself; it is whether the business understood its own processes before choosing. Here is how to decide, in the order it actually happens.

Map your processes before you look at products

Many companies start with a sales demo: someone clicks through the screens, everything seems to be there, and the contract gets signed. But demos run on standard scenarios, and what actually stalls an implementation is almost always the exceptions specific to your business. Write the following down first; whether you then compare packages or scope a custom build, you will have a common yardstick.

• Document flow: from quote to order, shipment, invoice and payment — who handles each step, on which document, and where it gets stuck. Do the same for purchasing and receiving.
• Exceptions: partial shipments, returns and exchanges, consignment, customer-specific pricing, one item sold in several units (cases and pieces), batch numbers and expiry dates. This is where systems are really tested.
• Reports you cannot do without: what the owner reviews weekly, what accounting needs at month-end, what format tax filing requires. Report requirements tend to surface last — and are the easiest place for extra charges to appear.
• External systems to connect: e-invoicing, accounting software, online marketplaces, point-of-sale, logistics. Every integration adds one more thing to verify for compatibility and cost.

Packaged, custom or hybrid: who each one suits

• Packaged software: suits companies whose processes look much like their peers’ — general trading, standard manufacturing or service workflows. It launches faster, its features have been proven across many customers, accounting and tax formats are usually handled, and the vendor updates it as regulations change. The condition is that you are willing to adapt some of your practices to the system’s standard flow; if you want every screen reshaped to match how you work today, the package loses its advantage.
• Custom development: suits companies whose processes are themselves the competitive edge — unusual pricing logic, a distinctive production schedule, bespoke data exchange with customers or suppliers. The system is built around how you actually work, you pay for no modules you do not use, and you own the data structure. The price is the up-front time needed to specify requirements properly, and quality that depends heavily on the development team and the specification.
• Hybrid: run standard functions such as accounting, inventory and purchasing on a package, custom-build only the genuinely distinctive piece — a quoting tool, a customer portal, a production dashboard — and connect them through APIs or data import and export. For many small businesses this is the most pragmatic route: you keep the package’s upgrade path without bending your core business around the software. Bear in mind that the integration itself needs maintaining, since a package upgrade can change its interface.

Total cost is more than the quote

• Ongoing package costs: whether the licence is perpetual or subscription, whether it is priced per user or per module, and what the annual maintenance fee actually covers. Ask up front how pricing changes when headcount grows or you open another site.
• Package implementation and modification: implementation consulting, extra reports and changes to screens or workflows are often billed separately by the day. The software price on the quote is rarely the final total.
• Custom maintenance and additions: bug fixes after launch, hosting and backups, adjustments when regulations change, and the cost of new features should be agreed in the contract, not negotiated after something breaks.
• Hidden costs common to both: cleaning and migrating data, staff training, and the double entry of running old and new systems in parallel during the early weeks. None of it appears on a vendor quote, yet it often absorbs the most staff time.
• The cost of leaving: if you replace the system in a few years, can the data be exported completely and in a usable format? It is the point most often overlooked at signing, and it decides whether you are locked in.

The pitfalls that catch most implementations

• Heavily modifying the vendor’s code: in the short term everything works your way, but every vendor release means redoing the modifications — or being stuck on an old version. The more you need to change, the more you should ask whether the wrong path was chosen in the first place.
• Underestimating data migration: duplicate item codes, one product under several names, inconsistent units, opening stock that was never accurate. Leave these uncleaned and the numbers will not reconcile on day one — and staff soon drift back to their spreadsheets.
• Custom work with no written specification or acceptance criteria: requirements are given verbally, and only on delivery does it emerge that each side understood them differently — followed by endless revisions and extra charges. Every feature should state plainly what goes in and what should come out.
• Leaving ownership of code and data unsettled: the contract should state who holds the source code, the database and the hosting accounts for a custom system. Otherwise, if the developer stops supporting you, even retrieving your own data becomes difficult.
• Switching everything over at once: when every module goes live on the same day, there is no telling where a problem started. Launch one module first, or run old and new systems side by side for a while and reconcile, then cut over fully once the numbers agree.

How to decide, and where to begin

It comes down to one question: is there a part of your process that competitors do not have, and that is how you make money? If not, build on a package and accept its standard practices wherever you can. If so, custom-build that part and leave the rest to off-the-shelf software. When evaluating, ask vendors to walk through your own real documents and exceptions rather than their standard demo, and confirm data export and the ownership terms in the contract. No choice guarantees a smooth rollout, but thinking your processes through first avoids most of the expensive mistakes. If you would like help working out which path fits, or need custom features and integrations alongside an existing package, Floatstone Digital can map your requirements and assess the practical options.