Indizilla
The client operations platform behind a marketing agency — orders, jobs, billing, credits, and referrals, running on one Postgres database instead of spreadsheets and a shared inbox. Live at indizilla.com.
An ordering system, not just a website
A marketing agency doesn't just need a homepage — it needs a place where a client can order work à la carte, a place where that order becomes a tracked job with a due date, an invoice that generates itself, and a way to reward referrals without a spreadsheet quietly going stale. Indizilla is that system: a static client-facing frontend backed by a single Postgres database that owns every one of those steps.
The data layer does the enforcing, not the frontend
The client platform covers a dashboard, à la carte ordering, an admin console, and tracked jobs, bills, credits, and referrals. One data module (js/db.js) exposes a single API that runs against either Supabase (when a real key is configured) or local storage in demo mode — so the same frontend runs standalone before a client's account even exists.
The important decision is where the trust boundary sits. Reads come from an in-memory cache filled once at init; writes go through Row-Level Security policies and a small set of security-definer Postgres functions — place_order, redeem_referral, admin_adjust_credits, my_referral_code. A client's browser can never write a job or an invoice table directly. Placing an order triggers server-side creation of both the job (with its due date) and the invoice (INV-year-seq), and every coupon or credit balance is re-validated in Postgres at order time — the client-side math is display only, never the source of truth.
Admin rights are enforced the same way: by row-level policy in the database, not by a role check in the frontend that a client could work around.
Payments are live; verification is the open item
Checkout runs client-side against Razorpay using a public key ID. Payment records in the database are currently unverified references — signature verification and webhook confirmation are the deliberate next step, planned as a Supabase Edge Function rather than shipped ahead of need. Google sign-in is wired through Supabase Auth rather than hand-rolled, with the OAuth exchange handled entirely on Supabase's side of the boundary.
- Ship the Edge Function for Razorpay signature verification before treating any payment record as confirmed — right now that's an honest gap, not an oversight.
- The demo-mode fallback (local storage when no Supabase key is set) was the right call for early iteration, but it's a trap if left in production longer than needed — worth an explicit build-time check that fails loudly if it's ever live with real traffic.
Scope of this entry.This page documents the platform architecture only — database design, payment flow, and auth. It intentionally does not describe Indizilla's marketing services or brand positioning, since that content hasn't been written up yet.
Status. Live at indizilla.com. Payment signature verification is a known, unshipped gap — see above.