Where they started
Biopet had the hard part solved already. Real demand, repeat customers, a catalogue people came back for. Pet supplies are one of the most reliably repeating purchases in retail, and Biopet had built the local trust that makes that repeat happen.
None of it lived in a product. Orders arrived across whatever channel a customer happened to use. Stock and pricing lived in spreadsheets. Somebody on the team was manually reconciling the two every day, and that person was the single point of failure for the entire business.
So the brief that arrived was we need a mobile app. That is almost always the symptom rather than the diagnosis. An app on its own would have moved the ordering chaos into a nicer container while the team behind it kept working the same way, and the first busy week would have broken it.
Why one team for all three
We pushed the scope in the first conversation and we were direct about why. A customer app, a storefront and an internal dashboard are not three projects. They are three views of the same catalogue, the same order, the same customer. Design them separately and they disagree, quietly, in the places that matter: a product has a field in one place and not another, an order status the customer can see has no equivalent the team can set, a discount rule that works on the site and cannot be created anywhere.
Splitting the work across vendors is how that happens. One team designing all three meant every object in the system got defined once and then appeared in three appropriate forms. That is the whole reason the scope grew, and the team agreed to it before we designed a single screen.
What we designed
Objects before screens
We started with the objects, not the layouts. Product, variant, order, customer, delivery slot, promotion. What each one holds, what states it moves through, and who is allowed to change it. One page of decisions that every later argument got settled against.
The customer app
Designed around one job: reordering with as little friction as possible. Pet supply buying is habitual, so the interesting screens were not the browse and discover ones. They were the ones that get a returning customer from opening the app to a confirmed repeat order in a few taps, with the previous order right there rather than something to go looking for.
The website
Built on the same visual system and component logic as the app, so a customer moving between phone and desktop never felt a seam, and so the team would not be maintaining two unrelated design languages forever.
The admin dashboard
Last to design and first to matter. This is the interface nobody screenshots and everybody uses eight hours a day. We designed it for the actual worst moment rather than the demo: a busy afternoon, several orders in flight, a stock discrepancy, one person handling it. Bulk actions instead of one at a time. Order status editable from the list view, not three clicks deep. Low stock visible without going to look for it.
Handoff that does not stall
Everything shipped as a component library with real states documented. Empty, loading, error, and edge cases like an out of stock item inside an otherwise valid order. That is the difference between a build that moves and a build that pauses every time developers hit a case the designs had skipped.
The result
Biopet went from an operation held together by one person and a spreadsheet to a product where the customer side and the internal side describe the same reality. Repeat ordering became a few taps instead of a conversation. The team stopped reconciling channels by hand.
The numbers followed the structure. Sessions run 35% longer on average and bounce rate is down 25%, which is what happens when a returning customer finds their last order on the first screen instead of going looking for it. In-app purchases are up 20%. Post-launch satisfaction sits at 4.6 out of 5. And the design system paid for itself on the build side rather than only the design side: the dev team ships roughly 30% faster working from documented components and states than it did before.