Stockpilot

I didn’t interview a hundred merchants for this, and I’ll say so plainly, because the honesty is the point. What I did: build a working persona, pressure-test her until she was real, and ground the product in what I know about how commerce operations run.

Rina. A solo merchant on a platform like Salla. Tight, revolving cash. Sixty to eighty styles. She checks her phone between school runs, and she doesn’t want analytics, she wants to know what to do next.

The first version of her was too easy. Eighty simple products? A seasoned merchant holds that on her fingertips, and AI is solving a problem that doesn’t hurt. So I broke her on purpose: I gave her variants, sizes, colours, verticals. Now she is tracking hundreds of SKUs, a “bestseller” might be selling only in medium-black while small-white rots, and the money is trapped where she can’t see it. That is where AI earns its place.

A persona you can’t break is a persona that flatters your idea. This one had to survive being difficult.

The obvious problem is prediction: what will sell. The real problem sits underneath it. She can’t stock everything, so every restock is a bet with money she can’t afford to lose. This was never a forecasting product.

Money first. That one line shaped every screen after it.

Before designing a single screen, I made the product earn its premise. If a static chart or a simple rule would answer the question, AI is decoration and it should go. It survived for one reason: the job is synthesis and judgement over messy, shifting, SKU-level data. Spot the pattern, project the week, weigh it against a budget. That is the thing a dashboard can’t do and a person can’t hold.

I designed Stockpilot the way I built this portfolio: in a long conversation with AI, where the model moved fast and I held the bar. It generated options and rendered working prototypes in minutes. My job was the judgement. What to keep, what to kill, and when something honest-looking was actually a lie.

The AI leaned toward letting the merchant set a budget range. My first instinct agreed: businesses run on flex. Then I caught the real cost. A range makes her decide two numbers instead of none, work handed to the person least able to spare it. So she sets one soft cap, and the AI does the range-thinking. As she drags a slider, the mix updates live and tells her the truth: “stretch to 3,400 and I’d add more of your fastest mover,” or “you only need 2,600, keep the rest in reserve.”

Confirming a reorder needed to do something. The easy answer was a “Send to supplier” button. I killed it. I know how small suppliers work: WhatsApp, a phone call, a walk-in, a scribbled note. There is no standard channel, and the app has no way into that relationship. So the app compiles a clean reorder list and hands it off, copy, share, or download, for her to route her own way. The app thinks and compiles. The human transacts.

We had a “Mark arrived” button on incoming orders. I stopped on it. If the app is synced to her inventory, why is it asking? When stock arrives, the count jumps, and the app sees it. So arrivals are sensed, not reported, and the app only asks when its own eyes and the expected date disagree. Sense confidently. Ask only when unsure. Always leave a fallback.

The forecast could be a threat (“runs out in 2 days”) or an opportunity (“you’ll likely sell 28 next week”). I chose by context. On the urgent alert, pressure is the point. In the planner, where she is deciding how to invest, pressure is wrong, so the same velocity becomes opportunity. One number. Two feelings. Picked on purpose.

This is an exploration, so the honest next step is real users, not more of my own reasoning. If I took it further, here is what I’d put in front of actual Salla and Shopify merchants:

I know the standard process: interviews, first-click and comprehension testing, a diary study on the daily loop. I didn’t run it here because this was an exploration, not a product build. Naming what I’d test isn’t a caveat. It is the difference between a designer who explores and one who guesses.

It assumes an integration I didn’t design. Stockpilot only works connected to the merchant’s platform for stock and sales data. That connection is an engineering problem, not mine. What was mine was designing around its realities: stale data, the offline gap when she reorders elsewhere, and what the screen shows when the data isn’t there. And a working prototype is the honest medium for an exploration. The whole story is “problem to clickable in days.”

The hard part of AI-native design isn’t making the AI look smart. It is knowing when it should act and when it should ask. When to show its work and when to stay quiet. When a helpful-looking feature is actually a promise you can’t keep. The model gave me speed. It could not give me the merchant’s world, the taste to keep things calm, or the instinct to kill my own clever ideas. That part is still the designer’s. It might be the part that matters most.