Services

How to Build an Inventory and Warehouse Management System: From Barcode Stocktaking to Multi-Channel Stock Sync

2026.09.08 · 17 views
How to Build an Inventory and Warehouse Management System: From Barcode Stocktaking to Multi-Channel Stock Sync

Spreadsheet-based stock control breaks somewhere around 2,000 SKUs: your website and marketplace sell the same unit twice, month-end reconciliation runs past midnight, and the annual count throws up variances nobody can trace. This guide walks through planning a custom inventory and warehouse system - a four-option alternatives matrix, a seven-phase build with deliverables, three real budget tiers with hidden costs, five classic traps and their fixes, 30/60/90-day success metrics, and a 12-question decision checklist to run before you spend anything.

Share:

Two in the morning, still reconciling

A hardware trading company doing roughly NT$60M a year across 2,400 SKUs ran its stock on two spreadsheets: one kept by the warehouse, one queried by sales. At every month-end the files disagreed on an average of 180 lines, and the warehouse supervisor stayed until 2am patching them by hand. Worse, units sold on the website were also sold on the marketplace, forcing about 20 apology calls a month to cancel orders. The owner's real question was never "should we get a system" - it was "how much, how long, and will this be another failed rollout."

When it fits, and when it does not

A custom inventory and warehouse system makes sense when

  • You carry more than 500 SKUs with colour, size or spec variants.
  • You run two or more warehouses or stores and need live transfers and cross-location lookups.
  • You sell through a website, physical channels and marketplaces and need one source of truth.
  • You need lot, expiry or serial-number traceability (food, supplements, medical devices, components).
  • Your process is already an SOP and simply has no system behind it.

When to hold off on the spend

  • Fewer than 100 SKUs in a single warehouse - a shared sheet plus a cloud form is enough.
  • Product coding is not unified and one item has three codes in three places.
  • The warehouse has no stable Wi-Fi or mobile signal, so scanning devices cannot connect.
  • You are replacing your accounting or ERP core within three months - settle that first.
  • You expect software to fix a management problem, such as staff refusing to scan.

Alternatives matrix: four ways to do this

ApproachEntry costStrengthsLimits
Excel / Google SheetsNT$0-5,000 per yearZero rollout, everyone can use itNo concurrency control, no audit trail, overselling is a matter of time
Packaged Taiwanese inventory software (Digiwin, Chief, Wenchung)NT$80,000-250,000 plus annual feeComplete bookkeeping, clean handoff to tax filingProcess is fixed, e-commerce APIs usually cost extra modules
Storefront-native inventory (Cyberbiz, 91APP, Shopify)NT$3,000-30,000 per monthFront and back office in one place, fast launchOnline orders only; physical transfers and B2B shipping fall outside
Custom Laravel systemFrom NT$180,000Matches the real process, integrates any API, you own the dataRequirements must be explicit; 8 weeks minimum to launch

A simple test: annual loss from stock error (refunds + rush replenishment + manual reconciliation hours) / three-year amortised system cost. Above 1, custom is worth it. The hardware trader above lost about NT$960,000 a year against an amortised NT$13,000 a month - a ratio above 6.

The seven-phase build, with deliverables

PhaseDurationDeliverablesTools
On-site interviews and process audit5-8 working daysGoods-in/out flow diagram, document inventory, ranked pain pointsNotion, Miro
Data preparation and re-coding10-15 days (client-led)Unified SKU master, barcode cross-reference tableGoogle Sheets, import templates
System design and prototype10 daysData model ERD, high-fidelity Figma prototype, permission matrixFigma, dbdiagram.io
Core development6-10 weeksReceiving, shipping, transfer and stocktake modules, scanning UILaravel, Filament, MySQL
Integrations2-4 weeksMarketplace stock sync, logistics API, label printingLaravel Queue, TSC label printer
UAT and parallel run3-4 weeksTest case sheet, recorded training sessionsLaravel Dusk, UptimeRobot
Go-live and opening-balance cutover3 daysSigned opening stock statement, launch checklistCount sheets, on-site support

The parallel run is the phase clients most often ask to cut, and the one that should never be cut. Run the spreadsheet and the system side by side for three to four weeks and only switch when the gap between them is under 0.5%. Skip it and you will spend the first three months after launch firefighting.

What it actually costs (NTD)

  • Entry tier, NT$180,000-320,000 (8-10 weeks): single warehouse, up to 1,000 SKUs, phone-browser scanning, goods in/out and stocktake, five core reports.
  • Standard tier, NT$350,000-650,000 (12-16 weeks): multi-warehouse and multi-store, lot and expiry tracking, transfer approvals, safety-stock replenishment suggestions, role-based permissions, logistics integration.
  • Advanced tier, NT$700,000-1,500,000 (20-28 weeks): multi-channel stock sync, bin locations and picking routes, a Flutter handheld counting app, reconciliation with the accounting system.

Costs people forget to budget

  • Bluetooth barcode scanners at NT$3,000-12,000 each; industrial handheld PDAs at NT$18,000-45,000 each.
  • Label printers (TSC or Zebra) at NT$8,000-25,000, plus NT$1,500-4,000 a month in labels and ribbon.
  • Cloud hosting with daily offsite backup, NT$2,500-8,000 a month.
  • Real shipping fees once convenience-store pickup is integrated - from NT$55 per parcel per ECPay's published logistics rates, plus 5% business tax at settlement.
  • Initial data cleansing and re-coding, 40-80 hours, almost always on the client side rather than the developer's.
  • Annual maintenance and small changes at roughly 12-18% of the build fee.
  • On-site training at NT$8,000-15,000 per session, typically two to three sessions.

What clients expect vs what happens

  • Expected: "import the spreadsheet and we have opening stock." Reality: coding is inconsistent, so 40-80 hours of cleanup comes first - the most common cause of schedule slip.
  • Expected: "it will be accurate on day one." Reality: month one still shows 2-5% book-to-physical variance, and cycle counting takes three months to pull it under 1%.
  • Expected: "multi-channel sync is instant." Reality: every platform API has rate limits, so the honest target is 30-90 seconds, with retries and failure alerts through Laravel queues.
  • Expected: "the system will just prevent overselling." Reality: it must be handled at the database layer with locking reads such as SELECT ... FOR UPDATE, or distributed locks - a decision that belongs in the written spec.
  • Expected: "the warehouse team will love it." Reality: the first two weeks bring the loudest complaints, because scanning is slower than scribbling a note. On-site support carries you through.

Five traps and how to avoid each

  • Overselling: several sources deduct the same stock with no transaction lock. Fix: funnel every deduction through one service, backed by Laravel atomic locks and database transactions, rolling back in full on failure.
  • Wrong available quantity: treating on-hand as sellable. Fix: define it in the spec - sellable = on hand - allocated - reserved - awaiting inspection.
  • Balances without movements: overwriting the stock number directly, so nobody can trace who changed what. Fix: keep an append-only movement ledger and derive the balance by summing movements.
  • Home-made barcodes: internal codes that do not match suppliers or channels, so receiving cannot be scanned. Fix: reuse the supplier's GS1 GTIN for purchased goods and issue internal codes only for own-brand items.
  • Counting once a year: variance accumulates until it is untraceable. Fix: run ABC cycle counting - A monthly, B quarterly, C twice a year - and keep auditable records, which is what Taiwan's Regulations Governing Assessment of Profit-Seeking Enterprise Income Tax expects of inventory.
  • Flat permissions: everyone can edit cost and unit price. Fix: put the role permission matrix in the spec and restrict cost fields to supervisors.

Success metrics and the 90-day roadmap

  • Day 30: first full count done, variance under 3%; scanning coverage at 80% of transactions; daily shipping-document handling time down 20%.
  • Day 60: variance under 1.5%; ABC classification and safety-stock levels set; stockout-driven order cancellations cut in half.
  • Day 90: variance under 1%; turnover-days and dead-stock reports live; multi-channel sync failure rate below 0.5%, with UptimeRobot watching the sync schedule.

Decision checklist: score yourself before you spend

  • ☐ I can state the monthly financial loss our stock errors currently cause.
  • ☐ We have one unified product coding rule across the company.
  • ☐ Our SKU master can be cleaned into an import-ready sheet within two weeks.
  • ☐ The warehouse floor has reliable network coverage for scanning devices.
  • ☐ There is an internal owner who can decide process, not just relay messages.
  • ☐ We accept a three-to-four-week parallel run before cutover.
  • ☐ We know exactly which sales channels and carriers must be integrated.
  • ☐ The definition of sellable quantity is agreed with the sales team.
  • ☐ If lot or expiry tracking is needed, suppliers will provide the data.
  • ☐ The budget already includes hardware, consumables and year-one maintenance.
  • ☐ We will run monthly cycle counts rather than one annual count.
  • ☐ We will not swap the accounting or ERP core within three months of launch.

Nine or more ticks means conditions are ready. Below six, spend two to three weeks on process and data preparation before development starts.

Frequently asked questions

Industrial PDAs, or just staff phones?

Under 300 scans a day in a dry, room-temperature environment, a phone browser with camera scanning is enough and saves close to NT$40,000 per unit. Frozen storage, one-handed work or more than a thousand scans a day is where an industrial handheld pays for itself. A common split is PDAs for warehouse staff, phones for stores and temporary hires.

Can we do stock only and leave accounting for later?

Yes, and most projects should split that way. Phase one covers quantity flow only - receiving, shipping, transfers, counting - until accuracy is inside 1%. Phase two adds cost valuation and accounting entries. Doing both at once doubles the scope and turns a three-month launch into seven.

Can multi-channel sync really stop overselling?

It can reduce it sharply but cannot guarantee zero, because the moment an order lands on an external marketplace is outside your control. Holding a safety buffer on fast movers, centralising deductions in one service, and running sync through a queue with retries usually brings overselling below 0.5% of orders.

How much downtime does go-live need?

The cutover point is the opening count date, not a maintenance window. Freeze the warehouse on a weekend or non-shipping day, finish the count in half a day to a day, and open the books next morning on the confirmed figures. The online service itself needs no downtime.

Will we be locked in when we want to extend it later?

Source code and database are handed over along with the ERD and API documentation, so maintaining it in-house or moving to another team stays open. That is one of the sharpest differences between custom and packaged software.

Next step

ScriptWalker's Inventory and Warehouse Management System build starts at NT$180,000, including the upfront process interviews and data preparation plan. We offer a free 60-minute consultation: bring your SKU count, channel list and the last three months of count variance records, and we will tell you which tier fits - or whether you should wait.

Share: