Production web app
Roomeefy
Student roommate-matching web app, live at app.roomeefy.pl since July 27, 2026. All production engineering is mine: auth, database, realtime, CI, and the guards that came out of launch day.
all within 24 hours, each converted into a permanent guard
app.roomeefy.pl, serving real users
release validator and a CI volatility test
Architecture
System path
- 01Installable PWA front end
- 02Supabase auth with Google OAuth
- 03Postgres with migrated schema
- 04Realtime with designed polling fallback
- 05CI: tests and migrations gate Vercel deploy
Role
Technical cofounder on a student roommate-matching venture. Everything production is mine: the Supabase backend (auth, Postgres, Realtime with a designed polling fallback), Google OAuth, the installable PWA, and merge-to-main CI that runs tests and database migrations before the Vercel deploy. The iOS TestFlight lane is built.
Launch day
The app went live on July 27, 2026. The launch surfaced 7 incidents, and all 7 were root-caused before the first 24 hours were over. Two are worth describing because of how they were found and what they left behind.
A release shipped a literal placeholder string where an API key belonged. Nothing in the logs said so directly; the failure was found by inspecting the served JS bundle and reading what the client had actually been given. The fix was followed by a release validator that fails the build if a placeholder value survives into an artifact.
A Postgres function was declared STABLE when its behavior was VOLATILE, which produced wrong results only under real query plans. It is now guarded by a CI regression test that asserts function volatility, so the class of bug cannot ship again silently.
Operating principle
Every failure becomes a permanent guard. Incidents are not closed when the symptom stops; they are closed when a test or validator exists that would have caught them before deploy. CI runs the test suite and database migrations on merge to main, before Vercel deploys, so the main branch is the release.
Realtime with a fallback
Matching and messaging use Supabase Realtime, but the client is written against a designed polling fallback rather than assuming the socket is always there. Degraded network conditions downgrade the experience instead of breaking it.