Supabase and Firebase Development Agency: New Backends, Security Reviews and Cost Fixes

Supabase and Firebase have made it possible to launch a real product without running your own servers. They've also made it easy to launch one with the database wide open, a bill that grows faster than the user base, or a schema nobody can change safely. We get called in for all of these.

This page is for teams who want to hire developers for Supabase or Firebase work: a new backend, a security review of an existing one, a messy schema, or a cost problem. For a full side-by-side comparison of the two platforms, read Supabase vs Firebase. Here we focus on what we do and what to check.

What we do with Supabase and Firebase

• New backends for web apps, SaaS products and mobile apps: data model, authentication (email, phone OTP, Google and Apple sign-in), file storage, server functions and an admin view.
• Security reviews of an existing project: who can read and write what, and whether the rules match what the interface pretends.
• Schema and migration clean-up: getting database changes into version control so they can be tested and repeated.
• Cost and performance fixes: finding the query, listener or function that's driving the bill or slowing screens down.
• Moving between platforms when a product has outgrown its first choice, done in stages so users don't notice.

We use these alongside Next.js, React and TypeScript on the web (see Next.js development), and Flutter or React Native on mobile. If you're planning a multi-tenant product, SaaS development covers the wider build.

Which one fits your product?

There's no universal winner. Our rule of thumb:

Both are fine choices for most MVPs. The worst choice is picking one because a tutorial used it, then fighting its data model for a year.

Row-level security: the part most projects get wrong

On Supabase, the browser or app talks to the database directly with a public key. That's by design, and it's safe only if row-level security (RLS) is switched on for every table that holds user data, with policies that say exactly who can do what. The mistakes we find most often:

1. Tables with RLS switched off, readable by anyone who opens the browser developer tools and copies the public key.
2. Policies that check data the user can edit, such as role values stored in user-editable profile metadata. A user can simply promote themselves.
3. The service role key used in front-end code. That key skips every policy and must only live on the server.
4. Policies that allow reading but forget updates or deletes, or the reverse.
5. Slow policies: a policy that runs a sub-query on every row can make large tables crawl. The fix is usually an index or a restructured check.

Firebase has the same risk in a different form: security rules. Projects started in "test mode" open the database to everyone for a period, and some teams forget to replace those rules before launch. Others write rules that check only that a user is signed in, so any signed-in user can read everyone's data.

In a security review we test the rules as a real attacker would: signed out, signed in as a normal user, and signed in as a user from another organization, trying to read and change what they shouldn't. You get a written list of findings, ordered by risk, with the fixes priced.

Migrations: changing the database without breaking it

On Supabase, every change to tables, policies and functions should be a migration file kept in the repository, tested on a local or preview database, then applied to production. When people make changes by clicking around the production dashboard, nobody can rebuild the database from scratch, and staging slowly drifts away from production. We bring projects like that back under control by capturing the current state as a baseline and moving forward with migrations from there.

On Firebase, Firestore has no fixed schema, which feels fast at first. The cost is that old and new document shapes live side by side. When your data model changes, you need a migration script or code that handles both shapes, and query indexes kept in a file under version control.

What it costs to run, as you grow

Both platforms are cheap or free at the start. The bill depends on how your app uses them, which is where good engineering pays for itself.

• Supabase has a free plan for trying things out, but free projects pause after a week without activity, so it isn't meant for a live product. Paid plans start at $25 per month and grow mainly with database compute size, storage, bandwidth and monthly active users beyond the plan's allowance.
• Firebase has a free Spark plan and a pay-as-you-go Blaze plan. Firestore charges per document read, write and delete. That's cheap per operation, but a screen that listens to a large collection, or a list that reloads every document on each visit, can multiply reads quickly.

Ways we keep bills predictable: paginating lists, listening only to what's on screen, caching data that rarely changes, indexing columns used in policies and filters, and moving heavy jobs to scheduled functions. Set up budget alerts in your cloud account too; they warn you, but they don't cap spending.

Both accounts are opened in your name and billed to you directly, from day one.

Prices and timelines

For an existing project we start with a quick review of the setup and an honest view of what's worth keeping, then quote fixes as a fixed price. Projects over $500 start with a 30% down payment, then 40% and 30% at milestones, each paid after you see the work running.

When we're the right fit, and when we're not

A good fit: startups building on Supabase or Firebase, teams who inherited a project and aren't sure it's secure, and products whose bills are growing faster than their users.

Not the right fit:

• You need 24/7 on-call database operations. We're a project studio, not a managed operations team.
• Your data must stay on servers inside one specific country and neither platform offers a suitable region for you. Self-hosting or a local cloud may be needed, and that's a different kind of project.
• You need a data warehouse or heavy analytics pipeline. Use tools built for that, fed from your app's database.
• The product involves gambling, crypto or forex trading, interest-based lending, alcohol, adult content or military use. We don't take these.

FAQ

Is Supabase secure enough for a production app?

Yes, when row-level security is enabled on every table with user data and policies are written and tested properly. Most leaks we see come from configuration mistakes, not from the platform. A review before launch is cheap compared with a data incident.

Can you move our app from Firebase to Supabase, or the other way?

Yes. We usually move in stages: authentication and new features first, then data, with both systems running side by side for a short period. It's only worth doing when the current platform is genuinely limiting you, and we'll tell you if it isn't.

Do I get locked in to either platform?

Supabase is built on standard PostgreSQL, so your data and most of your logic can move to any PostgreSQL host. Firebase is more tied to Google's services, so leaving later takes more work. That's a fair trade for many mobile apps, but worth knowing upfront.

Can you work on our existing project without rebuilding it?

Yes, that's most of our review work. We keep what's sound, fix what's risky, and explain anything that genuinely needs rebuilding before you pay for it. If the whole project needs rescuing, see fix or take over an app.

Which database do you use for mobile apps?

Firebase is a common choice for our mobile MVPs, especially with real-time features, and Supabase fits when the data is relational or shared with a web dashboard. Both work well with Flutter, our main mobile framework; see Flutter app development.

How do I start?

Tell us what you're building, or share access to the existing project and describe the problem. Within 24 hours you'll get a written scope and a fixed price, free and with no obligation. You can also use the project planner.