FamDay

Problem

A good deal isn’t always a good fit for a family. Bedtimes, food needs, energy levels, and the practicalities of getting everyone out the door all matter when choosing a trip, meal, or activity.

FamDay is built around those details. It helps families see which offers suit them and what they would save in dollars, using sampled reference prices rather than inflated discounts or artificial urgency.

What I built

As a co-founder and lead developer, I work on FamDay’s website and iOS app. Both use a shared core for family profiles and deal ranking, with API handlers running on Supabase and the browser app hosted on Cloudflare Workers.

The membership model lets families browse offers and see their fit scores before subscribing to redeem them. The mobile app includes family onboarding, saved places, day planning, and a hotel-booking flow used in sandbox testing.

A large part of the engineering work is keeping those experiences consistent across web and mobile while keeping membership, payment, and account checks on the server.

Notable engineering

• Scores people can understand. The scoreDeal engine combines a family’s stated preferences with a bounded adjustment from their behavior. Learned preferences can nudge a score by up to eight points, but they never replace the family’s explicit allergy settings.
• Shared logic without forcing identical apps. The core package holds domain rules and platform interfaces that both clients use. The website and mobile app can keep their own React versions while sharing the same ranking logic.
• One source for API behavior. The Supabase adapter is generated from the canonical API handlers. It preserves the original request body for Stripe signature verification, while the handlers enforce identity, membership, and ownership checks.
• A release gate that covers both platforms. The verification command checks configuration, migrations, design tokens, web and mobile tests, the Edge runtime, and the browser Worker. It also exports the iOS JavaScript bundle, catching problems that a web build alone would miss.
• A browser host with a recovery path. The browser Worker serves the app, API proxy, and share pages under one origin. Its production runbook includes deployment checks and rollback steps, making hosting changes easier to verify and recover from.

Status

FamDay is in development. The web preview is password protected and uses sample data, and the iOS app is in TestFlight testing. Live booking and payment flows still need separate provider setup and verification before release.