WorkInventory system
Appliance parts distribution
Stock, purchasing and point of sale for a growing parts distributor
One system for stock, purchasing, sales and accounts across a parts distributor’s storefronts, built because manual data handling stopped scaling with the business.
- Client
- Confidential — appliance parts distribution, US
- Engagement
- Project delivery
- Duration
- Ongoing since 2018
- Team
- 4–5 engineers
- Core stack
- PHP / Laravel, Vue.js, MySQL on AWS
The situation
What the organisation was trying to do
Two brothers founded the business in 2017, after ten years in the appliance repair parts trade. They knew the trade first-hand, and the business was built on knowing what a customer actually needed. Growth is where it started to cost them: orders, stock counts and sales records were still moved by hand, and that handling took time the pair no longer had. Answering a plain question — what is in stock, what has been ordered, what is owed — meant assembling the answer from several places at once. They came to us for an inventory system, on the recommendation of another client whose inventory project we had already delivered, so the brief arrived with its expectations already set.
What made it difficult
The constraint that shaped everything
There was no clean source of truth to migrate from. Stock lived in one spreadsheet per storefront, purchases in a shared inbox, and the sales record in the till’s own export. The three disagreed with each other most weeks, and nobody could say which was right. The business also could not stop trading while we sorted it out: both storefronts sold every day, and a wrong stock figure at the counter costs a sale or a return. So the system had to go live location by location, with the old spreadsheets still running alongside it until the counts matched for four consecutive weeks. The first migration took longer than the build of the module it fed, and that was the right order to spend the time in.
What we built
The approach, and the trade-offs we took
The system is organised around locations. Each storefront holds its own stock and its own accounts: purchases, sales and expenses are recorded against the location they happened in, rather than pooled company-wide and split back out for reporting. Everything else follows from that, because it is what makes the stock figure and the money figure agree at the level a manager asks about. Products carry a classification, a unit, an SKU and a stock level, and the selling price is derived from a configured margin rather than typed in per product. Purchases record their tax and discount and carry a paid or due state, with a notification when a payment comes due. Sales run from a point-of-sale screen that pulls the customer’s details in as the sale is rung up, drafts an invoice before issuing a final one, and hands off to one of several payment gateways. Around that sits what a distributor needs in order to trust the numbers: supplier and customer records with their transaction history, pay terms and payment alerts; expenses categorised and reportable by location; and reports for purchases, sales, tax, stock, expenses and contacts. Users are created with roles, and the role decides both what someone may do and what their dashboard shows them. Currency, timezone, financial year, tax groups and barcode format are configuration rather than code, because a business opening locations changes those first.
Outcome
38%
Fewer order errors
Baseline nine months of manual order records · measured over the first quarter after go-live
6 h → 40 min
Weekly stock reconciliation
Baseline a manual count across both storefronts · measured over the twelve weeks after go-live
2 days → same day
Month-end close per location
Baseline the previous financial year · measured over the first two quarters after go-live
What we would tell you
If you are considering something similar
Reconcile the data before you build anything on top of it. We started the purchasing module in parallel with the stock migration, and it sat finished for six weeks waiting for counts it could trust. If we did this again we would run the old spreadsheets alongside the new system for longer than felt necessary, and we would set the per-location accounting model on day one rather than discovering it was needed at the first month-end.
Really, the best talents I have hired so far! I hired them to develop my Inventory Software and they did a great job. Always in for Feedbacks and reflected the best outcomes. The final result is perfect! I like it!
Tell us what you are building.
A 30-minute call with an engineer who will work on it.A 30-minute call with an engineer who will work on it. No sales sequence, no obligation.
Book a consultationor email us directly