How to build a custom inventory management app

The short answer

Start with eight records:

1. Item and its stable internal identifier.
2. Location.
3. Unit of measure.
4. Stock movement.
5. Source document or reason.
6. Count session and observed quantity.
7. Discrepancy and approved adjustment.
8. User, role, and permitted action.

Calculate current stock from accepted movements. Do not make “quantity on hand” the only history you keep.

This guide assumes you have already decided that a sheet is no longer enough. If that decision is still unclear, use the spreadsheet-to-app warning signs or run the workflow readiness assessment.

Define what one unit and one location mean

Inventory errors often begin before the app. The same product appears under several names, one team counts cases while another issues pieces, or a shelf is described differently on each form.

For the first item set, define:

• one stable item identifier;
• display name and description;
• base unit and permitted conversions;
• active locations and any sublocations;
• whether lot, batch, serial, expiry, condition, or owner matters;
• whether negative stock is blocked, warned, or temporarily permitted;
• who may create an item or change its identifying fields.

Barcodes can carry identifiers, but the barcode is not the inventory model. GS1 explains that barcodes may encode identifiers for products, shipments, and locations, plus attributes such as serial numbers, batch or lot numbers, and dates. Its standards separate identifying something from capturing and sharing the data. GS1 barcode standards, how GS1 standards work

Do not claim GS1 compatibility because the app can display or scan a code. Standards-based identification requires the correct identifiers, data carriers, business rules, and implementation.

Use movements as the source of the balance

A movement should answer five questions: what changed, by how much, where, why, and who recorded it.

A simple balance for an item at a location is:

opening + receipts + returns in + transfers in − issues − shipments − transfers out ± approved adjustments

The exact movement types belong to your operation. A service company may issue parts to a job. A retailer may receive, sell, return, damage, and transfer stock. A manufacturer may need material issues, work in progress, finished goods, quarantine, and scrap. If those distinctions affect ownership, cost, traceability, or safety, model them explicitly.

Each accepted movement should retain:

Avoid deleting an accepted movement to “fix” the number. Add an authorised reversal or adjustment that preserves the error and correction.

Treat transfers as two-sided work

A transfer is not an instant change between two cells when goods can be in transit. It may need states such as:

draft → dispatched → in transit → received → closed

Dispatch reduces available stock at the source according to your rule. Receipt confirms quantity and condition at the destination. A shortage, damage, or partial receipt becomes a discrepancy with an owner rather than a quiet edit.

This matters even in one building. Moving items from stores to a technician, production area, vehicle, or consignment location changes custody. The app should show which role may dispatch, receive, reject, or correct each side.

Make counts a reconciliation process

A count is evidence about physical stock, not permission to overwrite the ledger.

Create a count session with scope, assigned counters, instructions, status, observed quantity, and any tolerance approved by management. Compare the observation with the recorded balance. A discrepancy then moves through investigation and, where permitted, adjustment approval.

The U.S. Government Accountability Office's inventory-count guide describes defined count procedures, record-accuracy measures, tolerances, management accountability, and the use of cycle counts. Although written for public-sector inventory, its operational lesson is useful: accuracy needs a defined measurement and response, not an occasional number replacement. GAO inventory count guide

Your app can show:

• due counts by location or item group;
• count sessions awaiting completion;
• discrepancies awaiting investigation;
• adjustments awaiting approval;
• repeat discrepancies that deserve a process review.

Do not publish an accuracy percentage until the team defines what counts as an accurate record, the tolerance, the denominator, and the measurement period.

Keep permissions narrower than the menu

Receiving, issuing, transferring, counting, and adjusting are different authorities. A person may need to record a count without gaining permission to approve the resulting adjustment.

OWASP recommends least privilege, deny by default, authorization checks on every request, and tests for the permission model. Hiding an adjustment button from warehouse staff is not enough; the app must reject the action on the server when the role is not authorised. OWASP Authorization Cheat Sheet

Test horizontal boundaries too. A user assigned to Location A should not be able to retrieve or change Location B merely by altering an identifier. Supervisors need explicit scope. Temporary access should have an owner and end date.

Decide the integration and connectivity boundary early

Inventory is often connected to purchasing, sales, accounting, e-commerce, manufacturing, field service, and barcode hardware. Each connection changes the source-of-truth decision.

For every external system, write down:

• which system owns the item record;
• which event creates a movement;
• how a duplicate is detected;
• what happens when the connection is unavailable;
• who reconciles rejected or delayed events;
• whether the user sees data that may be stale.

Do the same for connectivity. A responsive web app used on a phone is not automatically an offline inventory app. If staff work without reliable internet, test the exact requirement: what data must be present, what can be recorded offline, how conflicts resolve, and how users see sync state. Do not promise offline or real-time operation until it has been built and verified.

Run twelve acceptance cases

Test at least these records in a private version:

1. A normal receipt.
2. The same receipt submitted twice.
3. A quantity entered in the wrong unit.
4. A transfer dispatched but not received.
5. An issue that would create negative stock.
6. Two users trying to issue the same remaining quantity.
7. A count that matches.
8. A count discrepancy requiring approval.
9. Damaged or quarantined stock.
10. An unknown or duplicated scanned identifier.
11. A failed external hand-off or delayed sync.
12. An app release that must return to the previous behaviour.

Application rollback has a boundary. Returning to earlier behaviour cannot reverse physical movement or an external accounting transaction. Keep reconciliation owners for those effects.

In KasiLabs, you describe the records and rules in ordinary language, review a readable plan, and test a private working version with real roles and synthetic stock records. Owners choose access and paid-action limits. A reviewer approves the exact release, and earlier versions remain available. How KasiLabs works

Buy inventory software when the standard system fits

Packaged inventory or warehouse software is usually the better choice when you need mature purchasing, valuation, accounting, e-commerce, replenishment, warehouse routing, demand planning, regulated lot or serial traceability, tested offline mobile behavior, or established hardware integrations. Rebuilding that breadth as a “small custom app” creates hidden ownership.

A focused custom workflow is more reasonable when one stable movement or reconciliation process sits between systems and off-the-shelf products force staff back into side sheets. It still needs a named owner, clean item/location data, access tests, a count process, and a maintenance plan.

KasiLabs enables customers to create the tailored operating layer; it does not provide a prebuilt inventory product or claim the capabilities above by default. Use the hardest-workflow test before trusting any builder with stock records.

Describe one item moving through two locations in KasiLabs. Include a duplicate, a discrepancy, a wrong-role adjustment, and a failed hand-off, and keep the app private until each outcome is clear.