Build an inventory app around your stock workflow

When does a custom inventory app make sense?

A small shop may need to record incoming deliveries, find low-stock products and explain why a quantity changed. A workshop may track materials consumed by jobs. Start with the workflow your spreadsheet makes awkward, rather than recreating every feature of a warehouse system.

An inventory app is a good first project when one location and a small catalog are enough. Barcode hardware, offline synchronization, accounting integrations and several warehouses add requirements that should be tested separately. This page provides a build brief and acceptance checklist; it is not a claim that every inventory feature is already built into BrainHalf.

Define products and stock movements separately

Give each product a unique SKU, name, unit, opening quantity and reorder level. Record each later receipt, sale or adjustment as a stock movement with the product, quantity, reason, time and responsible user. Keeping the history helps explain the current balance.

For a first version, define current quantity as opening quantity plus receipts minus issues, with signed adjustments added. Use one unit per product: mixing boxes and individual pieces without a conversion rule produces misleading totals. Decide whether negative stock is permitted and what should happen when an SKU already exists.

• Product: SKU, name, unit, opening quantity and reorder level.
• Movement: product, receipt or issue, quantity, reason and timestamp.
• Permissions: owner manages staff and products; staff access only the actions you allow.
• Low-stock view: products whose quantity is at or below the reorder level.

Start with a specific inventory-app prompt

Replace the business type and permission rules with your own. Ask for a real database explicitly, and use synthetic records until the behavior has been checked.

Test the stock calculation with numbers you know

Create a sample brake-pad product with an opening quantity of 10 pairs. Receive 5 pairs and issue 3. The balance should be 12 pairs, and the movement list should explain both changes. Set the reorder level to 12 and confirm the product appears in the low-stock list if your rule includes equality.

Submit the same action twice to see whether the app prevents duplicate stock changes. Try a blank SKU, an existing SKU, a negative quantity and a value with the wrong unit. Open the app in two sessions and check what happens when both people change the same product. A correct-looking dashboard is not enough.

• Reload and confirm the saved product and both movements remain.
• Sign in with a separate business account and verify it cannot read the first account’s products.
• Test a failed request: the form should preserve the input and avoid displaying an unsaved change as successful.
• Use a phone to create a product and record a movement, including long names.
• Compare summary totals, product details and exported records against the same small dataset.

Publish after the workflow passes

For supported managed apps, BrainHalf builds and verifies a saved version before activating the public release. Production has its own database; development test records are not copied. Test sign-in and a small disposable transaction on the public URL before adding real stock.

Keep the owner’s sign-in working and decide how to recover records before you depend on the app. Restoring source code does not restore a database. Source export is available, but hosted records and managed services need separate setup when you move to another provider.