DEV Community

racioteka
racioteka

Posted on

I built a comparison catalog for meal delivery in Ukraine - and stopped opening 20 browser tabs

Choosing a meal delivery service (ready-made rations) in Ukraine used to mean opening 20+ websites and comparing them manually: price per day, calories, delivery zones, diets, goals. Every service has its own menu format, its own pricing logic, its own definition of "one meal". It's a classic directory problem.

So I built Racioteka — a catalog that aggregates dozens of Ukrainian meal-delivery services in one place, with filters by city, goal, diet and calories, plus a calorie calculator and a side-by-side comparison tool.

Here's what I learned building it.

The problem: everything is "almost comparable"

The services are similar on the surface: daily rations, X meals per day, Y kcal, delivered in the morning. But the details are messy:

  • Pricing: some quote per day, some per week, some per "program". One service includes delivery, another adds it at checkout.
  • Calories: ranges like "1200–1500 kcal" vs exact numbers.
  • Meals: 3, 4, or 5 meals per day — and "snack" means different things to different brands.
  • Diets: keto, vegan, gluten-free, lactose-free, sugar-free — with overlapping definitions.

The core engineering task was normalization: mapping all this chaos into a single schema.

// Simplified normalization shape
const service = {
  name: "Example Food",
  city: ["kyiv", "lviv"],
  pricePerDay: { min: 420, max: 850, currency: "UAH" },
  calories: { min: 900, max: 3000 },
  mealsPerDay: 5,
  goals: ["weight-loss", "fitness", "detox"],
  diets: ["keto", "vegan", "gluten-free"],
  delivery: { free: true, zone: "city + suburbs" }
};
Enter fullscreen mode Exit fullscreen mode

Once you have a clean shape, everything else becomes easier — filtering, sorting, comparing.

The filters that matter

Users come with different intents. The filter set we settled on:

  • City — most services are local (Kyiv, Lviv, Odesa, Ivano-Frankivsk...). A national catalog without city filtering is useless.
  • Goal — weight loss, maintenance, muscle gain, detox, medical nutrition.
  • Diet — keto, vegan, vegetarian, pescatarian, gluten-free, lactose-free, sugar-free.
  • Calories / price — the two numeric dimensions everyone compares.

Nothing revolutionary — but getting the category taxonomy right is 80% of the product. We iterate on it constantly.

The calorie calculator

A common question: "How many kcal do I actually need?" Instead of making users guess, we added a calculator based on the Mifflin–St Jeor equation:

Men:   BMR = 10*weight + 6.25*height − 5*age + 5
Women: BMR = 10*weight + 6.25*height − 5*age − 161
Enter fullscreen mode Exit fullscreen mode

Then we multiply by an activity factor (1.2 sedentary … 1.725 very active). The result plugs directly into the calorie filters — a nice "wow, it understands me" moment.

The comparison tool

The most requested feature: compare two programs side by side. We show:

  • price per day (and total for N days)
  • calories per day and per meal
  • number of meals
  • delivery zones and schedule
  • included diets / exclusions

It sounds trivial, but the UX detail matters: users want to compare their two shortlisted options, not a table of all 30 services. So the flow is: filter → pick 2 → compare.

Business model: the directory play

Racioteka is free for users and takes no commission — orders happen directly on the service's website. We're a discovery layer.

Revenue directions (in progress):

  • Featured listings — priority placement for services that want more visibility.
  • B2B / corporate — companies ordering meal plans for teams.
  • Affiliate / promo codes — when it makes sense for users.

The interesting part of the directory model: the catalog itself becomes a backlink source for every service listed. Which means the services have an incentive to keep their data accurate and even link back. It's a positive loop.

Lessons learned

  1. Data quality beats features. A catalog with wrong prices is worse than no catalog. We manually verify and always show "confirm with the service" disclaimers.
  2. Taxonomy is the product. Invest in the category tree early; refactoring it later is painful.
  3. Local matters. For Ukraine, delivery zones and cities are the #1 filter. "National" services barely exist — almost everyone is city-specific.
  4. Don't build a marketplace first. Start with the directory (information), prove traffic, then add transactions.

Try it

If you're in Ukraine (or curious about the market), check out Racioteka — it's free.

If you've built a directory or comparison product, I'd love to hear:

  • How did you handle data normalization?
  • What's your taxonomy strategy?
  • Directory vs marketplace — which did you start with?

Drop your thoughts in the comments 👇

Top comments (0)