Building an Inventory Tracking App From Your Existing Data

It is 7:40 on a Tuesday and the warehouse lead is doing the thing again. Export on-hand from the ERP. Export inventory levels from Shopify. Paste both into a Google Sheet with a VLOOKUP nobody wants to touch. Highlight anything under two weeks of cover. Screenshot it, drop it in #ops with the caption "3 SKUs at risk, PO going out today."

That ritual is why teams go shopping for an inventory management app. What most of them actually need is not a new place to store inventory. The counts already exist: in the ERP, in the storefront, in the 3PL portal, in a purchasing spreadsheet. What is missing is one screen that reads all of it, agrees on definitions, and surfaces the four or five facts that would change someone's morning.

This guide is about building that screen from data you already have. It also draws a hard line around what this approach cannot do, because inventory is one of the topics where the line matters most.

First decide: system of record, or console

Before anyone opens a builder, answer one question. Does the information you are missing already exist as a row somewhere?

If your on-hand counts live in NetSuite, Cin7, Katana, Fishbowl, Shopify, Amazon Seller Central, a WMS, or a Postgres table your data team maintains, then what you need is a console. A console reads those systems, reconciles them, and puts the reading in front of a human. It is a fast project. Two weeks of part-time effort is realistic.

If the information does not exist yet, for example cycle counts written on a clipboard, bin locations that live in the head of one person, damage notes on a sticky, then you need storage. Something has to accept new records, validate them, and keep them forever. That is a system of record, and it is a different project with a different budget. You either buy an inventory management system or you build one with a real database behind it.

The failure I see most often is teams starting the console project while quietly expecting it to become the system of record. Six weeks in, someone asks the app to accept a receiving scan, and the whole thing stalls. Decide up front. Write the decision down.

An honest note about the tooling here, including ours. Skopx apps read from connected systems and take actions through connected tools. They do not store their own records, and there is no form component that creates new data. So an app like this can be your stockout console, your receiving review queue and your reorder cockpit. It cannot be the place where inventory counts are born. If someone tells you an AI builder will replace your IMS this quarter, ask them where the row gets written.

Where inventory data already lives, and how it disagrees with itself

Every inventory project turns into a reconciliation project by day three. Plan for it.

The typical distributor or DTC brand has counts in at least four places:

• The ERP or accounting system. Authoritative for costed on-hand and for anything finance will defend. Often updated in batches, sometimes overnight.
• The sales channel. Shopify tracks inventory per location, per variant. Amazon tracks fulfillable, reserved and inbound separately. These numbers are what customers can actually buy.
• The warehouse or 3PL. Physical truth, usually the freshest, usually the hardest to reach. Some 3PLs give you an API, some give you a nightly CSV to an SFTP box.
• Purchasing. Open POs and in-transit quantities, which live in an ERP module for some teams and in a spreadsheet for a surprising number of others.

They disagree for boring, specific reasons. Learn them once:

Identity. The ERP keys on an internal item ID, Shopify keys on variant ID and SKU, the supplier keys on their part number. One SKU typed with a trailing space in a spreadsheet is the classic silent break. Build the join on a single agreed key and produce an exception list of anything that fails to match, before you show any totals.

Definitions. On-hand, available, committed, allocated, fulfillable, inbound, in-transit. Two of your systems will use the same word for different math. Pick your definitions, write them into the app as visible labels, and stop using bare "stock."

Units. A case of 24 in purchasing versus eaches in the storefront ruins a reorder calculation without ever throwing an error.

Time. A number pulled at 03:00 UTC and a number pulled live are not comparable during a busy sales day. Put the snapshot timestamp on screen. Every screen.

Profile the real data before you design a single screen

This is the step everyone skips and everyone regrets. Run the query. Look at what actually came back. Then design.

The profile questions that change the layout:

• Row count. 400 SKUs is a scrollable list. 40,000 SKUs is a table with server-side filtering and a default view that shows only exceptions. Loading everything and letting the browser sort is how these apps die.
• Cardinality of your filters. Six warehouses is a row of filter chips. Two hundred vendors is a search box.
• Text length. If product titles average 30 characters, they fit inline. If half of them run past 90 because someone appended the full spec, the column needs truncation or it eats the table.
• Value ranges and negatives. Negative on-hand is real and common, caused by oversells and unposted receipts. If your data has it, the app has to display it as an exception rather than quietly rendering a bar chart with a bar pointing the wrong way.
• Nulls. A cost field that is null for 12 percent of rows means your inventory value metric is wrong and needs a stated exclusion.
• Distribution. If 5 percent of SKUs carry 80 percent of the value, a flat alphabetical table is the wrong default sort and a value-weighted view is the right one.

This is where the newer generation of app builders earns its place. Skopx runs the query and reads a profile of the real result, column types, value ranges, text lengths, before it proposes a layout, so the design fits the data that actually came back rather than a generic template. The same discipline applies if you are hand-building in React: query first, sketch second. More on the general pattern in apps on connected data.

The five screens an inventory management app actually needs

Resist the urge to build a portal with fourteen tabs. In practice five views cover almost everything an operations team needs from an inventory management app.

1. Stockout risk. The default landing view. A stat grid at the top: SKUs out of stock now, SKUs under your cover threshold, value at risk, open POs arriving this week. Below it, a table sorted by days of cover ascending, with velocity, on-hand, in-transit, lead time and cover on one row. This screen is the reason the app exists.

2. Overstock and aging. The mirror image, and the one finance cares about. Units and dollars sitting still for more than 90, 180 and 365 days. A chart of value by age bucket, plus a table you can hand to whoever runs promotions.

3. Receiving and in-transit. Open purchase orders with expected dates, quantities, and how late they are against the original promise. A timeline component reads better than a table here because the question is "what lands when."

4. The exception queue. Negative on-hand, SKUs selling on a channel that do not exist in the ERP, items with no cost, items with no vendor, quantities that moved more than a threshold overnight. This is the least glamorous screen and the one that pays for itself. Data quality problems in inventory always show up as money problems later.

5. Single SKU detail. One search box, one SKU, everything about it in one place: counts per location, last 90 days of movement as a chart, open POs, cost, vendor, lead time. Kills the "can you check this for me" Slack message.

Components map cleanly: stat grid and metric for the top row, table for the lists, chart for trends and age buckets, timeline for inbound, callout for the stale-data warning, filter for location and vendor, and a section per block. If you also want a channel-level or margin-level rollup for the leadership meeting, that belongs in a separate view, closer to an operations dashboard than to a working console.

Days of cover: the one number worth arguing about

Every inventory app lives or dies on this calculation, so do not let a tool pick it for you.

The naive version is on-hand divided by average daily units sold over the last 30 days. It fails in four predictable ways.

Stockouts poison the average. A SKU that was out of stock for 20 of the last 30 days looks slow-moving. It is not slow, it was absent. Compute velocity over days the item was actually in stock, or the app will recommend you never reorder your best product.

One window is not enough. Show 7, 30 and 90 day velocity side by side. The comparison between them is the trend, and the trend is what a buyer actually reads.

Lead time is a distribution, not a number. Your supplier's 30 day lead time is really 28 to 52. The reorder point that matters is average daily demand times average lead time, plus safety stock sized to the variability of both. If you only have one lead time number, say so on screen rather than pretending to precision you do not have.

Seasonality breaks trailing averages. If November is four times October for you, a 30 day trailing velocity in late October is systematically low. Either compare to the same weeks last year or let the buyer apply a multiplier and show the effect.

Put the formula in a text component right in the app. When a buyer disagrees with a recommendation, you want the argument to be about the assumption, not about whether the app is lying.

How this compares to the other four ways people solve it

Four approaches show up repeatedly. None is wrong everywhere.

The honest reading of this table: if you need barcode receiving and cycle counts, buy an inventory management system, and do not let anyone talk you out of it. If you need governed, board-level metrics, a BI tool is the right home. If you need custom write-back logic and you have engineers, a builder like Retool is a legitimate choice and worth the effort. The connected-data approach wins on a narrow but common case: the data exists, it is scattered, and a non-engineer needs a working view this week. Related comparisons live in Airtable alternatives for apps.

Actions, and where an inventory management app stops

A console that only shows things gets abandoned. The value arrives when the person looking at a stockout can do the next thing without leaving the screen.

Actions that work well on top of connected tools:

• Post a formatted at-risk list to a Slack channel
• Email a vendor a reorder request from a template
• Create a task or ticket in Jira, Asana or Linear for a purchasing follow-up
• Create a draft purchase order in the ERP, if your ERP exposes that action through its integration
• Flag a SKU for review by writing to a field in the connected system that owns it

Two rules keep this safe. Every action is an explicit click with a confirmation, never something the app decides on its own. And every action names the system it will touch before it touches it, because "Send" means nothing and "Email vendor@example.com the 6 SKUs below" means everything.

Now the stop sign. This kind of app does not store records. There is no form component that creates new data. So it cannot accept a cycle count, cannot record a bin move, cannot register a receipt against a PO, and cannot be the audit trail for inventory adjustments. Those need a system that owns the row. Say that out loud in your kickoff meeting, and you will avoid the stall I described earlier.

If your real problem is that reorder decisions need a second signature, that is a different shape entirely and closer to an approval workflow app.

Access, credentials and the part that gets skipped

Inventory data is commercially sensitive. It exposes margin, supplier relationships and demand. Treat it that way.

Connect the database with a read-only user scoped to the specific tables or views the app needs. Not a superuser, not the credential your application server uses. If your ERP data lands in a warehouse, build a view that exposes only the columns you intend to show, and point the app at the view. This single step removes an entire category of accident.

Then set the audience deliberately. An app is private to the person who built it, or shared with the organization. There is no useful middle where "shared" quietly means "public link." Skopx keeps per-organization row-level isolation, encrypts data at rest with AES-256 and in transit with TLS 1.3, has SOC 2 controls in place, and never trains models on customer data. Whatever you use, get equivalent answers in writing before real cost data goes near it.

One warning that applies to every AI-assisted build. Published security research on AI-generated applications has repeatedly found projects shipped with database row-level security left disabled, which means any authenticated user can read every tenant's rows. If your app generator writes its own backend, verify that yourself rather than assuming. The topic is worth a full read in AI-generated app security.

A two-week rollout that actually finishes

Week one, day one and two: pick the definitions. On-hand, available, committed, in-transit. Write them in a shared doc. Get the warehouse lead and the controller to agree. This is the whole project in disguise.

Day three: connect one source, the one closest to physical truth, and build only the stockout risk view. Run it against real data and show it to the buyer.

Day four and five: build the exception queue. Expect it to be ugly. The list of SKUs that do not reconcile is your real backlog, and it will be longer than anyone predicted.

Week two: add the second source and the reconciliation join. Add in-transit. Add the single SKU view. Then add exactly one action, the one the buyer asked for unprompted.

Then stop building and start watching. If nobody opens the app for five working days, the screens are not answering a question anyone has, and adding a sixth screen will not fix that. Kill it or ask better questions.

For the recurring part, a morning message with the at-risk list beats an app nobody remembers to open. Scheduled runs with retries and run history belong in your automation layer rather than in the app itself. The app is where you go when the message says something is wrong.

FAQ: building an inventory management app

Can an app like this update stock levels in my systems?

Only through an action that a connected tool exposes, with an explicit click and a confirmation, and only where the owning system offers that operation through its integration. It cannot maintain counts itself. If your workflow requires adjusting quantities, receiving against a PO or recording a cycle count, the write needs to happen in the system that owns inventory. Treat the app as the place you decide, and the ERP or WMS as the place it becomes true.

How fresh is the data on screen?

As fresh as the slowest source in the chain. If your ERP replicates to a warehouse nightly, the app is showing you last night, no matter how modern the interface looks. Query the live system where you can, and put the snapshot time on every screen where you cannot. Most bad inventory decisions I have watched came from someone trusting a number that was eleven hours old during a promotion.

What if my inventory lives in a spreadsheet, not a database?

Then your first project is not an app, it is moving that spreadsheet somewhere with types, history and access control. A sheet with 8,000 rows and hand-edited SKUs will produce a beautiful app that lies. Land the data in Postgres, Supabase, Snowflake or whatever your team already runs, add the constraints, then build the console on top.

How many SKUs before the table stops being usable?

The interface stops being the issue long before the data does. Past roughly 2,000 rows, nobody reads a table, they read a filter. Design for the exception-first view at any size: default to items below cover threshold or flagged by the exception rules, and make the full catalog something you search rather than something you scroll.

Do I need a data warehouse first?

Not for a first version. Reading a production replica or querying tools directly is fine for a console over current state. You need a warehouse when you want history that your source systems overwrite, for example on-hand as of every past Monday, or velocity by week over two years. Inventory systems are notorious for storing only current state, so if trend analysis matters, start capturing snapshots early.

What does this cost to try?

The app-building side is bundled into normal platform pricing rather than sold as a separate module. On Skopx that means the Team plan at $16 per seat per month with 2.3 million AI tokens included per seat, or $5 per month solo using your own API key at provider rates. Current details are on pricing. The bigger cost is not the software, it is the two days of definition work in week one, and no vendor can do that part for you.

The short version

You almost certainly have the data. It is split across an ERP, a storefront, a warehouse system and a purchasing spreadsheet, and it disagrees with itself in ways that are boring and fixable. An inventory management app built on that existing data can be live in days: five screens, honest definitions, one visible snapshot timestamp, and a small number of actions that fire only when a human clicks.

What it cannot be is the place where counts are created. Keep that line bright, buy a real inventory system when you need one, and let the console do the job it is genuinely good at, which is making sure the right person sees the right problem before the customer does.