- Role: Product Design (End-to-end)
- Product definition, UX, UI, system modeling, design system
- Product: B2B / Restaurant Operations / Ordering & Pickup
March 2020. Lockdown closed restaurant dining rooms overnight. The restaurants that survived had online ordering. Most didn’t.
The existing solutions weren’t built for them. Delivery platforms took up to 30% per order and required weeks to onboard. Custom systems needed technical resources most small restaurants didn’t have. And time was the one thing no one had left.
MESA was built to solve one problem: get any restaurant receiving online orders in under a day — with no platform dependency and no technical setup required.
In a crisis, speed to value is a design decision.
Designed to reduce decision friction by showing what’s available nearby, when it’s ready, and what users can do next.
The Problem
Small restaurants weren't losing customers because of their food. They were losing them because they had no digital surface. No way to be found, no way to take orders, no way to stay relevant the moment their doors closed.
The solutions that existed made it worse:
- Delivery platforms took up to 30% of revenue per order — unsustainable for thin-margin businesses
- Enterprise systems required IT setup, training, and integration timelines measured in weeks
- Generic e-commerce tools weren’t designed for perishable, time-sensitive, pickup-based orders
The hard constraint: restaurants needed to be operational the same day. Not in a week. Not after training. The day they heard about MESA.
Approach
The product couldn’t ask restaurants to learn new systems during a crisis. Every design decision had one filter: does this help a restaurant start selling faster?
Hide operational complexity
Restaurants run on urgency and routine — not software. Every UI decision that required learning was a barrier to adoption. The system had to behave the way kitchen staff already think: what’s available, what’s ordered, what needs to go out.
Start selling on day one
The product had to be valuable from the first minute of setup. No integrations, no configuration, no walkthroughs required. A restaurant should be able to add their menu and receive their first order within hours of signing up.
Make order state non-negotiable
If a restaurant or customer can’t tell the status of an order, trust breaks instantly. Timing, confirmation, and readiness were made explicit at every touchpoint — not inferred from notifications or follow-up calls.
For users
Customers browse nearby restaurants, see prep times upfront, and place pickup orders through a familiar checkout flow. No account requirements, no delivery complexity, no surprise wait times. The experience is intentionally narrow — because in high-friction moments, fewer choices drive more completions.
For Restaurants
Restaurants manage their full operation through a simple queue view — add menu items, set availability, accept or decline orders. No integration, no workflow changes, no training required. The design assumption: if it takes more than one day to learn, it won't get used during a crisis.
Key Tradeoffs
Every meaningful design decision involved a real trade-off between what would be ideal and what would actually be adopted in time.
- Speed over completeness. Early users got the core flow, not the full feature set. A restaurant online with 80% of the features is better than one still waiting for 100%.
- Predictability over flexibility. Fixed pickup times and explicit status states were less flexible than custom scheduling — but they prevented the support overhead that kills adoption in B2B tools.
- Local discovery over marketplace scale. No global catalog, no recommendation engine. Nearby, available, now — that's the product. Everything else was future scope.
- Direct control over automation. Restaurants toggle their own availability manually. That's a UX cost, but it builds operator trust faster than smart automation they don't yet understand or control.
Impact
No hard conversion metrics from this project — it launched during COVID and the team didn't have instrumentation in place at launch.
What was observable: restaurants that had never sold online were operational within hours of signing up. The onboarding friction that typically drives early churn in B2B tools wasn't happening — because we designed against it from day one.
The real measure: small restaurants stayed in business through lockdown who wouldn't have otherwise. That's the kind of outcome that doesn't fit in a dashboard — but doesn't need to.
Next Project
[ Aptoide Connect ]
