Four supermarkets, one screen, no merchant portal.

01 — The problem

The deals exist. Getting to them takes more effort than the savings are worth.

Kenya's grocery market serves 54 million people across four dominant supermarket chains — Carrefour, Naivas, QuickMart, and Greenspoon. Each runs weekly promotions. The information is real and current. It's also scattered across four separate websites, WhatsApp forwards, and paper flyers pinned to store entrances. I kept running into the same experience: I knew deals existed but checking four places wasn't worth the ten minutes it took. So I stopped checking, like most people do.

02 — The decision

I cut the merchant out of the pipeline.

The standard approach is obvious: build a portal, ask each supermarket's marketing team to upload their promotions weekly. I thought about this for a while and decided against it. A marketing manager at Carrefour Kenya is not going to maintain a dashboard for an app with zero users. The portal would launch empty, and an empty deal aggregator has nothing to show anyone.

Instead, I built an automated pipeline that pulls deal data directly from retailer websites. No partnership required. No waiting for anyone to say yes. The data flows on a schedule, gets normalised into a consistent format, and lands in a Firestore database that the PWA reads from.

The actual data pipeline — retailer sites are scraped weekly via GitHub Actions, normalised, and served through Firestore.

"Ariel Power Gel 2L
Was KES 1,299 Now KES 899
Valid: 15-21 Apr
Category: HOME CARE"

{ "name": "Ariel Power Gel",
  "size": "2L",
  "price": 899,
  "was": 1299,
  "pct": 31,
  "retailer": "carrefour",
  "category": "household",
  "expires": "2026-04-21" }

Each retailer has different formatting, units, and date conventions. The normalisation layer standardises everything into a consistent schema the PWA can render without per-retailer logic.

03 — Constraints

Every design decision traces back to one of these.

04 — The deal card

One hierarchy call that defines the whole product.

The deal card is the atomic unit of Dill. Every other screen exists to surface it or filter toward it. The key question was which number goes biggest: 40% off (feels exciting) or KES 200 saved (is that even worth the trip?). I chose to show both at equal weight. A percentage alone optimises for dopamine; an absolute alone favours high-ticket items. Showing both lets the shopper apply their own judgment.

Everything else on the card — brand imagery, marketing language, promo badges — got stripped out. Price is the product. The card shows four things: current price, original price, percentage saved, and which store has it. That's the information a shopper needs to decide, and nothing more.

05 — Current status

Where Dill is now.

Dill is a live product in active development. The automated pipeline runs weekly, pulling current deals from all four retailers. The PWA serves cached data for offline use and loads under 2 seconds on a 3G connection.

Next steps: Validate the core assumption — that shoppers check deals before leaving home and rely on cached data at the store. This assumption shaped the entire offline architecture. Whether it reflects real behaviour, or whether people want live data and would rather wait for a connection, is the open question that determines the next iteration.

Accessibility

Deal cards use sufficient contrast for price text against card backgrounds, meeting WCAG 2.1 AA requirements. All interactive elements have minimum 44×44px touch targets for reliable use on mid-range Android devices. The app respects prefers-reduced-motion for users who have disabled animations at the OS level, and all navigation is keyboard-accessible.