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
| Approach | Entry cost | Strengths | Limits |
|---|---|---|---|
| Excel / Google Sheets | NT$0-5,000 per year | Zero rollout, everyone can use it | No 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 fee | Complete bookkeeping, clean handoff to tax filing | Process is fixed, e-commerce APIs usually cost extra modules |
| Storefront-native inventory (Cyberbiz, 91APP, Shopify) | NT$3,000-30,000 per month | Front and back office in one place, fast launch | Online orders only; physical transfers and B2B shipping fall outside |
| Custom Laravel system | From NT$180,000 | Matches the real process, integrates any API, you own the data | Requirements 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
| Phase | Duration | Deliverables | Tools |
|---|---|---|---|
| On-site interviews and process audit | 5-8 working days | Goods-in/out flow diagram, document inventory, ranked pain points | Notion, Miro |
| Data preparation and re-coding | 10-15 days (client-led) | Unified SKU master, barcode cross-reference table | Google Sheets, import templates |
| System design and prototype | 10 days | Data model ERD, high-fidelity Figma prototype, permission matrix | Figma, dbdiagram.io |
| Core development | 6-10 weeks | Receiving, shipping, transfer and stocktake modules, scanning UI | Laravel, Filament, MySQL |
| Integrations | 2-4 weeks | Marketplace stock sync, logistics API, label printing | Laravel Queue, TSC label printer |
| UAT and parallel run | 3-4 weeks | Test case sheet, recorded training sessions | Laravel Dusk, UptimeRobot |
| Go-live and opening-balance cutover | 3 days | Signed opening stock statement, launch checklist | Count 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.
- Email: [email protected]
- Phone: 0916-224-047
- LINE: @ufv9089p