Integration

How we build on Supabase

Supabase is the database, auth and storage layer under everything we ship. This page is the technical detail: what we use, how we wire it, and what a build actually looks like.

What we are

Kaliber Autonomy is a consultancy in Richmond Hill, Ontario. We build and run production web applications for small local businesses — storefronts, booking, admin areas, content systems.

We're an implementation partner, not a tool vendor. We don't publish software that plugs into Supabase; we build our clients' systems on it and keep them running afterwards.

What we use

Postgres + RLS Row-level security on every table that holds customer data. Policies are the access model, not an afterthought bolted on at the API layer.

Auth Email and OAuth. Where a client only needs staff access, we lock sign-in to a single provider and an allow-list rather than opening registration.

Storage Product and gallery images, served through the site's own image pipeline so clients upload from a phone without thinking about formats.

Edge Functions Webhook receivers and anything that must hold a secret — payment callbacks, transactional mail, scheduled jobs.

How a build is put together

1. Schema first, policies with it

We design the tables and the RLS policies in the same pass. Anonymous visitors read what is meant to be public. Everything else is denied by default and opened deliberately. No table ships with RLS off.

2. Static front end, Supabase behind it

Sites are static — Astro or hand-written HTML on Cloudflare Pages or GitHub Pages. The browser talks to Supabase with the anon key, and RLS decides what comes back. Anything privileged runs in an Edge Function with the service key, never in the page.

3. Payments through webhooks

Checkout goes through Stripe. The order is written by a webhook handler that verifies the signature before it touches the database, so the record reflects what the payment processor confirmed rather than what a browser claimed.

4. An admin the owner can actually use

Every build ships with an admin area scoped to the owner's own account. Products, prices, content, orders. The point is that the client changes their own site without calling us.

5. Security review before launch

We run a live attack battery against the deployed URL and review the code for what a black-box probe can't see — policy gaps, exposed keys, write endpoints without rate limits. Nothing goes live for a client until that passes.

Built on Supabase

Sandra's Wick & Wax Co.

sandraswickswaxco.ca

Candle storefront. Supabase holds the catalogue, orders and admin; Stripe handles checkout. The owner manages products, prices and stock herself.

Kotori

kotoriauthenticjapaneserestaurant.ca

Restaurant site with a Supabase-backed CMS. Menu, hours and page content are editable by staff behind Google-only sign-in restricted to the restaurant's own accounts.

Natural Stone Design

quote capture and follow-up

Quote intake for a stone fabricator, with the request pipeline in Supabase. Currently offline at the client's request.

How we work with clients

The Supabase project belongs to the client, on their own account and billing. We're granted access; we don't hold their data hostage.
Schema and policies live in the client's repository as migrations, so the database can be rebuilt from source.
Most engagements start as a migration — moving a small business off a monthly SaaS platform onto an owned stack, which usually cuts fixed cost to near zero and leaves the data portable.
We stay on afterwards for changes and monitoring. Sites we build are checked for uptime and reviewed when anything security-relevant changes.

If you're evaluating us as a Supabase partner and want specifics we haven't published — schema patterns, a policy walkthrough, a reference — email admin@kaliberautonomy.com and we'll send them.

Details

Company: Kaliber Autonomy (1001628065 Ontario Inc.)
Where: Richmond Hill, Ontario, Canada
Contact: admin@kaliberautonomy.com
Logo and brand assets: kaliberautonomy.com/brand.html