The inventory spreadsheet started simple. One sheet, one tab, two hundred SKUs. It worked. Then you added a second warehouse and a tab for it. Then a tab for purchase orders. Then a tab that summarises the other tabs. Then a sheet that pulls from the summary into a dashboard. Then a backup sheet because someone overwrote the formulas in the first one.
Now stock counts are wrong by the time anyone reads them. Cash is tied up in slow stock that nobody noticed. Out-of-stocks are missed and customers find them on the website. Product data eats a third of the week for one person. The single workbook has 14 tabs and one person who truly understands all of them.
This article is the honest decision tree between off-the-shelf and custom, and the build path I would propose if custom is the answer.
The Short Answer
Inventory is one of the rare business functions where good off-the-shelf SaaS exists and works for a wide range of businesses. Cin7, Unleashed, DEAR (now Cin7 Core), TradeGecko (acquired by QuickBooks), and Brightpearl all solve standard inventory operations well. If your processes are standard, off-the-shelf is the right answer and we should not build.
Custom inventory software pays back when your processes are specific in ways the SaaS tools do not model: multi-location with custom transfer rules, manufacturing with unusual BOM structures, drop-ship arrangements with consignment tracking, retail-plus-wholesale with conflicting pricing logic, or deep integration with a custom platform you already run.
The decision tree below is how I help you choose honestly.
The Decision Tree
Question 1: Are your processes standard?
Standard means: You buy from suppliers, hold stock, sell to customers, ship orders. Maybe across two or three locations. Maybe with a small wholesale side. Your inventory rules are not unusual; they are inventory rules.
If yes: Off-the-shelf wins. I will name the SaaS that fits your shape, point at the integration path with your existing tools, and decline to build. There is no honour in selling a custom build when a $99/month SaaS solves the problem.
If no: Continue to question 2.
Question 2: What makes your processes non-standard?
Manufacturing with unusual BOM structures. A finished good is built from sub-components, some of which have variable scrap rates, some of which are themselves built from sub-sub-components, and the routing depends on which version of the finished good is being made. Most SaaS handles BOMs but assumes a flat structure.
Multi-location with custom transfer rules. You have five locations with different replenishment policies. Location A is restocked weekly from a central warehouse. Location B holds drop-ship inventory you do not own. Location C is a pop-up that exists for three months. SaaS assumes locations are roughly symmetric.
Retail plus wholesale with conflicting pricing. Same SKU, different cost basis depending on channel. Same SKU, different MOQ depending on customer class. Same SKU, different tax treatment depending on region. SaaS often forces one pricing logic per SKU.
Deep integration with a custom platform. You run BX1X or a similar custom operations platform. The inventory needs to live inside it, not in a separate tool that has to be kept in sync.
Project-based or job-based stock. You allocate inventory to projects before any sale happens. SaaS does not model "this part is reserved for project X but not yet sold."
If your "non-standard" matches one of those: Custom probably pays back. Continue to question 3.
If your "non-standard" is "we do things our way": Push back on yourself first. Often "our way" is standard with a few preferences that off-the-shelf can absorb. The discovery identifies which.
Question 3: How many users will use the system?
Under five users: Custom is harder to justify on cost alone. The build cost amortises over the team, and a small team with off-the-shelf is usually cheaper.
Five to twenty users: Custom is the sweet spot. The team is large enough that off-the-shelf workarounds add up to real cost, and the build cost amortises.
Over twenty users: Custom almost always pays back, but the build is larger because you need proper user roles, audit trails, performance under concurrency, and onboarding documentation.
Question 4: How important are the integrations?
Light integration (just sync to Shopify / WooCommerce): Off-the-shelf SaaS handles this well.
Heavy integration (sync to a custom platform, custom ERP, or unusual accounting): Custom often wins because the integration becomes part of the build instead of a fragile bolt-on.
How I Would Approach The Custom Build
Phase 1: Discovery (week zero)
Before building, I need to understand the actual workflow, not the spreadsheet. The spreadsheet is one model of the workflow; usually a partial one.
What I do. Sit with whoever uses the spreadsheet. Watch them work. Ask "what happens when..." for the edge cases the spreadsheet does not handle (returns, damage, transfers, lost shipments, supplier disputes). Map the data model from the workflow, not from the existing tabs. Identify the integration points (accounting, Shopify, WooCommerce, manufacturing, suppliers).
What you get. A written discovery report covering: the actual workflow, the proposed data model, the build scope, the integration points, the user roles, the off-the-shelf options that almost fit (so the comparison is honest), and the recommended path.
Phase 2: Data migration plan (week one)
Before any code, the existing data has to be cleanable. Spreadsheets accumulate exceptions, blank rows, "TBD" values, and historical artefacts. The migration plan addresses each.
What I do. Profile the existing data. Identify the corrections and reconciliations needed. Build a migration script as repeatable and reversible. Run a dry-run migration against a copy. Reconcile against finance. The first real migration only happens after the dry-run is clean.
Phase 3: First usable version (weeks two to six)
We build the smallest version that replaces the spreadsheet for one workflow. Usually that workflow is "see current stock and adjust it."
What I build. A web application accessed through a browser. User login. Role-based permissions. The inventory grid (current stock by SKU and location). Add/edit/transfer actions with validation. Audit trail. Search and filter. Reports for the most common questions. Integration with the most important external system (usually Shopify or accounting). Mobile-responsive.
What you get. A system you can actually use. The spreadsheet stays running for the rest of the workflow during this phase.
Phase 4: Migration to live use (week six to eight)
We switch one workflow off the spreadsheet onto the new system. Pilot users first. Then everyone.
What I do. Pick the lowest-risk workflow. Pilot with one or two users. Reconcile daily against the spreadsheet. When the pilot is clean for two weeks, expand. The spreadsheet stays as a backup until everyone is on the new system for a defined window.
Phase 5: Subsequent workflows (weeks eight to twelve+)
Inventory in. Then purchase orders. Then forecasting. Then reporting. Then whatever else the spreadsheet was carrying.
What I do. Each subsequent workflow is its own short build. The system grows module by module. Like BX1X grew. Each module is scoped, built, validated, and put into use.
Phase 6: Documented handover
You keep the code, the database, the docs, the migration scripts, and the path to extend it. You also get the answer to "how do we add a new feature?" so the system can grow without me being the only one who can touch it.
Honest Variables That Change The Cost Shape
Existing data quality. Clean data migrates fast. Spreadsheets with ten years of history, mixed conventions, and undocumented exceptions migrate slowly.
Integration complexity. A simple Shopify sync is a known shape. A custom ERP integration is a discovery in itself.
User count and concurrency. A five-user system has fewer concurrency concerns than a fifty-user system. The architecture differs.
Reporting depth. "Show me current stock" is one query. "Show me cohort-based sell-through with recommendation engine for reorder timing" is a different engagement.
Mobile and offline requirements. A floor team scanning barcodes on the warehouse Wi-Fi is straightforward. A field team that needs offline capture and later sync is an additional engineering layer.
Decision to route through Villiers Vision Works. Multi-module operations platforms typically run through VVW (Villiers Vision Works), the company that operates BX1X. Anton handles discovery and design directly; VVW carries the larger multi-module engagements.
Why I Wrote This
Most articles on "replace your inventory spreadsheet" are written by SaaS vendors selling their own product. This article exists because the honest answer is "sometimes off-the-shelf, sometimes custom" and the decision tree is something a buyer should walk through with someone who is not selling a specific tool. If you read this and concluded "we are probably custom," the discovery is the route in. If you read it and concluded "we are probably off-the-shelf," I will tell you which and you save the engagement cost.