Building an ERP for a Building Material Store

A building material store does not look like a typical retail business. Products are sold by the meter, sack, or piece. Supplier prices change. Reorders depend on both demand and remaining stock. And at the counter, customers are not waiting.

Here is how we turned those workflows into an ERP.

Start by walking the floor

Before writing any code we spent time understanding how the store actually operated: who enters a sale, how stock is counted, how purchases from suppliers are recorded. The store’s real workflow — not an idealized retail model — became the blueprint for the system.

Sales and stock in the same breath

The critical connection in any inventory system is between a sale and what it removes from stock. We made sure every sale decrements the right stock record for the right unit of measure, because “5 sacks of cement” and “12 meters of pipe” do not behave the same way.

Reordering that follows the business

We added reorder alerts based on minimum stock levels set per product. When stock drops below a threshold, purchasing can see exactly what was sold, how much is left, and who they usually buy from — so the reorder decision stays a business decision, supported by data.

Purchasing as part of the story

Purchases affect stock levels, which affect what is available at the counter. We treated purchasing and sales as two sides of one system rather than separate modules, so stock balances always reflect reality.

The lesson: workflows before features

The biggest lesson was to resist starting with a feature list. Every genuinely useful module in that ERP — point-of-sale, inventory, purchasing, reporting — came from a real workflow we had to support, not from an assumption about what a store “should” have.

We wrote more about how to design these systems in Designing Better Business Management Systems.