Pivot
Locale 2.0
Pivoting to prepared meals to save the business.
- ARR
- $6M
- Restaurants
- 50+
- Model
- Subscription
Context
Long-term retention dropped from 15% to 8% when covid ended. We were burning more than $600K a month trying to grow a marketplace that didn’t have a real PMF.
After digging through our data, we learned that our best customers were ordering prepared meals over one-off items like baked goods and flowers. It made perfect sense: how often are you going to order a croissant in a month versus a meal you can actually eat for dinner?
We moved toward an opt-out subscription model built around prepared meals. Recurring revenue, recurring customers, and a reason to come back every week instead of every once in a while.
The pivot
Before committing, we had to figure out and understand what we were actually pivoting into. So we conducted a PMF survey and talked to over 100 existing customers who were ordering prepared meals.
What we heard over and over was that people were tired of how much they were spending on DoorDash.
We already knew how to deliver from multiple vendors in a single order — it was the core of the original marketplace. If we applied the same model to restaurants, but bundled it into one weekly delivery of prepared meals, we thought we could undercut on-demand delivery on pricing.
The logistics also worked in the restaurant’s favor. Batching everything into one weekly order meant they had time to prep, cook in bulk, and schedule efficiently instead of cooking on demand.
Rebuilding the platform
This pivot snapped the Webflow camel’s back because it couldn’t do two things (cleanly) that the new model required: native user accounts and robust order management. We needed a better solution.
We settled on Shopify; however, due to their lack of customization for non-technical users, we had to bring on a contractor who knew Shopify’s templating language to help us customize the front-end functionality.
This let me step back into Figma for the first time in 3 years. It was sparingly used for 1.0 due to the speed we needed to ship at — most of that site was designed in the browser. It allowed for clean documentation of the design system, flows, and let me sharpen my hand off skills.
Unfortunately the contractor didn’t end up as a viable long-term solution for us. Output was slow and the code was unmaintainable. Waiting on them became the bottleneck for the entire front end, so we eventually let him go, which left a gap I had to fill myself.
Learning to code
So I learned to code!
With the contractor gone and a front end that still needed building and iterating, I taught myself enough to start shipping — with help from one of my co-founders who took on the backend. Everything I’m showing on this page is my own work on the front end.
Over the last year of Locale 2.0, I built and rebuilt landing pages, ran A/B tests, and shipped systems that made the subscription product work: the filtering system for meal discovery, the meal review system for returning customers, the accounts experience, and a dashboard for managing orders across different delivery days.
It was the moment the design-engineer path stopped being a distant dream and started being something I could see myself executing on.
Impact & retrospect
By the end, I was designing and shipping my own work on the front end. The thing that started as a crisis became one of the most important skills I picked up at Locale.
But the product never fully found its footing. Locale 2.0 was always searching for a better PMF, and our only real edge was being the cheapest way to get good prepared meals from restaurants. We told ourselves the convenient truth that “margins will get better with scale” — and they didn’t.
$6M
ARR
50+
Restaurants
$200K+
Monthly burn