Building a Custom Inventory Check-In System With Claude Code

Most inventory problems do not require a full Warehouse Management System. They require a tool that lets a team receive product quickly, count accurately, reconcile moving inventory, and adapt when the operation changes.

We recently built that kind of system for a client inventory project using Google Sheets, Google Apps Script, Node.js deployment tooling, and Claude Code. The goal was not to build a flashy software product. The goal was to create a robust inventory check-in workflow that worked in the real world, could be deployed quickly, and did not force unnecessary WMS cost onto the client.

We are keeping the client anonymous in this article. The point is the operating model and the development approach, not the specific account.

The Problem We Were Solving

The operational requirement was straightforward:

• Multiple people needed to scan inventory at the same time
• Counts had to consolidate into a single master view
• New inbound inventory needed its own receiving workflow
• Inventory was moving while counting was in progress
• The system had to be simple enough for warehouse use, not just software demos

That combination is where many teams get pushed toward a WMS. On paper, that sounds reasonable. In practice, it often means paying for a large system built for a much more rigid operation than the one you actually have.

Why We Did Not Reach For a WMS

This is the same pattern we see repeatedly in fulfillment. Companies are told that operational maturity means buying heavier software. Often it means the opposite.

For this use case, the expensive path had three obvious downsides:

• Cost - Licensing, implementation, onboarding, and change orders would all become client costs
• Rigidity - Receiving workflows, special handling, and exceptions would be harder to change
• Brittleness - A lot of modern warehouse software is impressive in demos and frustrating in live operations

What we needed was a system that fit the actual work:

• A master source of truth
• Simple scanning interfaces for individual users
• Fast updates without record-locking headaches
• Clear reconciliation against expected inventory
• A receiving flow for additional inventory after the original count

The Architecture

The system uses a multi-workbook Google Sheets architecture backed by Apps Script.

• One master workbook handles product data, barcode lookup, user registry, summary reporting, ledger calculations, and receiving-event management
• One workbook per user handles scanning locally so multiple people can work without stepping on each other
• A registry file and deploy scripts track workbook IDs and push code updates across master and user workbooks

That structure solved an important real-world problem: concurrent use. Instead of making several people share one live scanning sheet, each scanner gets an isolated workbook. The master workbook then pulls and consolidates their work.

The base sheet model in the master workbook is simple and operationally legible:

• Config
• Master Data
• Barcode Lookup
• User Registry
• Summary
• Adjustment Data
• Receiving Events
• Receiving Scans

Each user workbook stays lighter:

• Scans
• Damaged Scans
• Receiving Scans
• Receiving Events

What Made The Check-In Flow Robust

The point of a check-in tool is not just to record scans. It is to survive reality.

1. Separate user workbooks

Each user scans into their own workbook. That avoids contention, keeps the interface simple, and makes it easier to attribute scans by person and by time.

2. Formula-based lookup for speed

The user workbooks do not wait on slow script lookups for every scan. Barcode scans trigger formulas that resolve:

• SKU
• Product name
• Quantity
• Valid / invalid status

That matters because scan speed is not a cosmetic detail. A system that feels slow gets worked around.

3. Barcode-to-SKU mapping for units and cases

The lookup layer supports both unit and case barcodes, with case quantity awareness built into the scan flow. That let the same check-in process handle mixed packaging realities without adding complexity for the person holding the scanner.

4. Consolidation back to master

The master workbook pulls regular scans, damaged scans, barcode mappings, case-quantity updates, and receiving scans from all active user workbooks. After sync, the system rebuilds summary views and pushes updated data back out to users.

That gave us a simple operating rhythm:

1. Users scan locally
2. Master syncs everyone back together
3. Summary updates against the latest data
4. Users receive refreshed lookup data as needed

5. Receiving events for inbound inventory

Once the original inventory workflow was in place, we extended the system to support receiving events for additional inbound inventory.

That mattered because the operation did not stop after the first count. New inventory kept arriving. We needed a way to:

• Create a receiving event in master
• Push the event list to user workbooks
• Let scanners choose the active event
• Tag inbound scans to that event
• Consolidate totals into event-specific summary sheets

This is a good example of why lightweight custom systems are valuable. The receiving layer was added as the operation needed it, instead of being over-specified upfront.

The Hard Part: Inventory Was Still Moving

A static expected quantity is easy. Live reconciliation is harder.

During an inventory project, stock is still changing:

• Orders are shipping
• Corrections are being made
• Internal adjustments happen
• Some source data is messy

If you compare scans against an old baseline without accounting for those movements, the summary becomes misleading fast.

That is why the system includes a ledger layer:

Live Expected = Baseline + Net Adjustments

The master workbook imports inventory adjustment data, cleans it, filters out events that should not affect physical inventory, and updates a live expected quantity column in Master Data.

That let the summary sheet compare counted inventory against a moving reality instead of a stale snapshot.

Data Quality Problems We Had To Solve

This is where a lot of operational software breaks down. It assumes clean inputs. Warehouse reality does not.

The ledger workflow had to account for several messy cases in source data, including:

• Adjustment rows with missing SKUs
• Orders where some fulfilled SKUs were missing from one data source
• Orders missing entirely from one data source
• Refund-related restock activity that should not distort physical inventory

We handled that by combining multiple sources:

• Raw inventory adjustment exports
• GraphQL-derived order/SKU data
• Processing scripts to normalize and deduplicate records before import

This is not glamorous software work. It is the kind of work that makes reports trustworthy.

Why Claude Code Helped

The value of Claude Code here was not that it invented the workflow. The workflow came from operational knowledge. The value was speed.

It let us move quickly on:

• Initial architecture
• Apps Script implementation
• Iterative menu and sheet changes
• receiving-event expansion
• deployment scripting
• documentation and cleanup

That meant we could bring the first working version to market in days instead of months, then improve it in response to real usage.

This is the pattern we care about most:

• Identify the real operational bottleneck
• Build the first useful version fast
• Put it in front of the people doing the work
• Watch what breaks or feels awkward
• Ship improvements immediately

That loop is much harder when software changes require vendor tickets, consultant schedules, or a heavyweight implementation plan.

Why This Matters For Non-Software Companies

This is not just a story about one inventory tool. It is a story about how non-software companies can use AI-assisted development to build operational leverage.

If you run a warehouse, a brand, or another physical operation, you probably have workflows that are too specific for off-the-shelf software and too important to leave messy forever.

Historically, that created a bad choice:

• Live with clumsy software
• Or spend heavily on custom systems and ongoing vendor dependency

AI-assisted development changes that equation when it is paired with real domain expertise.

It allows a company like ours to build tools that are:

• Custom enough to fit reality
• Fast enough to matter
• Cheap enough to keep costs off the client
• Flexible enough to evolve with the operation

That does not mean every business should build its own software. It means more businesses can right-size their software instead of accepting the default enterprise answer.

The Operating Principle

We do not build custom tools because software is interesting. We build them when they let us serve clients better.

In this case, a lightweight inventory check-in app gave us:

• Better control over the inventory process
• Faster adaptation as the project evolved
• A practical inbound receiving workflow for new client inventory
• Less dependence on expensive, brittle WMS software
• More flexibility for clients of different sizes

That is the larger point.

The future is not every company becoming a software company. The future is more companies using AI to build the few systems they actually need instead of buying a large system designed for someone else’s operation.

The Takeaway

If your inventory process is pushing you toward a WMS, stop and ask a more precise question:

Do you need a warehouse management system, or do you need a better way to check in, reconcile, and report inventory?

Those are not the same thing.

For this project, the better answer was a custom inventory check-in system built on familiar tools, designed around the actual workflow, and brought to market quickly with Claude Code.

That gave us the control we needed without locking the client into cost and rigidity they did not need.