Custom inventory and order management software

When the standard model does not fit your product

Off-the-shelf inventory assumes a unit is a unit. Businesses build custom when that breaks:

• Lot and batch tracking with expiry, where a recall means finding every customer who received a specific lot
• Serial numbers tracked individually through warranty and service
• Variable units — sold by weight or length, received in one unit and sold in another
• Kits and assemblies, where selling one thing depletes eleven others
• Customer-specific pricing, contract rates and volume breaks
• Consignment or customer-owned stock sitting in your warehouse

Any one of these can be forced into a generic tool with enough workarounds. The workarounds are the cost, and they are usually paid in somebody's unrecorded daily labour.

Count what is committed, not just what is present

The most consequential design decision in inventory software is what "available" means. On the shelf is not the same as available to promise: some of it is allocated to orders not yet picked, some is on a purchase order not yet arrived, some is quarantined.

Systems that track only physical quantity oversell constantly, and overselling costs more than carrying the stock would have. Model committed, on-order, and available separately from day one.

Every movement is an event

Inventory should be built as a ledger, not a number you overwrite. Each receipt, pick, adjustment, transfer and return is an immutable event, and the current quantity is derived from them.

This costs slightly more to build and repays it the first time a count disagrees with the system. With a ledger you can see exactly when the two diverged and what happened. With a stored number you have a discrepancy and no explanation — which is the situation almost every warehouse manager will recognise.

Barcodes, because typing is the error

Manual entry of SKUs and quantities is where inventory accuracy goes to die. Scanning is cheap, works on ordinary phones, and removes the entire class of transposition errors. If anything moves in volume, scanning is not a nice-to-have.

Integration is most of the work

Inventory sits in the middle of everything — accounting, your sales channels, your suppliers, shipping. Realistically, integration is where the majority of the build goes, and it is where estimates go wrong when they are made by someone who has not looked at the systems involved.

Ask early and specifically what each system can export or expose. A supplier who sends a weekly spreadsheet by email is a different integration than one with a real API, and only one of them is quick.

Units of measure cause more bugs than anything else

If you buy in one unit and sell in another, that conversion will be the source of most of your inventory errors. Buy by the pallet, stock by the case, sell by the each. Buy steel by weight, sell by the cut length. Buy fabric by the bolt, sell by the metre with an offcut left over.

Handle it explicitly or it will be handled inconsistently in a dozen places. That means a defined base unit per item, conversions stored as data rather than written into code, and a deliberate decision about rounding — because rounding is where the slow drift between the system count and the physical count comes from. The systems that survive are the ones that picked a base unit on day one and never negotiated with it.

Counting without stopping the business

Physical counts are how you find out the software has been wrong, and the annual shutdown count is the worst version of it: disruptive, expensive, and it tells you about a discrepancy months after it happened.

Cycle counting is the alternative — count a small subset continuously, weighted so fast-moving and high-value items come round more often. It needs support in the software: a count sheet, a way to record what was found, a variance report, and an approval step before adjustments post. That approval step matters. Letting anyone correct a count to match what they see destroys the only signal you have that something is going wrong.

Decide what happens when you run out

Every inventory system needs an explicit answer for overselling, and most acquire one by accident after the first incident. Do you refuse the order, accept it as a backorder, allow a negative count, or hold stock for a period while an order is pending?

There is no universally right answer — it depends on whether your customers will wait. What is always wrong is having different answers in different parts of the system, so that the website allows what the warehouse cannot fulfil. Pair the decision with a reservation rule: stock committed to a picked-but-unshipped order is not available, and a short hold on items in an open cart prevents the race between two customers buying the last one.

Returns run backwards through everything

Returns are routinely left until last and they touch every part of the system: inventory, orders, invoicing, payments and often accounting. The awkward part is that returned stock is not automatically sellable stock. It may need inspection, repackaging, quarantine or scrapping.

So a return is several steps, not one: authorised, received, inspected, dispositioned, refunded. Each step needs a state, and the item needs somewhere to sit that is not general stock until someone decides it is fit to sell. Skip this and returned goods either vanish from the count or reappear in it before anyone has looked at them, and both errors are discovered by a customer.

Who is allowed to change a number

Inventory quantities are financial figures, and in most small operations everybody can edit them. That is how shrinkage becomes untraceable — not through theft, but because adjustments are made freely and never explained, so no pattern is ever visible.

Adjustments need a reason code and a person attached, and large ones need a second pair of eyes. This is not about distrust; it is about being able to answer why a count moved three months later, when nobody remembers. It is also the point where the inventory system stops being a stock list and starts being something your accountant can rely on at year end.

What it costs

Builds start at $1,900 for platform access, $3,800 to own your modules outright on a perpetual platform licence, and $14,400 for a full custom build with 100% of the IP assigned to you. Hosting from $99/month, optional maintenance from $175/month, changes at $125/hour. Nothing recurring starts until launch.

These builds usually justify full ownership, because inventory logic tends to encode the actual competitive advantage of a distribution business.

Tell us what the business does and what it has to accomplish. We will tell you honestly if a cheaper option fits you better.