A table and a search box

We built a shop for Fredparts — website, full backoffice, the lot. Then their salespeople asked for something we hadn't planned: a price list they could search while standing in front of a customer.

The data already existed. The backoffice could show every product, every price, every property, and it could filter them. On paper the feature was done. In practice it was useless for that job. A salesperson on a phone had to log in, navigate, wait for a page built to manage products rather than read them, then scan past a dozen fields he didn't care about. The answer he needed was two taps away and thirty seconds too slow.

So we built the smaller thing. Which turned out not to be a small thing to build.

All the machinery sits in the backoffice. The admin picks which price type the list uses — so the same tool produces a dealer sheet at wholesale prices and a customer-facing catalog at retail prices, from the same products, at the same time, without either audience seeing the other's numbers. He picks which fields appear: part number, brand, stock, whatever that audience needs and nothing it doesn't. He can switch images on, which turns the same table into something you can hand to a customer to browse. He sets a password. Then he gets a link.

What comes out is one page. A table in the middle, a search box above it, instant filtering, nothing else. No navigation, no dashboard, no logo. The search is fuzzy, so a half-remembered part number or a typo still finds the row — which matters more than it sounds, because nobody types a part number correctly while a customer is watching.

The page lives at an unguessable URL, isn't linked from anywhere, and stays out of search engines. It asks for the password once and remembers it, so nobody is typing a password in front of a customer either.

At first glance it looks too plain to be a feature. The page is plain. What produces it isn't. And plain is the requirement, not a compromise. It replaced Excel and Word files that went stale every time a price or a stock count changed — files that got copied, emailed, and quietly kept in use months after they were wrong. The page has no copy to go stale: it reads the live numbers from the shop and from their accounting system, so the price a salesperson reads out is the price in the books. From the conversation to the live page took a day.

"We wanted to build a new system for the salespeople. Now we just use this page — it reads our live data from the website and the accounting system." — Vafa, Fredparts

What we actually took from this: "the feature exists" and "the feature is usable" are two different sentences. The backoffice answered the question the business had. It didn't answer the question a salesperson has forty times a day. Nothing in the data model tells you about that gap — you only find it by asking what someone does, minute by minute. Fredparts came to that conversation ready to pay for a whole new system. What they needed was one page reading the data they already had.

That's the hardest part of this work, and it isn't technical. The client describes a business problem. We hear a programming problem. He says "I need the prices somewhere they can see them," we hear "add a page," and neither of us notices we pictured two completely different things until it's built and wrong. So we talk it through, repeat it back, and ask what a normal Tuesday looks like. Every hour spent there is cheaper than the week spent undoing a guess.

If something in your business still runs on a spreadsheet that keeps going stale, tell us about it. We'll get on a call and work out what the small version looks like.