A box still contains twenty pairs of gloves. The number is correct. It may even have been updated five minutes ago.
One much more useful piece of information is missing: will those twenty pairs last two days or three weeks?
That is where inventory management gets strange. It looks like a counting problem first. It turns into a timing problem.
The frozen number
A traditional stock count produces a photograph.
It says there are 20 boxes, 8 cartridges, 3 rolls or 47 parts left. A spreadsheet can store that photograph perfectly well. So can a sheet of paper, with a level of server-outage resilience that remains slightly embarrassing for the SaaS industry.
The photograph starts ageing as soon as somebody takes something.
That gap between physical inventory and the quantity recorded in a system is common enough to have its own research literature. A 2008 study covering almost 370,000 inventory records across 37 stores of one retailer found 65% of the records to be inaccurate.2 That is a large retail environment, not a six-person workshop, so the percentage should not be transplanted to a small team. The mechanism is still useful: a stock record stays correct only when the actions that change the stock reach the record too.
A large monthly count can repair the gap. Then the counter starts drifting again.
The product-design problem is less glamorous: how do you record a movement without turning every pair of gloves into a tiny tax return?
The missing gesture
That is where Invumi starts.
Its main interface does not try to make a small workshop look like a 40,000-square-metre warehouse. It tries to make the movement light enough to record while it is happening: open the product, add or remove a quantity, keep working.1
The idea is almost suspiciously simple. It controls everything that comes after it.
A forecast built on false history is merely an error wearing nicer clothes. A low-stock threshold based on a quantity nobody updates will wait politely while the shelf empties. Even an excellent chart is still fiction when its input is wrong.
Recent replenishment research is also exploring the value of point-of-consumption data when inventory records are imperfect.3 The systems studied are more technical than a phone in a studio, but the shift is useful: collect the change close to the moment it happens instead of asking someone to reconstruct the month later.
The blind threshold
Now suppose the quantities are good.
You can define a threshold: “warn me when ten units remain.” Useful. Also blind to speed.
Ten units can be comfortable for something used once a month. They can be an emergency for a consumable used fifteen times a day when the supplier needs a week to deliver.
Invumi keeps the threshold and adds an estimate built from movement history.1 The important design choice is less the algorithm than its right to stay quiet. The public product page says the forecast only appears when enough history exists.1
That detail captures the product decision unusually well.
Software that does not know should be allowed to display “I don’t know.” In a dashboard, this sometimes feels like a premium feature after years of interfaces trained to produce a number whether or not the number deserves to exist.
The forecast does not replace the threshold. It adds another question: how quickly are we approaching it?
Buying enough
The other half arrives when it is time to order.
Knowing that one product is low does not yet tell you how much to buy. The decision depends on the current quantity, the target quantity and what is likely to be consumed before the next restock.
For a small team, the mechanism can stay deliberately ordinary: a target per product, a list of items below their threshold, then a quantity that brings each one back toward the target. Invumi groups that information in its purchasing view instead of asking someone to visit every product page.1
The point is not to automate purchasing all the way into the supplier. Not yet. It is to remove the slightly ridiculous moment where somebody opens three browser tabs, a spreadsheet, the supplier website and perhaps a photo from last week to decide whether the team needs 4 boxes or 14.
That tiny administrative task is exactly the kind of friction that becomes expensive because it is too small to deserve a proper operations project.
Knowing the boundary
Invumi is not trying to become a full warehouse management system.
The product targets small teams. It tracks products, movements, thresholds, target quantities and a forecast when the data supports one.1 Complex lots, advanced picking or EDI belong to a different class of software. Adding them for the sake of a longer feature grid would probably make the product worse for the person who simply wants to know whether gloves need ordering today.
That is also the limit of this article.
This design note can explain why Arthur built the product this way and the problem each choice tries to address. It cannot turn that experience into evidence that Invumi fits every small company, or pretend that retail research directly validates what happens in a studio, fab lab or small shop.
The useful test is simpler: does the team still record movements after two weeks? Do the quantities stay close enough to reality for the alerts to matter? Does placing an order require fewer unnecessary decisions than before?
If those things do not happen, the predictive chart can look excellent. It will simply decorate a bad database.
The product, here
That specific problem is why Arthur built Invumi: inventory management for small teams that starts with real movements, flags low levels and tries to estimate a stockout before it becomes visible on the shelf.1
There are features that are easier to sell in a screenshot. This one says more about the product: when the data is insufficient, the forecast does not appear.
Good inventory software does not need to pretend it can see the future. It only needs to stop you discovering the past when you open the last box.