In developmentFireFly Stack LLC
Home-Services Marketplace
Homeowners can't easily find and pay trusted local service providers; providers have no structured channel for local demand.
roleFounder, architect, and sole engineer
timeline2026 — present
statusin development
- Next.js
- React
- TypeScript
- Supabase
- PostgreSQL
- Stripe Connect
- Expo / React Native
// problem
Plumbing, electrical, drywall, HVAC, gardening, and general property services in Utah still run on phone tag and word of mouth. Homeowners can't compare quotes; providers can't see nearby demand; nobody holds payment safely in the middle.
// users
Homeowners and businesses posting tasks; licensed local service providers quoting and completing them; platform admin overseeing disputes and onboarding.
// constraints
Two-sided cold-start, real money movement (escrow-style release), provider verification, and a single engineer building web + mobile from one codebase.
// solution
A two-sided marketplace: customers post a task, providers in the ZIP code quote it, the customer picks a provider and is charged through the platform. The provider completes the work and uploads photos; the customer approves; payment is released with a 7% platform fee retained.
// architecture
Next.js web app and Expo mobile app over a shared Supabase (PostgreSQL + RLS) backend. Stripe Connect handles onboarding, charges, and payment release. Role-based access separates customers, providers, and admin tooling; messaging and image uploads ride Supabase storage and realtime.
// my role
- Product scoping and workflow design (posting → quoting → escrow-style payment → review → release)
- Database schema, RLS policies, and role-based access
- Stripe Connect payment architecture including the 7% platform-fee model
- Web frontend, provider onboarding, and admin tools
- Expo / React Native mobile development
// status & outcomes
In active development under FireFly Stack. Payment, bidding, and onboarding workflows are the current build focus.
// lessons
Escrow-style flows put state-machine correctness above everything — every payment transition needs an unambiguous owner, and RLS has to enforce the same rules the UI implies.