How to Build an Inventory App with Barcode Scanning

An inventory app should answer two questions quickly: "What is this item?" and "How many do we have in this location?" Barcode scanning makes the lookup fast, but the product only works when stock changes are recorded correctly.

For a first version, choose one business and one stock workflow. This guide uses a small shop receiving products, moving items between a back room and a sales floor, and counting stock at closing. The same model can work for parts, studio equipment, or service supplies.

Choose the first inventory task

A shop may receive deliveries, sell products, transfer stock, return items, and count inventory. Trying to design all those flows before launch creates a large, confusing app.

Begin with receiving and a simple count. The success test is concrete: a worker scans an item, finds the correct product, adds received units to a location, and sees the updated balance. A second worker can verify the movement without asking who changed the total.

If your existing system is a spreadsheet, sort its columns into item fields, stock movements, and notes. Check which rows are duplicates before importing them into the app.

Map the item record

The first item record needs a name, your own SKU, barcode value or values, unit, optional photo, and an active status. A product sold individually may also have a pack size or variant. Keep supplier and price fields only if your first workflow uses them.

Do not use a barcode as your database's only permanent identifier. Packaging changes, different variants can share a product family, and some stock has no readable code. Assign an internal item ID and store scanned codes as lookup values.

Choose the barcode type you actually have

Test real labels from your shop. A product barcode, a QR label printed for your own bins, and a supplier's shipping code may represent different things.

The camera scans a string. Your app must decide whether that string maps to an item, a location, or a batch. Ask the business to collect sample labels before you build the scanner. A scanner that reads the camera feed but cannot match their labels isn't useful.

For Expo apps, the official Expo Camera documentation covers barcode detection in CameraView. Huxly can generate the app around that native capability when Expo is your selected framework.

Design the scan flow

A good scan flow is short:

1. Open Receive stock.
2. Scan the item code.
3. Show product name, image, and unit.
4. Enter the received quantity.
5. Choose a location.
6. Review and confirm.
7. Show the recorded movement and new balance.

Keep the scanner from processing the same visible code repeatedly while the confirmation screen opens. Let the worker correct a wrong match or search manually when the label is damaged.

Store movements, then calculate balances

A single editable "quantity on hand" field hides how a number changed. Store movements such as receive, transfer, use, sale, return, and adjustment. Each movement needs item, quantity, source and destination when relevant, actor, time, and reason.

Balance is the result of recorded movements for an item in a location. You may cache balances for speed, but the ledger is what lets you investigate a discrepancy.

Handle multiple locations

Even a small shop can have a shelf, back room, and vehicle. Require the worker to choose or confirm the location before saving a movement. Remember their last choice only if it cannot cause silent mistakes.

Transfers need two linked changes. If stock leaves one location but never arrives at the other because of a partial write, the app creates a false shortage. Save a transfer as one operation in the backend or use a state that can be reconciled.

Count stock in the real world

Physical counts rarely match the recorded balance perfectly. Build a count session that can be paused and resumed. Record the expected quantity, the counted quantity, who counted, and the adjustment decision.

Don't quietly replace a balance when someone types a new number. Require a reason for an adjustment and keep the previous value. The question later will be "Why did this change?" The app should answer it.

Deal with concurrent edits

If two workers receive or adjust the same item at once, the second write must not overwrite the first. Record movements as separate operations and calculate the resulting balance consistently in the backend.

For example, a balance of 10 with two valid receipts of 2 and 3 should become 15. Two screens each saving a new absolute balance can leave it at 12 or 13. This is a backend rule, not a visual design problem.

Decide on offline behavior

Offline scanning is useful in a warehouse or field location, but it adds conflict work. For a first version, you can allow searches and draft movements offline while requiring a connection before a final balance is confirmed.

If you queue movements, give each a unique ID, show "Pending sync," retry safely, and prevent a duplicate movement after reconnecting. Decide how the app handles a stock count that changed on another phone while one user was offline.

Huxly's offline mode guide covers the broader sync decisions.

Control who can change what

A viewer may search stock, a worker may receive and transfer, and a manager may approve adjustments. Store these rules on the server. Hiding an adjustment button from workers does not stop a direct request.

A small first role model might be worker and manager. Add more roles only when the business has a real difference in responsibility. See the role-based access guide.

Keep the interface fast

The scanner screen should be ready when the worker opens the task. Use a visible search fallback and large controls for quantity adjustment. The confirmation view should show item name and location clearly enough to catch an error.

Test in the actual light and space where workers scan. A polished desktop preview cannot reveal glare, shaky camera focus, tiny labels, or interrupted connectivity.

Build useful low-stock alerts

A threshold is useful only if it reflects how the business orders. Start with a manager-controlled minimum per item or location and show which stock needs attention.

Avoid sending a notification for every scan. Show a daily review list or notify when stock crosses a threshold, then suppress repeats until the state changes. Define whether reserved stock counts as available stock if the business needs that distinction.

Import existing items carefully

A CSV import can accelerate setup, but inconsistent SKUs, duplicate barcodes, and blank units will create wrong matches. Dry-run a small sample and show errors before importing the full catalog.

Require the team to review duplicate candidates instead of merging them automatically. Preserve the original source file until they can scan and find the imported items.

Test before rollout

Test damaged codes, unknown codes, duplicate scans, a code belonging to several variants, negative quantities, concurrent receives, failed transfer, rejected adjustment, and an interrupted offline sync. Count a set of physical items and compare the app's resulting balance.

The MVP is ready when a real worker can receive and locate items without a founder watching over their shoulder.

Work through a real receipt

Imagine the back room has 12 units of an item. A supplier delivers 8 more, but the worker scans the same label twice while putting the box down.

The first scan should display the item and back room location. The worker enters 8, checks the unit, and confirms. The backend saves one receiving movement with a unique operation ID. The visible balance becomes 20.

On the second scan, the scanner should open a new confirmation step. It must not automatically add another 8. If the worker submits the same operation twice because of a slow connection, the backend should recognize its ID and return the saved result. If this really is a second box, the worker creates a new movement and the balance changes again.

This small scenario covers more than camera scanning. It tests input confirmation, server ownership of the balance, safe retries, and a movement history the manager can inspect.

Write acceptance checks before release

Give the first worker a short task: receive an item, move two units to the sales floor, and count the remainder. A different person should be able to explain the final quantities from the movement list.

Check these outcomes:

• Every stock change has an actor, time, type, and quantity.
• A transfer moves the same quantity out of one location and into another.
• A double tap cannot create a duplicate movement.
• A scanner error leaves the prior balance untouched.
• An adjustment records both the old and the new number.
• The worker can find an item by name if its code will not scan.

If one fails, fix that workflow before adding suppliers, purchase orders, or forecasting.

Build the inventory app with Huxly

Huxly can help build the scanner flow, item records, stock movement backend, access rules, and mobile preview in one project. Give it sample labels, real inventory data shapes, and the receiving workflow first. Then test the generated flow at the stock location before adding purchasing or accounting.

FAQ

Conclusion

A reliable barcode inventory app turns scans into traceable stock movements. Begin with one business, real labels, one receiving path, and a physical count. Get the balance rules right before building a large reporting dashboard.