Supabase developer · New Zealand
Supabase builds by someone who genuinely knows Postgres.
You’ve chosen Supabase, or you’re weighing it up, and you want someone who treats Postgres as a real database — not a black box behind an ORM. Tally Digital builds the whole surface: schema, row-level security, auth, realtime and edge functions, hand-coded by a senior engineer and yours to own.
In short
What a Supabase developer actually does
A Supabase developer builds the application layer on top of Supabase’s Postgres database, Auth, Realtime, Storage and Edge Functions — and, crucially, understands the Postgres underneath rather than treating it as a generic backend. In practice that’s designing a schema with real foreign keys, constraints and indexes; writing row-level security policies so your data is protected at the database instead of trusted from the client; wiring up auth with the right JWT claims; and adding realtime, file storage and server-side functions where they belong. It’s the difference between a Supabase project that ships fast and quietly leaks data through one missing RLS policy, and one built to hold up in production.
What we build
What we build on Supabase
Most projects are some combination of these. If it involves Postgres, auth and data your business depends on, it’s in scope.
Postgres schema design & migrations
A relational schema with real foreign keys, check constraints, indexes and the right data types — designed in SQL, versioned as migrations and applied through the Supabase CLI, not clicked together in the dashboard and forgotten. Generated columns, views and triggers where they earn their place.
Row-level security & multi-tenant access
RLS policies written and tested per table — USING and WITH CHECK clauses keyed off auth.uid() and JWT claims — so a tenant can only ever read and write its own rows. Security enforced at the database, not hoped for in the client.
Supabase Auth done properly
Email, magic-link, OAuth and SSO through Supabase Auth (GoTrue), with the anon and service-role keys used where each belongs, custom claims via auth hooks, and MFA where it matters — because that JWT is what your RLS policies actually depend on.
Realtime — Broadcast, Presence & Postgres changes
Live updates built the way that actually scales: Broadcast and Presence for high-frequency channels, database-change streams where they genuinely fit, and an honest call on which — because Postgres Changes on every table does not scale the way people assume.
Edge Functions, webhooks & integrations
Deno-based Edge Functions for the work that shouldn’t touch the client — Stripe and other webhooks, third-party API calls with your secrets kept server-side, scheduled jobs via pg_cron — and the integrations that make Supabase talk to the rest of your stack.
Storage, search & Postgres extensions
S3-compatible Storage with RLS on buckets and signed URLs, full-text search in Postgres itself, and extensions where they earn it — pgvector for embeddings and semantic search, PostGIS for geospatial, pg_cron for scheduling.
In depth
How to think about a Supabase build
When you don’t need a Supabase specialist
Plenty of Supabase projects don’t need one. If you’re building a straightforward CRUD app, single-tenant and behind a login, the defaults and the docs will carry you a long way — and you should let them. If you haven’t validated the idea yet, a no-code tool or the Supabase dashboard on its own is often enough to test it. And if your workload is heavy analytical reporting over hundreds of millions of rows, that’s a data-warehouse job rather than a Postgres-on-Supabase one, and I’ll say so. Where a specialist earns their keep is the moment real money, real tenants or sensitive data are involved: multi-tenant RLS, auth you can’t afford to get subtly wrong, a schema that has to hold up as the product grows. If that’s not you yet, don’t over-build.
Postgres is a database, not a black box behind an ORM
A lot of Supabase trouble comes from treating Postgres as a generic backend that an ORM will manage for you. It isn’t. Supabase gives you a real relational database, and the projects that hold up are the ones designed like one — proper normalisation, foreign keys and check constraints doing the work the application shouldn’t have to, indexes chosen for the queries you actually run, and logic pushed into the database as functions and triggers where that’s the right place for it. Knowing Postgres — not just an ORM’s query builder — is what lets you use RPC functions, generated columns, materialised views and the PostgREST API that Supabase exposes, instead of pulling everything into application code and re-implementing what the database already does better.
Row-level security is real security, not a checkbox
Supabase’s PostgREST API means your database is, in effect, reachable from the client with the anon key — so row-level security isn’t optional decoration, it’s the wall. Getting it right means a policy on every table with the correct USING and WITH CHECK clauses, keyed off auth.uid() or a JWT claim; it means knowing that the service-role key bypasses RLS entirely and must never reach the browser; and it means testing policies as different users rather than assuming they hold. It also means writing them to perform — wrapping auth.uid() in a subselect and indexing the columns policies filter on, so security doesn’t quietly cost you a sequential scan on every request. A missing or naive RLS policy is the single most common way a Supabase app leaks data, and it’s the first thing I check on an existing project.
Auth, realtime and edge functions — the rest of the surface
Beyond the database, a real Supabase build uses the rest of the platform deliberately. Auth (GoTrue) issues the JWT your RLS depends on, so the claims in that token — and how custom claims are added through auth hooks — matter more than the login screen. Realtime has three modes, Broadcast, Presence and Postgres Changes, and choosing well matters, because streaming every database change to every client does not scale the way the demo suggests; Broadcast, often triggered from the database, is usually the right tool. Edge Functions handle what can’t live in the client: webhooks, third-party calls that need secrets, anything using the service-role key. And connection pooling through Supavisor in transaction mode is what keeps a serverless front end from exhausting Postgres connections. None of it is exotic — it’s just the difference between using Supabase and using it properly.
Who you actually work with
Not an account manager fronting a team — Isaac Vicliph, a senior software engineer with a decade shipping software in financial services, writing the SQL and the TypeScript himself. That background matters here: row-level security, auth and data you can’t afford to leak are exactly the problems financial-services software is built around. You get one accountable person from the first scoping call to launch, direct contact throughout, and a plan you can read before anything is built. It’s a deliberately small operation — fewer projects, no junior hand-off, and the person who understands your system is the person who built it. NZ-based, priced in NZD, GST-registered.
How a project runs, and how it’s priced
I scope before I quote. The first step is understanding what you’re building and where the risk sits — the multi-tenant model, the auth requirements, the data that has to stay private — followed by a written plan: the schema, the RLS approach, which parts of the Supabase surface you actually need, what you own at the end, and a fixed price for that scope. No hourly meter, no open-ended estimate that drifts. A focused schema-and-RLS build is a smaller job than a full multi-tenant app with realtime and billing, so rather than publish a number that’s wrong for your project, I give you a firm one once I understand it. An existing project that needs an audit or a rescue is scoped the same way.
Reviewed July 2026 · written by Isaac Vicliph, Tally Digital
Questions
Frequently asked
What is Supabase, and what does a Supabase developer do?
Supabase is an open-source backend platform built on Postgres — it gives you a Postgres database, authentication, row-level security, realtime, file storage and serverless edge functions in one place. A Supabase developer builds the application on top of that: designing the schema, writing the RLS policies that protect your data, setting up auth, and using realtime, storage and edge functions where they belong — while genuinely understanding the Postgres underneath, not just an ORM sitting on top of it.
How much does a Supabase build cost in New Zealand?
It depends entirely on scope — a focused schema-and-RLS setup is a very different job from a full multi-tenant app with auth, realtime and billing, so a blanket price would mislead. I scope your actual project first, then give you a fixed price for that scope before any work starts: no hourly meter and no open-ended estimate. Tell me what you’re building and you’ll get a firm number back.
Do you set up row-level security and multi-tenant auth properly?
Yes — it’s most of the work on any serious Supabase project. That means a tested RLS policy on every table, keyed off auth.uid() and JWT claims, with USING and WITH CHECK clauses that stop a tenant reading or writing another tenant’s rows; the service-role key kept server-side and off the client; and policies written to perform. Security enforced at the database, not assumed in the application.
Can you audit or fix an existing Supabase project?
Yes. A common request is a review of a Supabase app someone else started — usually checking that RLS actually protects every table, that the service-role key hasn’t leaked into the client, that the schema and indexes hold up, and that auth is set up the way the app assumes. I scope a fix or a rescue the same way as a new build: understand it first, then a written plan and a fixed price.
Is Supabase secure enough for production and sensitive data?
Yes, when it’s built properly — Supabase is Postgres, and Postgres runs plenty of serious production systems. The security lives in how you use it: correct row-level security on every table, the service-role key kept off the client, auth and JWT claims set up right, and sensible data handling. Supabase gives you the tools; whether an app is actually secure comes down to whether those tools were used correctly, which is exactly what a specialist is for.
Can you migrate us from Firebase or another database to Supabase?
Yes. Moving from Firebase or another database to Supabase is more than copying data across — it means designing a proper relational schema to replace a document store, rebuilding auth on Supabase Auth, and translating security rules into row-level security policies. I scope the migration, plan the cutover so you’re not flying blind, and build it so the result is a clean Postgres database you own, rather than a lift-and-shift that carries the old problems with it.
Do I own the Supabase project and the code?
Yes, outright. The Supabase project sits in your own organisation and account, and you own the repository, the SQL migrations and the infrastructure. Because it’s a mainstream stack — Postgres, standard migrations, TypeScript — any competent developer can pick it up. The whole point of commissioning the work is that it’s your asset, not something locked to me.
Are you a Supabase developer or a digital agency?
A senior software engineer, not an agency. Supabase, Postgres and the application around them — written by the person you talk to, every time. No account managers, no junior hand-off, no monthly marketing retainer. If you need someone who genuinely knows Postgres and the whole Supabase surface, that’s the work.
Tell me what you’re building on Supabase.
Whether it’s a new multi-tenant app, an RLS and auth model you need to get right, or an existing Supabase project that needs an audit — tell me what you’re building and I’ll scope the smallest safe build that gets you there, then come back with a clear plan and a fixed price.