Inventory software must explain why the stock count changed, not just show a number. Use one product and a few real stock movements to compare your options. Include a returned item or a damaged delivery so you can see how each system handles exceptions.
The decision is rarely only buy or build. The realistic options are adopt a standard product, configure and integrate a platform, extend an existing ERP, create a narrow custom layer, or build a complete system. The right choice is the least complex option that satisfies the critical operating requirements with acceptable risk and ownership.
Related service: CRM, ERP & Web Application development- 01Map stock identities, locations, states, movements, and exceptions.
- 02Prioritize the requirements that protect operation and control.
- 03Test standard products with representative workflows and data.
- 04Assess configuration, integration, extension, and custom gaps.
- 05Compare migration, five-year cost, support, change, and exit.
- 06Validate the preferred option through a realistic operational slice.
- 07Record the decision, accepted compromises, owners, and review triggers.
SECTION 01
Define the inventory model before the feature list
Document how an item is identified and counted. The model may need SKUs, variants, serial or lot identifiers, units of measure, packs, substitutions, expiration or condition, ownership, and multiple locations. Each added dimension affects receiving, movement, reservation, picking, adjustment, and reporting.
Then map every stock-changing event. A purchase receipt, transfer, return, production issue, service-job consumption, damage adjustment, customer shipment, or cycle count should create a traceable transaction. Avoid a design that stores only the latest quantity without a dependable movement history.
SECTION 02
Identify the gaps that actually justify custom work
A missing dashboard color or preferred field name is not a reason to build. Look for gaps that create manual reconciliation, incorrect availability, blocked fulfillment, loss of traceability, repeated integration failure, or a workflow that is central to the business model.
Classify each requirement as critical, important, or optional. For a critical requirement, describe the consequence of failure and the evidence that a candidate system cannot meet it through supported configuration or integration. This prevents preferences from being promoted into expensive custom scope.
Unique transaction
The organization has a stock-changing event or ownership rule that standard products cannot represent safely.
Operational edge
Work occurs in vehicles, sites, low-connectivity areas, or hardware contexts that need a specific offline or device flow.
Integration boundary
Availability, orders, purchasing, accounting, ecommerce, or service work must stay consistent across systems.
Control requirement
Roles, approvals, traceability, reconciliation, or reporting require a model materially different from available products.
SECTION 03
Compare five realistic implementation options
Evaluate the smallest ownership model first. A standard product may solve the requirement; configuration may close the remaining gap; integration may remove duplicate entry; an extension may preserve the ERP as source of truth; a custom system may be appropriate only when the earlier options cannot support the operation cleanly.
| Option | Best fit | Main responsibility |
|---|---|---|
| Adopt packaged software | Standard stock, purchasing, fulfillment, and reporting workflows are acceptable. | Process adaptation, configuration, data migration, training, and vendor management. |
| Configure and integrate | The core product fits, but fields, approvals, reports, or connected systems need planned work. | Govern configuration and maintain every integration. |
| Extend the ERP | The ERP owns inventory and a supported module or extension can fill the operational gap. | Protect upgrade compatibility and the ERP data model. |
| Build a custom operational layer | A specific user experience, mobile flow, portal, or rule is unique while the ERP remains system of record. | Define synchronization, conflict resolution, offline behavior, and support. |
| Build a custom inventory system | The full model and workflow are materially distinct and the organization accepts product ownership. | Own requirements, architecture, security, releases, infrastructure, support, and roadmap. |
SECTION 04
Use a weighted build-versus-buy scorecard
Assign each dimension a weight from 1 to 5 before demonstrations. Score each option from 0 to 2: 0 means it does not meet the requirement, 1 means it meets it with a material compromise or additional work, and 2 means it meets it cleanly. Multiply weight by score and attach an evidence note.
Do not use the total as an automatic decision. A critical zero may disqualify an option even when its overall score is high. The scorecard exists to expose trade-offs and assumptions so operational, technical, and financial owners can discuss the same evidence.
| Dimension | Suggested weight | Evidence to collect |
|---|---|---|
| Critical workflow fit | 5 | Demonstrated receiving, movement, fulfillment, return, count, and exception scenarios. |
| Stock identity and traceability | 5 | Representative SKU, unit, lot/serial, location, status, and movement model. |
| Integration reliability | 5 | API limits, ownership, sync direction, retries, reconciliation, and monitoring. |
| Offline and device operation | 1–5 | Real connectivity conditions, scanning hardware, conflict rules, and recovery tests. |
| Migration and data quality | 4 | Source profiling, mapping, opening balance, history, and reconciliation plan. |
| Permissions and auditability | 4 | Role scenarios, approval paths, change history, and exception ownership. |
| Five-year cost | 4 | Comparable acquisition, operation, change, support, and exit assumptions. |
| Internal ownership | 5 | Named product/process owner and available administration or engineering capability. |
SECTION 05
Model total cost and change risk
For packaged software, include licenses, implementation, configuration, data migration, connectors, hardware, training, administration, vendor support, upgrades, and future add-ons. For custom software, include discovery, design, engineering, data migration, infrastructure, observability, security, support, maintenance, dependency updates, and roadmap work.
Model changes that are reasonably likely: a new warehouse, sales channel, unit convention, supplier process, device type, or connected system. Use ranges rather than one precise figure when scope is uncertain. Catapult AI Work provides scope-based quotes after requirements; this article does not publish a fixed price.
SECTION 06
Treat migration and reconciliation as first-class work
Profile source data before committing to a migration date. Identify duplicate items, inconsistent units, inactive records, negative or unexplained quantities, missing locations, open purchase and sales commitments, serial or lot gaps, and records maintained outside the current system.
Define the cutover balance, transaction freeze or synchronization approach, ownership of corrections, and reconciliation reports. Run at least one representative trial migration and test the operational day that follows it. A successful import is not the same as a reconciled, usable inventory position.
- 01
Profile and classify source records and open transactions.
- 02
Approve mapping, units, locations, statuses, and identity rules.
- 03
Clean data with traceable decisions and responsible owners.
- 04
Run a trial migration and test real receiving, movement, fulfillment, and adjustment flows.
- 05
Reconcile opening balances and open commitments before final cutover approval.
SECTION 07
Make the decision with explicit ownership
The final recommendation should name the chosen option, critical evidence, accepted compromises, implementation stages, responsible owners, total-cost range, exit path, and conditions that would trigger review. Record rejected alternatives so future teams understand why the choice was made.
If custom work is selected, begin with the smallest complete operational slice rather than a large module list. A slice such as receive, locate, transfer, and reconcile one stock type can reveal data, permissions, device, and integration risks before a broader rollout.
PRIMARY REFERENCES
Sources and further reading
These references cover the standards, platforms, or published prices discussed in the guide. Worked examples and checklists are our editorial guidance.
- GS1 barcodesGS1
EDITORIAL METHOD
About this guide
We use AI to assist with drafting and editing. Catapult AI Work is responsible for the published content. Examples illustrate possible approaches; they are not client case studies unless identified as such.
Budget examples are not Catapult package prices. Check linked provider pages for current fees and plan limits before making a purchase.
Read the editorial policy