How We Built FoodieSwipe in 2 Weeks

The Idea

The brief was simple: build a Tinder-style restaurant discovery app for Hong Kong. Users swipe right to save restaurants they want to try, left to skip. Favourites sync to a map. Filter by cuisine, price, awards, and whether they're open right now.

Simple enough idea. The execution is where it gets interesting — because we built the entire thing using AI tools, with no traditional development team.

The Stack

We chose tools that would let us move fast without compromising on quality:

• Rork — AI-native iOS app builder. Describes UI in natural language, writes SwiftUI, handles Xcode. We used this for all the frontend work.
• Supabase — Backend database for restaurant data, user profiles, favourites, and feedback. PostgreSQL under the hood, REST API out of the box.
• Cloudflare R2 — Image storage for 1,000+ restaurant photos at near-zero cost.
• Sentry — Error monitoring. Critical for catching silent failures (more on this later).
• Apple Sign In — Authentication. HK users expect this for any iOS app.

Week 1: Data + Core UI

The first challenge was data. A restaurant discovery app is useless without great restaurant data. We needed:

• 146 Central Hong Kong restaurants with accurate details
• Opening hours in a consistent format
• Award data (Michelin stars, Asia's 50 Best, Black Pearl, Tatler)
• High-quality photos for every restaurant
• Coordinates for the map view

We built a data pipeline to source, verify, and standardise everything — then loaded it all into Supabase. Every restaurant got cover photos and gallery images stored on Cloudflare R2.

While the data pipeline ran, we started building the app with Rork. The swipe card UI, the filter system, the map view — all described in natural language and built iteratively.

Week 2: Polish + Real Device Testing

This is where most of the interesting problems appeared.

The Silent Decode Bug

The app was showing only 10 restaurants instead of 146. No error message. No crash. Just the wrong data. The culprit: a database column created as INTEGER instead of BOOLEAN. Swift's Codable tried to decode a number as a boolean and silently fell back to mock data.

We fixed it by adding Sentry error monitoring — which identified the exact failing field in seconds. Lesson: add error monitoring before you start testing on real devices, not after.

The Open Now Filter

The "Open Now" filter was showing wrong results. Fukuro — which opens at 6PM — was showing as open at 4:30PM. The hours parser was failing on strings like "Daily 6:00pm–12:00am" because the prefix "Daily" confused the regex.

We rewrote the parser using NSRegularExpression to extract time patterns from anywhere in the string, regardless of prefix. Then standardised all 146 restaurant hours strings to a consistent format.

The Horizontal Drag

Users could accidentally drag the details sheet sideways off screen. The fix required adding .interactiveDismissDisabled(true) at the sheet call site — not inside the presented view as we'd initially done.

The Result

After 2 weeks: a fully functional iOS app with 146 restaurants, live Supabase backend, Apple Sign In, error monitoring, a map view, and a rich filter system. Submitted to TestFlight. App Store submission in progress.

Traditional development timeline for this spec: 3–6 months. Cost: HK$150,000–400,000+. Our timeline: 2 weeks.

What This Means for You

If you have a product idea — an app, a tool, a digital product — the economics of building have fundamentally changed. The barrier is no longer "do I have a technical co-founder or HK$200K to spend." It's "do I have a clear enough idea and the patience to iterate."

That's what Flux AI Labs does. We take your idea and we build it — fast.