Quick answer: Buy or configure an existing inventory product when your workflows are standard. Connect an ERP when finance and warehouse already live there. Build custom only when your rules are a real advantage or no vendor can cover your channels without painful compromise. Most growing stores should exhaust WooCommerce stock settings, a dedicated inventory SaaS and ERP connectors before writing a greenfield system.
Inventory mistakes are expensive: overselling, stockouts, dead warehouse space and angry wholesale buyers. Software choice will not fix a chaotic process alone, but the wrong software will fight you daily.
Clarify what “inventory system” means for you
Write down the jobs you need:
- Track on-hand, reserved and incoming quantity per SKU
- Support multiple warehouses or bins
- Handle bundles, kits or made-to-order items
- Sync to one or more sales channels (web, Amazon, POS, B2B portal)
- Purchase orders and supplier lead times
- Lots, serials or expiry dates
- Returns to stock
- Reporting for finance
If you only need “do not oversell on one WooCommerce store,” start with native stock and careful ops. See WooCommerce inventory.
Option A: Native ecommerce stock
Pros: Cheap, simple, already in your store admin. Cons: Weak for multi-warehouse, complex B2B and multi-channel.
Fine for early stage. Painful when you open a second warehouse or add marketplaces.
Option B: Dedicated inventory / WMS SaaS
Products in this category sync stock between stores, marketplaces and warehouses. You configure rules rather than code.
Pros: Faster than custom, channel connectors exist, vendor maintains the sync. Cons: Monthly cost, quirks in edge cases, you adapt processes to the tool.
Try this before you hire a team to build from scratch.
Option C: ERP as the system of record
If finance already runs on an ERP, inventory often belongs there. The website becomes a channel that reads availability and posts orders. That is an ERP integration project with clear ownership of which system wins when numbers disagree.
Pros: One financial truth, purchasing and inventory together. Cons: ERP projects are heavy; real-time web stock needs careful design.
Option D: Custom build
Custom makes sense when your allocation rules are proprietary and material to margin, you operate unusual channels or manufacturing steps vendors do not model, you have (or can hire) people to maintain the system for years, and off-the-shelf tools failed a structured evaluation, not a one-hour trial.
Custom is not “cheaper plugins with more PHP.” It is software product work: modeling, UX for warehouse staff, APIs, testing and on-call habits. Pair it with solid recovery thinking when systems talk to each other.
Build vs buy decision grid
Ask your team:
- How unique are our rules? If a salesperson can explain them in five minutes, a vendor likely covers them.
- What is the cost of being wrong? Pharma lot tracking is not the same as T-shirt colors.
- Who will maintain this in three years? Custom without an owner becomes shelfware.
- What systems must we connect? List them. Count real connectors vs “we will write it later.”
- Can we stage the problem? Multi-warehouse next year does not force a custom platform today.
If you buy, run a serious pilot
- Import a slice of real SKUs
- Run purchase orders and returns
- Sync a non-production channel
- Measure time to receive stock and time to correct a mismatch
- Include warehouse staff in scoring, not only IT
If you build, scope ruthlessly
A viable v1 might be SKUs, locations, quantities, reservations for open orders, an API for the website and POS, an audit log of adjustments, and a simple receiving workflow.
Leave forecasting models and pretty dashboards for later. Warehouse truth first.
For related custom operational tools, see how teams approach a custom booking system with the same build-versus-configure eye.
Data migration and cutover
Moving off spreadsheets or Magento stock tables needs a freeze window, reconciliation reports and a plan for orders in flight. The discipline in data migration applies: trial imports, checksums, rollback plan.
People and process beat features
Cycle counts, who may adjust stock, and how you handle damaged goods matter more than a fancy UI. Train staff before go-live. If two people can edit the same quantity in two systems without an audit trail, you do not have inventory control yet.
Cost pictures
- Native store stock: lowest software cost, highest manual risk as you scale
- Inventory SaaS: subscription plus setup
- ERP module: license or subscription plus integration
- Custom: design, build, host, monitor, iterate
Compare multi-year cost, not month one. Custom that avoids chronic oversell can pay off. Custom that recreates a low-cost SaaS will not.
Channel conflict patterns
Web, Amazon and a retail POS all selling the same SKU need a shared available-to-promise number. Without it you oversell. Buffer stock per channel is a business decision; encode it deliberately rather than hoping each channel “usually” has enough.
Bundles and kits
If you sell a kit made of component SKUs, decide whether you stock the kit, the components, or both. Custom systems often exist because kits plus manufacturing steps exceed SaaS defaults. Document assembly time and scrap rates before you model them in software.
Reporting finance will accept
Warehouse on-hand must reconcile to what finance expects for valuation. Involve finance in the pilot. A system operations loves but accounting rejects will not last.
Security and permissions
Not everyone in the company should adjust stock by 500 units with no note. Role-based permissions and mandatory reason codes prevent “mystery inventory.”
FAQ
Can WooCommerce plugins replace a WMS?
For one warehouse and simple products, often yes. For bin-level warehouse operations, usually no.
Should the website own inventory?
Only if the website is truly your only channel and volume is modest. Otherwise a central system should own stock and push availability outward.
How long does a custom inventory build take?
A narrow v1 is often months, not weeks, once you include discovery and warehouse pilot. Beware demos that skip receiving and returns.
What kills these projects?
Unclear ownership of stock figures, no audit trail for manual edits, and integrations bolted on without failure handling.
Returns and refunds
Returned goods may be sellable, refurbishable or scrap. Your system should support reason codes and quarantine locations. Ecommerce teams that dump every return straight back to sellable stock create customer complaints about condition.
Seasonality and preorders
If you sell preorders or seasonal lines, available-to-promise logic needs dates, not only raw on-hand. Spreadsheets handle this until they do not. When preorders become a normal channel, encode the rules in software before peak season.
Vendor scorecards
When you evaluate SaaS inventory tools, score them on connectors you need today, API quality for the gaps, warehouse UX, and exportability. Trapping your stock ledger in a system with no usable export is a future migration tax.
Choose the dull option that matches your rules
Most teams should buy or connect before they build. Build when your operations are the product. If you are weighing a custom inventory system against SaaS and ERP options, our custom development work starts with that fit assessment so you do not code yourself into a corner.
