Supabase development for web apps, SaaS and MVPs

What Supabase replaces

A first version of a product usually needs the same backend pieces. Supabase bundles them on top of a standard PostgreSQL database, which means your data is not locked in a proprietary format.

If you are deciding between Supabase and Firebase, our Supabase vs Firebase page covers the trade-offs. The short version: Supabase suits relational data and SQL, Firebase suits document data and a Google-centered stack.

Row level security, with an example

Supabase exposes your database to the browser through an API. That is safe only if every table has row level security turned on and written rules. A rule is a sentence the database checks on each request.

Take a SaaS app where each customer has a team and the team has projects. The rule for the projects table reads: a person may see a project only if they are a member of the team that owns it. A second rule says only team admins may delete. If you skip those rules on a table, anyone holding the public key can read all of its rows.

We write a test for each rule: log in as a member of team A, ask for team B's project, and confirm the answer is empty. These tests run before every release, so a later change cannot quietly open a table.

What we have built on it

We do not publish a Supabase project on our work page, and this page does not pretend otherwise. The published custom-app work closest to it is the CRM we built for Aura Realty, which gathers enquiries from the website, Instagram, WhatsApp and calls in one place and tracks follow-ups. The case study does not name the database, so we make no claim about it. For a Supabase project we begin with the data model and the security rules, then build the interface. Our MVP development and SaaS development services are the usual route.

Gotchas we plan for

• Two keys, two risk levels. The public key is meant for browsers. The service key bypasses all security rules and must stay on a server. Putting it in front-end code is the most serious error we see in review.
• Row security can be off. A table made through code does not always have it enabled. We check every table in the schema before launch.
• Serverless and connections. Many short-lived functions open many database connections. Use the connection pooler address in those environments.
• Changes belong in migrations. Editing tables in the dashboard is fast but leaves no record. We keep schema changes in versioned migration files so staging and production match.
• Region and privacy. Pick the project region deliberately. For EU or UK customers, keeping personal data in a European region simplifies GDPR paperwork.
• Backups and recovery. Know what your plan includes, and test a restore at least once before you have customers.
• Free projects can pause. Inactive free-tier projects may be paused. Move to a paid plan before real users depend on the app.

Timeline for a first version

A focused MVP with logins, three to five main screens and one integration usually takes 6 to 10 weeks. Bigger products are scoped in phases.

We give a fixed quote after a short call. Describe your product.