Supabase carries the data and authentication layer for six of our live products. This is HCD, Appster, MoneyCare, Release Coach AI, Inspire Film and TrendinChat all run on it.
Standing Supabase up is easy. Standing it up securely is a separate job. This page explains why row level security is the most consequential decision you will make, and when we choose a different path entirely.
Supabase adds authentication, file storage and live subscriptions on top of PostgreSQL. On an MVP, wiring those three pieces together separately takes weeks. On Appster, catalogue data and vector search could live in the same database, so there was no separate search infrastructure to operate or pay for. And because what sits underneath is standard PostgreSQL, your data is not locked in if you later decide to move somewhere else.
The security problem we see most often in Supabase projects is row level security policies that are missing or written too broadly. Because the client talks to the database directly, one wrong policy means a user can read another user's records. These tables and policies are always designed and reviewed by an engineer. This is one area where we do not trust generated code, no matter how convincing the generated policy reads on the first pass.
If you need complex multi-step business logic, long-running background jobs, or the database has to sit in a specific environment for enterprise reasons, we build a separate server layer instead. That is why Reveal Software has its own service layer on Hono and Drizzle. Having everything talk from the client straight to the database stops being sustainable once business logic grows past a certain point, and untangling it later costs more than starting differently would have.
Supabase invoices tend to grow with storage and bandwidth rather than row count. On image and video heavy products, moving files to a different storage service is often more economical. In Inspire Film, video delivery runs through a separate service and Supabase carries only the application data. Making that split at the beginning is considerably cheaper than migrating files once the library has already grown large.
The smallest real product that proves the idea, deployed and usable by actual customers.
Starting points, not quotes. What a project actually costs depends on scope, and we agree that in writing after discovery.
Yes, we run it in six live products. What decides the outcome is not Supabase itself but whether row level security and the data model were designed properly. An engineer always writes and reviews that part before anything ships.
The data is portable because standard PostgreSQL sits underneath. The authentication and storage layers take additional work. If you know this is a possibility from the start, we can structure the codebase to make that move less painful.
Yes. We look at table policies, where service keys are being used and what surface is exposed to the client, then produce a written report. This work usually runs under the ongoing support arrangement.
It is suitable for vector search. On Appster, embeddings for more than 2,700 apps sit in the same database as everything else, which meant we never had to operate a separate vector service alongside it.
A short note about the product, the timeline and who it is for is enough to start. You will hear back from the engineer who would do the work, not a sales team.
Ankara / Türkiye · Working across European and US time zones
