Breadstack Unification
Six years at Breadstack, from founding designer to Product & Design Lead. This page is about the six months in the middle that mattered most — merging three separate products into a single platform, and then learning how much of it to take back out.
Project
Saas
Role
Product Design Lead
Product Operation Manager
Year
2023
Breadstack
Breadstack is a B2B2C e-commerce enabler for cannabis retail. It syncs inventory straight from a store’s POS system to their own storefront, so retailers keep their brand, their customers and their data instead of renting space inside someone else’s marketplace.
Problem
By the time the market was ready for us, we were not one product. We were three: an e-commerce platform, a live chat tool and a delivery system. Each had its own tech stack, its own settings and its own visual language. You cannot ask a retailer to onboard three platforms at once, and you cannot sell three platforms at once either. Apart, none of them was quite enough.
Mission
Merge the three into one product a retailer could buy once, learn once and run from one place — without rebuilding any of them from scratch. We had six months.
Why Unify
Too Big to Explain
Design work was light that year, so the team made its own. We kept circling the same question in our sharing sessions: why would Breadstack not sell? My honest answer was that I could not say who it was for. So I worked backwards — took the features we had already built and reverse-engineered them into a person and a situation. The conclusion was uncomfortable and useful. The product was not wrong. It was unsellable because it was unexplainable.
The Proof
We presented a tiered concept — a platform that grows with the business — and it landed well, then sat. What actually moved things was a retailer from our stakeholders’ circle going live on the old platform a few months later. The integration was held together with tape and they complained constantly. They also kept using it, because nothing else on the market did the job. That was the proof we needed: the demand was real, and the obstacle was the shape we were selling it in.
Three Hard Problems
A Design Language in a Week
Every other designer was waiting on me, so I gave the design language one week. I did not call it a system — it was a guideline, and it only had to settle font, colour, grid and tone. I worked it out on three real pages instead of in the abstract: a live chat screen because it was the odd one out, a product detail page as the most common detail view, and a listing page as the most common page in any SaaS product. If it held on those three it would hold everywhere. The one principle I refused to trade was modularity. Our chat product had been designed as a single integrated piece, and adding anything to it later meant redrawing around it. This one had to absorb new modules without being redrawn.
One Product From Three Stacks
The three products sat on three different tech stacks. Merging them properly meant tearing them down and rebuilding, which did not fit inside six months. So we solved it in the interface instead. A bundle menu of three icons sits beside the main navigation — E-commerce, Live Chat and Delivery, renamed out of their old product identities. Clicking one actually sends you to a different domain. They share a visual language, a navigation pattern and a loading state we designed deliberately to carry the seam, and the result reads as one piece of software. Engineering, product and design landed on it together: the merge was achieved by design rather than by a rewrite.
Settings That Belong to No One
Each product arrived with its own settings, written for different users doing different jobs. The obvious answer is one group per product, and it breaks immediately, because after unification a great many settings sit above all three — users, permissions, onboarding. They belong to no single product. We studied how other multi-product suites handle it, then stopped respecting the product boundaries altogether: break every setting into pieces, and regroup the pieces by what belongs together in the user’s head rather than by which product it came from.
After Launch
Less Than We Built
We shipped, and then we watched. Usage data and support conversations kept saying the thing the word enabler should have told us earlier: retailers wanted the job enabled, not a wall of features. Whole areas we had carefully built were going untouched, and the scenarios some of them assumed had quietly stopped being true.
Tracking the post-launch UI cleanup, module by module
Taking Things Out
The warehouse module is the clearest example. Transfers in and out, SKU management, adjustments — genuinely complex, and effectively unused. We removed it. Removing is harder than adding: a feature at the edge of a product comes out cleanly, but one wired through the middle moves everything it touches. So we worked through them in order of how deep they sat, and held each removal to the same bar as a new feature — evidence first, then a plan for the people already on that screen.
Fulfillment Becomes an Order
Fulfillment had shipped as its own module, and every interaction in it assumed volume — bulk select, bulk process, bulk print. In cannabis retail nobody works in bulk. One order is one order. So we dissolved the module and moved every fulfillment action inside the order itself. It was not only simpler, it was more accurate to how the work gets described. To a store, it is not fulfillment. It is an order that needs processing.
Outcome
Breadstack became the second-largest cannabis e-commerce platform in Canada, serving 40+ enterprise clients across 100+ locations. Three products became one that a retailer buys once and runs from one place — and the version they run today is smaller than the one we launched. Unification landed while the market was still open, and that timing is most of the story. It gave Breadstack the ground to stop being a single platform and become a retail ecosystem.
Six Years, in Short
I was Breadstack’s founding designer on Day One and left as Product & Design Lead, having built and run a team of six across Vancouver and Hanoi. This project is the one that changed how I work. Seniority turned out not to be choosing which feature to build, but the when and the how — and increasingly the whether. I stopped thinking in screens and started thinking about the whole arc of a decision: what it does to positioning, to the people who have to sell it, to the people who have to support it, and to the product a year after it ships. The most useful skill I came away with was knowing how to take something out.
Some Screens
Breadstack Core - Product List
Breadstack Core - Product
Breadstack Core - Order
Breadstack Core - Workflow Automation
Breadstack Core - Live Chat
Breadstack Core - Visitor Tracking
Breadstack Core - Location Setting
Breadstack Core - Integration
Next
Chatso
