Case Study
Preparing for Scale (Part I)
Mula is a B2B SaaS platform that helps companies streamline their merchandise operations. The mission was to prepare the company for European expansion.
Role
Product Design Lead
Duration
2022–2023
Teams
Design, CS, Sales, Supply Chain, Warehouse
Context
Mula had been growing steadily without funding through a period of high demand for branded merchandise. By mid-2022 a competitor had acquired a 25% stake with an option to complete the purchase, valuing the company at €40 million. The European expansion had a timeline. Thirty people and a platform that had grown faster than the processes supporting it.
Two fronts needed work before scale was viable: operations, and the customer experience. Operations first. Expansion without a stable operational foundation would have multiplied the failures customers were already seeing (late deliveries, missed deadlines, broken handoffs) across every new market we entered. This case is the story of that first phase.
No Single Source of Truth
Stakeholder interviews in my first weeks revealed that no two teams described the order lifecycle the same way. Inconsistent answers about the same process mean one thing: no single source of truth. I mapped the full order lifecycle across all five teams involved.
What came back wasn't fixable at the surface. Critical processes were running off-platform. Spreadsheets and Slack threads were compensating for gaps. This led to broken handoffs, unclear ownership, and operational failures that customers felt directly: delayed ETAs, missed deadlines, and, eventually, churn. At the current volume, the workarounds were manageable. At the next, they would compound.
01
Off-platform processes
Critical approvals and order tracking ran through Slack, email, and spreadsheets. No visibility, no single source of truth.
02
Unclear ownership
More than one person was considered responsible for the same step. In practice, nobody owned it.
03
Wasteful manual processes
Production specifications created manually. Order status maintained by hand across five teams. Every change meant rework.
Ownership was clarified during the mapping itself. Walking the broken steps with each team surfaced where responsibilities were unclear, and a single owner was assigned per process.
Standardizing the Design Phase
Production specifications were the manual process that touched every order. Different suppliers handled different product types and required different specifications. Designers maintained the templates by hand in Photoshop, rebuilding spec sheets per supplier per order. It worked at the current volume. It wouldn't at the next.
The decision was to stop accommodating each supplier's preferences and design one scalable format, agreed with the producers we worked with.
The intervention was closing the platform's configuration gaps so the specifications sheet could generate from platform data instead of being assembled in Photoshop.
No One Could See the Full Order Lifecycle
Order monitoring had three structural gaps: no consolidated view of the lifecycle, no early warning when a milestone was running late, and no preserved baseline for performance.
01
No traceability
When something went wrong, CS and Sales reconstructed history from Design briefs, HubSpot, Slack threads, and spreadsheet comments. No single record existed.
02
No early warning
The platform showed green until the ETA had already passed. No team could tell at a glance whether their part of the order needed steering.
03
Invisible performance
The platform stored only the current ETA, never the original. Every update moved the goalposts. There was no way to distinguish client-caused delays from operational failures.
To compensate for these platform gaps, five teams maintained a shared spreadsheet across the organisation, updated daily by hand. The workaround surfaced what was missing, and added problems of its own.
04
Duplicated effort
Every update had to be made twice: once in the platform, once in the spreadsheet. Five teams, every order, every change.
05
Always out of date
Updates were time-consuming so teams batched them. By the time status was logged, it was already lagging behind reality.
The Solution
The objective was to retire the spreadsheet by closing the gaps that had forced it into existence: a consolidated view of the lifecycle, early warning of milestone delays, and a preserved baseline for performance.
A unified timeline view
The spreadsheet was replaced by a unified timeline view, embedded in the order detail page and across all its instances. The view extended a chat surface that already existed in the platform, adding system events alongside the human comments it carried. Every event, ETA change, and team update now lives in one place, in chronological order. CS and Sales can reconstruct the full history of an order without leaving the platform. Supply chain and warehouse teams can spot which of their instances need steering at a glance.
Earlier warning signals
With every milestone now visible in one place, the traffic light could move from order-level to milestone-level. Yellow flags any phase running behind in a way that threatens the final ETA, surfaced on the list view weeks before the deadline. A delay in Design propagates to downstream instances automatically. Every team sees it without opening the order.
Measurable on-time performance
The original ETA is now preserved alongside the current one. Deviations are visible. Delays are attributed as client-caused or operational. For the first time, the business could measure its real on-time performance, understand why orders were late, and act on it.
The Outcome
| Before | After |
|---|---|
| Order lifecycle lived in spreadsheets and Slack | End-to-end process traceable on-platform |
| Customer Success blind to developing delays | Delays caught internally, before client impact |
| On-time performance measurement was broken | Real ETA performance visible for the first time |
Closing
Scale isn't something you add to a company. It's something the systems either support or don't. What customers experienced as delays came from an order lifecycle spread across spreadsheets, Slack threads, and five teams each holding part of the picture. Making it visible made it fixable. That's most of what designing for scale actually is.
Part (II): The Self-Service Platform. With the foundation stable, the customer experience work became the priority: redesigning the platform to do what the team had been doing manually. A separate case is in development.