A wholesaler’s whole system, rebuilt in-house

Two years of order history, 27,185 lines across 4,768 orders, gave a clear answer. For the 31 resellers who ordered five times or more, 70% of every later order line was a product they had bought before.

So the store was asking the wrong question. A reseller opened a catalogue of about 2,000 products to find the 40 or so they always buy. The screen that follows is “Tavallinen tilauksesi”, your usual order: a standing list of what this store buys, sorted by how often and how recently, with the usual quantity filled in.

Two rules came from the data. Quantities are suggestions and never submit themselves, because quantity is where real money goes wrong. And the screen has to step aside honestly: one in six resellers buy something different every time, and a thin list would look broken to them.

I chose not to build a learned recommender. A few dozen resellers is far too little data, and a confident wrong suggestion costs a rep credibility.

The same data changed how I saw the move off the old shop. Only one of those 31 regular resellers had an account there, so the migration is really a sales job: winning 30 businesses Mikebon already sells to. The purchase tables come first, then the reorder screen.

It opens on a feed of the day. Which rep sent an order, who added display photos at which store, what the office took off a store’s shelf. Analytics answers the questions the owner actually asks: which stores have gone quiet, which carts are sitting unsent, and what people searched for and didn’t find.

A search with no result is a product somebody wanted, so that list sits next to the best sellers. A cart left for more than a day gets a red label, because it is an order that hasn’t happened yet.

The admin also did the slow rescue work from the old shop. 1,501 product photos came across through an import screen, and the official 240-code colour register now lives here, since the ERP has no place for it.

Several people use it, so access is deny-by-default. Each admin endpoint names the permission it needs, a new endpoint stays locked until it is listed, and a test fails the build if one is missing. Deletes go to an archive the office can restore from.

I made a shop a database record served through one page shell. An admin sets a name, a logo and one brand colour. From that colour the shell derives five tokens: the primary colour, a hover shade, two tints, and the text colour on the brand, white or near-black, whichever reads better. If no choice reaches 4.5:1, admin warns before the shop opens.

The trade-off was reuse against risk. The club shops share the styles and components of the business store but run on their own small script, so the live store resellers order from is never touched. Retail orders get their own collection too. A guest order mixed into business orders would leak into rep history, best-seller rankings and the office export.

Opening a shop is now something the office does in admin.

Before launch the shop went through a structured UI/UX review in three passes, on phone and desktop. I triaged its 78 findings, accepted 74 and built every one of them.

The top finding was measured. On a phone screen 844 pixels tall, the price started 760 pixels down, hidden behind the cookie notice on a first visit. The buy button sat around 1,100 pixels down.

On phones I moved the name and price above the photo, cut the top strip to one line and dropped the thumbnail row, since the photo already swipes. A slim bar with the price and “Lisää ostoskoriin” (add to basket) appears once the real button scrolls away. Desktop keeps its two columns, where the price was never the problem.

The physical layer matters as much as the screens. Every pallet gets an A4 sheet from the office printer, in a pocket facing the aisle: a huge pallet number, the arrival month in large print and a QR code. Each rack section has one code at eye height on the upright, so the driver scans from the floor and taps the spot on screen. That covers all 64 spots without a label up high.

My first version tracked pallets only, with no piece counts, because every extra field makes an update slower and slow updates are how records drift. Then the owner asked for a running stock count, so I changed my mind. Each line on a pallet now has a count, and one person can do the whole stock-take alone: scan the sheet, type what is on it, scan the rack.

Three groups use it differently. The forklift driver gets a tablet with three steps and big targets. Staff find stock on their phones, and search lists the oldest arrival first, so old stock leaves first. The office registers deliveries and prints sheets on a desktop. Everything is in Finnish, because that is the language on the floor.

I designed a weekly spot check and then cut it. What stayed is one list to clear every Friday: pallets that are missing or have sat on the floor too long. A failed save never disappears quietly. A red message stays on screen until it is retried.