Inspiration

This project started with a problem I regularly run into myself.

As a college student, I like ordering takeout or delivery from time to time, but I also try to be as financially savvy as possible. Most of the time, that means ordering based on whatever deals are available rather than simply opening one app and picking the first thing that looks good.

The problem is that those deals, and even the restaurants available to me, are fragmented across different platforms. I often find myself searching through multiple apps, sometimes downloading another one just to see what it offers, looking through restaurant lists and promotions, rebuilding carts, and comparing final prices between platforms.

What should be a quick decision about what to eat can turn into a solid chunk of time spent figuring out where I can actually get the best value.

That led to a pretty simple question:

Wouldn't this be easier if all of this information was in one place?

Instead of searching through every platform yourself, what if you could search for whatever you're craving and immediately compare the restaurants, prices, deals, pickup options, delivery options, and total costs available to you?

It's a product I know I would genuinely use, and we realized this wasn't a hypothetical problem. It was a real problem we were already experiencing, so we decided to try to solve it.

What it does

Our platform brings restaurant, menu, pricing, deal, and ordering data from multiple sources into one place.

Users can search by restaurant, menu item, cuisine, or simply describe what they're craving. We match restaurants and menu items across different ordering sources and compare the available options, including menu prices, fees, promotions, pickup, delivery, and direct ordering.

The goal isn't just to answer:

"Where can I order this?"

It's to answer:

"What can I order, what deals are available to me, and what's the cheapest way to get it?"

Rather than opening several apps and manually comparing everything yourself, the platform handles the discovery and comparison in one place.

How we built it

We realized early that the interface wasn't going to be the hardest part of the project.

The data was going to be both our biggest challenge and our strongest differentiator.

The backend is primarily written in Go, with a shared Go data model that serves as the source of truth for restaurants, locations, menu items, prices, ordering options, deals, and the relationships between them.

We organized the platform into several focused components:

Web App for the user-facing search and comparison experience API / Engine for search, filtering, ranking, and price comparison Go Data Model (GDM) for the canonical representation of our restaurant and menu data Data Acquisition for collecting, parsing, and normalizing information from different sources Platform Contracts for defining how our services communicate Platform Config & Persistence for shared configuration and data storage Local Development for running the platform locally as a complete system

A major part of the project was building acquisition pipelines that could populate and update this shared data model.

We worked with the sources available to us, including restaurant and platform data, web content, promotional emails, and text message deals. Incoming information is parsed, normalized, and transformed into structured data that our system can compare.

For sources where continuous retrieval wasn't practical, we used rotating snapshots. This gave us a useful representation of the current ordering landscape while allowing us to build toward more automated and frequent updates.

We also designed the system with geography in mind. Restaurant availability, pricing, promotions, and delivery options are inherently local, so a user searching for dinner should primarily see relevant nearby results. The architecture supports eventually partitioning data geographically and routing requests to the appropriate regions.

Challenges we faced

By far, our biggest challenge was data acquisition.

A comparison platform is only useful when it has enough current information to compare. We quickly discovered that reliably acquiring this information was much harder than simply calling a few public APIs.

Many of the APIs we wanted were either unavailable publicly or required an application and approval process. That created a significant constraint during a hackathon, where we had limited time and couldn't wait for access to every source we wanted.

Our challenge became finding practical ways to build a useful data foundation despite those limitations.

We were able to collect enough web data to create useful snapshots of restaurants, menus, prices, and ordering options. We also built acquisition pipelines around sources we could process automatically. Promotional text messages, for example, can be parsed into structured deal information, while promotional emails can be processed and incorporated into the same data model.

Combining these pipelines with rotating snapshots allowed us to work with real data while building the foundation for more continuous updates.

Normalization was another major challenge. Each source describes its data differently. Two platforms may use different names, identifiers, structures, or pricing models for the same restaurant or menu item. Collecting the information is only the first step. We also need to determine what it represents and connect it to the correct canonical entity.

That challenge reinforced one of our original assumptions: data quality, along with the systems used to acquire, normalize, and connect that data, is a core part of the product.

What we learned

The biggest thing we learned is that the difficult part of a comparison engine isn't displaying comparisons. It's making the underlying data comparable in the first place.

We learned about building acquisition pipelines, web scraping, parsing unstructured promotional information, normalizing data from unrelated sources, matching entities across platforms, defining service boundaries, and designing a shared data model capable of representing all of it.

We also learned that when an ideal data source isn't available, several smaller sources can often be combined to create something useful. A web snapshot, an email promotion, and a text message deal may look completely different when they arrive, but after normalization they can contribute to the same picture of what options are available to a user.

Most importantly, building this project reinforced why we wanted to build it in the first place.

Today, the user is effectively the comparison engine. They open multiple apps, search multiple restaurant lists, find promotions, build carts, compare totals, and decide which combination gives them the best value.

We're trying to move that work from the user to the software.

A $15 meal isn't really $15 if it becomes $24 at checkout, and a great deal isn't necessarily a great deal if another platform, pickup option, or the restaurant itself can get you the same food for less.

We want to put all of that information in one place, save people money, and remove the tedious comparison work. Deciding what to eat should still be the fun, difficult part. We just want to make sure the difficult decision is about what sounds good, not about comparing menus, promotions, fees, delivery options, and checkout totals across multiple apps.