Toprak — case study
Multiple roles, Legacy Systems, Excel sheets and produce that could vanish with nobody able to say whose job it was to notice.
I designed the multi-role, permission-managed system that makes sure someone always can.
Stakes
Every decision that determined whether Toprak made or lost money happened off any system
Toprak trades perishable produce: bought from suppliers worldwide, sold to wholesale buyers, on margins thin enough that one mishandled shipment can wipe out a week’s profit on that product. Before this platform, almost every decision that determined whether Toprak made or lost money on a trade happened off any system: a phone call, a paper receipt, an Excel row, a price quietly marked up with nobody downstream able to see it.
Perishables don’t wait. Stock that isn’t priced, tracked, and moved fast just rots, or disappears with no record of when or why — see: the 20kg of stock that went missing from a locked office, never explained, because there was nothing to check it against. The company’s own reference points, ISSAC and Ross-Tech, were themselves clunky. And the ambition was never just to patch Toprak’s own operation, it was to build something that could run 100+ wholesale trading businesses like it, each with their own suppliers, buyers, and staff.
Some of it did already run on a system, just a two-decades-old one. Salespeople worked a Motorola handheld with physical number buttons to log orders. Warehouse staff worked off desktop terminals that hadn’t changed since the software first shipped. That hardware wasn’t really the problem. The people running it had years of muscle memory built into exactly where every button sat. The problem was that nothing built to replace it had ever looked in that direction — they just assumed a screen and a redesign would be enough.
Context
Role
Solo product designer research, IA, and every design decision, working with a development team.
Client
Sasefied. Contracting for Toprak, a UK perishable-goods wholesaler.
Type
Multi-tenant B2B SaaS, meant to serve other trading businesses on the same system, not a one-off tool.
Status
In active development. FX and onboarding are built; core trading workflows are shipping module by module.
Insight
The riskiest thirty seconds in the whole trade weren’t on the sales floor, they were on the loading dock
The moment a shipment arrived and someone had to decide, on the spot, whether what showed up matched what was ordered — that was where the money the business was quietly losing actually disappeared: in shortages nobody logged, quality drops nobody priced, stock nobody flagged as unsellable until it was already a write-off.
Most systems in this space start by digitizing the sale. I started by digitizing that thirty seconds instead, because that’s where trust between supplier, wholesaler, and buyer was actually being tested, and where the old process had no answer at all.
Forks
Three decisions shaped the platform more than any others
Fork 1
What happens when a shipment doesn’t match the order
Auto-reject anything that doesn’t match
Pro
Simplest to build. Fully protects the buyer.
Con
Perishables that arrive slightly short or slightly lower quality are often still sellable at a fair price. Auto-rejecting them burns margin the business can’t spare.
Killed
B . Free-text note, resolved offline
Pro
Fastest to ship, no new screens.
Con
This is the old Excel problem, just moved into the app. No financial trail when a dispute resurfaces weeks later.
Killed
C . Branch by outcome into structured paths
Pro
Preserves margin on stock that’s imperfect but still sellable. Creates an auditable record for every dispute.
Con
More states and screens: quantity mismatch routes to a credit note, quality issues route to a price renegotiation and a separate inventory tag, wrong product routes to return-to-sender.
Shipped
Fork 2
Who gets to see the real numbers
A . One shared view for every role
Pro
Simplest to design and maintain.
Con
Exposes markup and margin to roles that shouldn’t see it - cashiers and pickers don’t need to know what a supplier was paid. A real business risk.
Killed
B . Nine separate apps, one per role
Pro
Maximum control per role.
Con
Nine copies of the same order state, built and maintained separately, drift out of sync with each other. That’s the exact failure mode of the old process, just automated.
Killed
C . One transaction model, two view modes, permission-gated
Pro
Keeps margin data restricted to roles that need it, without splitting the underlying data.
Con
Requires the permission model to be right from day one, which takes longer to design up front.
Shipped
Fork 3
Replace the interaction pattern outright, or carry it forward
A . Clean-slate modern UI, ignore the old hardware
Pro
Fastest to design. No legacy constraints, best-practice patterns throughout.
Con
Every salesperson with years of muscle memory on that button layout has to relearn order entry from zero, on a live trading floor, no ramp-up.
Killed
B . Recreate the Motorola’s exact button flow on screen
Pro
Zero relearning. Staff feel instantly at home on day one.
Con
The old flow was built for a 4-line screen and physical number keys. It wasn’t built for speed, for two people working the same order, or for a much bigger catalog. Copying it exactly copies its limits too.
Killed
C . Preserve the sequence, rebuild the interface
Pro
Keeps what actually mattered — the mental model, not the plastic buttons — while gaining screen size, speed, and far more product and pricing context on screen at once.
Con
Took longer to design, because it meant sitting with actual salespeople and store managers to learn how they think through an order, not just screenshotting the old software.
Shipped
a command line for the people who didn't need the buttons slowed down
Fork 3 solved for staff rebuilding muscle memory. It undersold the ones who weren't slow on the old hardware, they'd just compressed the whole order into one motion. For them, I added a single typed field: "AAPL 3000 units buy" gets parsed with NLP into product, quantity, and side, and comes back as a one-line confirmation before it becomes a real order. Same underlying flow as the tap version, same confirm step, just typed instead of tapped, so the fastest people on the floor aren't held to the pace of a screen built for everyone else. inspired by interaction design in Todoist
Craft
Where the decisions landed on screen
A buyer either enters a price already agreed by phone, or requests a quote and the order visibly sits as “requested, not yet priced” until the supplier responds. The order list never implies a deal is done before it is.
What actually arrives, not what was ordered, is what the stockman logs — and that’s what flows into inventory and accounting from that point on.
Client birthdays, anniversaries, and price drops sit next to falling order volumes and repeatedly delayed suppliers, so the sales team has a reason to act before a relationship or a shipment goes bad.
One search, by client name, surfaces every open order, the previous day’s balance, and today’s total due: cash, cheque, card, or credit.
Struggle
The permission model didn’t arrive cleanly
An early version let an admin edit several users’ roles and access at once, batch-style. That fell apart fast: changing multiple people’s access to pricing and cash-handling permissions in a single action is exactly the kind of change that shouldn’t be easy to make by accident in a system that touches real money. It got rolled back to single-user edits only — deliberately slower, deliberately harder to misuse.
The harder edge is stock that’s rotten, lost, or expired. Which role writes it off, whose numbers absorb the loss, does it need its own status or can it fold into “poor quality” — those questions stayed open longer than anything else in the system. They still aren’t fully resolved.
Proof
Honest, not impressive yet
The platform hasn’t shipped in full, so there’s no adoption curve or before/after number to point to here. What’s actually true right now: nine distinct roles — supplier, wholesaler admin, salesperson, buyer, stockman, cashier, accountant, operations, picker — are designed around one shared transaction model instead of nine disconnected ones. FX and onboarding are built and in use. Buying, selling, and the dashboard are being refined against real trading edge cases as Toprak’s own team runs them: slower than shipping a finished vision in one go, but it means every flow above has already survived contact with an actual trade.
After
What I’d do differently, and what’s next
If I rebuilt this from scratch, I’d design the receiving and permission model before touching a single buying or selling screen, not after. That’s where the highest-stakes decisions turned out to live, and I only found that by building the sales-first version first. Next: finishing the buyer workflow, closing out the rotten/lost/expired question properly, and testing whether the gross/net view split still holds once a second trading client, not just Toprak, is running on it.
Ownership
I owned the research, information architecture, and every design decision on this project end to end, working alongside a development team building it out. The platform is still in active design: several modules are built and in use, most are being refined client by client as real trading edge cases surface.