EBT Finder: UX Case Study

Shipped

From prototype to the App Store

EBT Finder didn't stop at the prototype. I built the product in React with a Supabase backend, wrapped it with Capacitor, and released it on the iOS App Store. The research below shaped the first version. Everything since has been shaped by running it: real data pipelines, a real App Store review, real crashes, and users on weak connections.

EBT-accepting locations mapped across 53 states and territories

264,000+

US users on the web app in the last 28 days

1,470

shoppers have confirmed or flagged a store's EBT status

49

TestFlight builds to reach a clean release

13

Sources: production database, Google Analytics (Sep 14 – Oct 11, 2026), verification records, release log. Locations and builds read 2026-09-18; users and verifications read 2026-10-12.

Status

Live on the App Store (1.0.2) and at ebtfinder.org

Built with

React, TypeScript, Supabase (Postgres, RLS, 20 edge functions), Google Places API, Capacitor

Data

USDA SNAP retailer dataset synced on a schedule, enriched with Google Places, plus community verifications

Team

Solo: research, design, code, backend, release and support

The Problem

The official locator is a CSV on a map

Low-income families using EBT are underserved by digital tools. The USDA's SNAP Retailer Locator is failing them.

• Is overwhelming and outdated
• Lacks visuals, reviews, or trust signals
• Isn't mobile-first
• Can't filter by user needs (hot food, delivery, open now)

Competitive audit (USDA locator, Google Maps, Yelp, Propel): no single platform combined snap eligibility with real-time visuals and user reviews.

Research

Seven interviews, three findings, five decisions

To ground the experience in real needs, I interviewed 7 EBT users in Fresno over 4 days, including single parents, seniors, and working adults. I later ran moderated usability tests of the prototype with 10 people.

The Solution

Reviews, real photos and a hot-food filter

The search and filter flow is the interactive prototype at the top of this page. The features below are what turn a search result into a store a person will actually walk into.

Validation

9 of 10 found hot food in under 15 seconds

Before writing production code, I ran moderated usability tests with 10 participants, each asked to find a hot food location near them in EBT Finder and in the USDA locator. All four numbers below come from that one session; the production usage figures are at the top of this page.

Task success

9 of 10

testers found a hot food location in under 15 seconds, against 3+ minutes on the USDA site

Preference

10 of 10

testers said they would use EBT Finder over the USDA tool

Confidence

8 of 10

testers felt more confident visiting a store after seeing its reviews and photos

Time to find hot food

12x faster

median 15 seconds in EBT Finder versus 180 seconds on the USDA locator

Marketing

How I market it

Shipping is half the job. I also run distribution: the App Store listing, search, content and partners. It is the same research, applied to how people find the product instead of how they use it.

• App Store

  The listing is an ad

  I designed the store screenshots above as marketing frames, one benefit each, in the words people used in interviews. The subtitle and keywords match how people actually search: food stamps, CalFresh, hot food, WIC. On the web, a Smart App Banner sends iPhone visitors to the listing.

  7 designed store screenshots

• Search

  A landing page for every state and major city

  Prerendered pages for every state, 121 cities and the questions people type, like “Does Walmart take EBT?”, plus a store sitemap with structured data so results can show EBT acceptance.

  198 search landing pages

• Content

  SNAP guides on a steady schedule

  Guides and SNAP news publish twice a week. I cut it from daily once quality mattered more than volume. The site works in English and Spanish.

  2 posts a week, English and Spanish

• Partners

  Distribution through people users already trust

  An embeddable city widget that food banks and 211 sites can put on their own pages, with tracked links back, and an outreach plan aimed at 211 networks, food banks and SNAP-Ed.

  26 partner organizations targeted

What I don't do: marketing push notifications. A notification only sends if it saves someone a wasted trip or wasted money.

Running It

What broke after launch, and what I did about it

A prototype never meets a changed API, an App Review rejection or a user with one bar of signal. The product did. These are the problems that mattered, each with the decision behind the fix.

1. 01

   Google changed the shape of its data and took down every store page

   What happened:

   Google Places moved reviews from one JSON shape to another. Rows written before and after the change coexisted in the same column. Rendering the new shape crashed every enriched store page; a SQL filter reading the old key silently dropped new-shape stores from Open Now results.

   What I did:

   Normalized both shapes at one boundary, guarded every render of external data, made the SQL read both keys, and locked it with a regression test built from the actual crashing row.

   What it taught me:

   The database stores whatever shape the API had on the day each row was written. Every consumer, client and SQL, has to handle both, forever.

2. 02

   Users open the app where the signal is worst

   What happened:

   The core use is standing in a store with one bar. Queries returned empty on network failure and the app showed nothing.

   What I did:

   A last-good-result cache keyed on the full query identity (bucketed location plus every filter), so an area with zero results shows zero and never another area's cache. Fresh data always wins; the cache only speaks when the network can't.

   What it taught me:

   Offline support is a product decision about which screens must work, not a technical checkbox.

3. 03

   Apple rejected the build for a bug that wasn't in the build

   What happened:

   App Review reported that account creation failed. The cause was a database trigger referencing a column I had removed: every new sign-up returned a 500, which the app surfaced as the error the reviewer saw.

   What I did:

   Fixed the trigger server-side, reproduced the sign-up on a physical device against the same build, and replied to the Resolution Center with the root cause and evidence. No new binary was needed.

   What it taught me:

   The backend is a shared artery. A schema change hits the website and every installed build at once, so server changes must be additive and tested against shipped versions.

4. 04

   Thirteen TestFlight builds to a clean release

   What happened:

   The 1.0.2 redesign found its native-UX bugs on the phone, after upload: a sticky header that never stuck, dead-tap card images, a login screen with a manufactured scroll region, GPS refresh that navigated away instead of updating inline.

   What I did:

   Turned every bug class into a written rule and a pre-archive audit at phone dimensions (safe areas owned by one component each, 44pt targets, one tap target per card, inline refresh with skeletons). Later releases audit before they archive.

   What it taught me:

   Every rule in that checklist is a build that cost a day. The discipline is auditing before the archive exists.

5. 05

   Notifications that respect people who are stretched thin

   What happened:

   Push is the easiest way to look engaged and the fastest way to lose trust with users who are checking their benefits, not browsing.

   What I did:

   A standing policy: a notification sends only if it saves a wasted trip or wasted money. Two are allowed (a saved store may have stopped taking EBT; an opt-in proximity alert), permission is asked right after the first favorite, never at launch, and there are no marketing or re-engagement pushes at all.

   What it taught me:

   Attention is not an engagement metric. For this audience, restraint is the feature.

What I Learned

What I learned, and what I'd change

1. 01

   Trust is UX. Users don't care about feature count; they care about confidence. Visuals, reviews, and community feedback drive trust more than any official dataset.

2. 02

   Government tools ignore real workflows. The USDA SNAP locator serves as a database, not a usable product. It fails on mobile, lacks accessibility, and assumes users will do all the work.

3. 03

   Filtering equals dignity. People aren't just looking for "any" EBT store. They want the right fit: hot meals, open hours, safety, distance, and welcoming staff.

4. 04

   Designing for underserved users requires humility. You can't assume you know what matters most until you talk to people living through the experience.

What I'd do differently

1. 01

   Expand merchant research. I focused heavily on user needs but should have interviewed more small business owners to understand barriers to EBT adoption. This would strengthen the business model.

2. 02

   Test with broader demographics. My 7 interviewees and 10 testers were valuable, but I'd include more rural users, non-English speakers, and users with disabilities to ensure accessibility.

3. 03

   Build in educational content earlier. Hot food eligibility is confusing. I should have designed state-specific tooltips and FAQ content into the MVP, not as a "next step."