Case Study · Sonic Drive-In · Internal Tooling

Building the tool that put
Sonic's menu in the app
from scratch.

Sonic had a new mobile app and no way to get a digital menu into it. After months of discovery, we chose to build rather than buy — and shipped a menu management platform that powered Order Ahead at national scale.

$2.4M
Budget owned and delivered
10+
Developers, BAs, and PM on the team
0→1
Built from scratch — no existing vendor solution
1
Platform powering Order Ahead across all Sonic locations
Brand
Sonic Drive-In
Role
Product Owner
Budget
$2,400,000
Scope
Internal Tooling, APIs, Menu Infrastructure

A new app — with no way to get
a menu into it.

Sonic had spent two years pushing hard into digital. They rebuilt their infrastructure and shipped a new mobile app with Order Ahead capabilities. It was a significant leap forward — except for one problem nobody had fully solved: how does a culinary concept become a digital product that a guest can actually order?

The gap between "item on the menu board" and "item in the app" wasn't obvious. A product at Sonic isn't just a name and a price — it's a web of relationships. Recipes. Build components. Nutrition data. Marketing categories. Images. Modifiers. Pricing rules. Availability windows. Each one managed by a different internal system, none of them speaking to each other.

"It took several months of discovery to put the puzzle together. The question wasn't just technical — it was: how does a culinary concept become a tangible product sold in a store, and how do we model that digitally?"

The answer required mapping the entire lifecycle of a menu item from the kitchen to the customer's phone. That discovery work became the foundation for everything that followed.

Build vs. buy — and keeping
scope under control.

The first major decision was whether to buy an off-the-shelf menu management solution or build one. We evaluated the vendor landscape and came back with a clear answer: nothing on the market could model the complexity of Sonic's menu relationships the way we needed. The build decision was made.

That decision came with its own risk — a blank canvas. Menu management tools have a tendency to become everything to everyone. Every team with a stake in the menu wants the tool to solve their problem. Scope creep in this context isn't just annoying. It's project-killing.

"I developed a set of guidelines to ensure the DMM was never responsible for anything but the menu at any given time. Data points like images and display rules are handled at another layer. The DMM owns the menu. That's it."

Keeping that boundary sharp was as important as any technical decision. The principle: the Digital Menu Manager manages menus, categories, and product placement. Rendering logic, display rules, and channel-specific behavior live elsewhere — in the layers that consume the DMM's output. Separation of concerns, applied at the product level.

Mapping dozens of relationships
into a single coherent tool.

The DMM's core job was to ingest data from multiple internal systems, map the relationships between them, and produce a decorated menu that channels — the app, the web, future digital surfaces — could consume. That sounds straightforward. The complexity was in the relationships.

Data Ingestion & Mapping
Pulled from recipes, build items, nutrition databases, and pricing systems — mapping dozens of relationships to construct a complete product record.
Consumer Decoration
Layered consumer-friendly data on top — product names, images, descriptions, disclaimers, and display metadata — without owning the rendering logic.
Menu Management
Controlled how menus were structured — categories, product placement, availability windows, and ordering — across all digital channels.

The architecture was deliberately layered. The DMM produced the menu. A separate rendering layer consumed it and decided how to display it per channel. This meant the same menu data could power the mobile app, the web, and any future digital surface without the DMM needing to change.

As Product Owner, I owned the full picture: requirements, acceptance criteria, infrastructure mapping, UI/UX feedback, vendor partnerships, and team management across a 10+ person squad.

8–10
Developers across frontend and backend
2
Business Analysts supporting requirements and documentation
1
Project Manager keeping delivery on track

The guiding principles I set for the tool kept the team focused through a project that had every incentive to expand.

The DMM owns the menu — nothing else. Display rules, channel behavior, and rendering logic live in consuming layers.
Don't let the blank canvas become a trap. Every feature request was evaluated against: does this belong in the menu manager, or somewhere else?
Build for the channel, not the tool. The DMM's success was measured by whether channels could reliably consume and render a correct menu — not by how many features the tool had.
Discovery before architecture. Months of discovery work preceded a single line of code — because the relationships had to be fully understood before they could be modeled.

The tech stack reflected the team's strengths and Sonic's infrastructure direction at the time.

React Java AWS GoCD

The missing piece — shipped,
on budget, and ready to scale.

The Digital Menu Manager shipped and became the backbone of Sonic's Order Ahead capability. It solved the core problem that had blocked digital ordering: getting a complete, accurate, decorated menu into the app in a way that could be maintained and updated without engineering involvement for every change.

Order Ahead launched in internal beta with a public release planned for early 2018. The platform was built to scale — structured so that menu updates, new product launches, and category changes could be managed by non-technical operators directly in the tool.

"This project taught me the most important lesson in enterprise product work: the hardest part isn't building the tool — it's understanding the system the tool has to model. Discovery is the work."

The build-vs-buy decision proved correct. No off-the-shelf solution could have modeled Sonic's menu relationships at the fidelity required. By building, the team produced a system that was purpose-built for Sonic's specific data model — and extensible enough to serve any digital channel that came after. $2.4 million. One platform. The foundation for Sonic's entire digital ordering capability.

Building something complex from scratch?

The build-vs-buy decision and the discovery work that precedes it are where I do some of my best work. Let's talk.

Connect on LinkedIn