Backend Technical

Backend Technical Brief For candidate review before recording a Loom walkthrough What This Platform Is This is a SaaS console. Client companies log in and trigger modules that run through an AI API. A human approves the output before anything goes live. The business only works if the backend is built correctly from day one, since two things break it fast: one client seeing another client's data, and one client's usage burning through your margin. This brief describes the problems in the system. We are not asking you to build anything yet. We want a Loom video where you walk through how you would approach the full backend, start to finish. We want to hear your thinking, not see finished code. Problem 1: The Full System, Start to Finish Before the specific problems below, we want you to walk through the whole backend as you see it. Treat this as if you had won the project and were explaining your plan to us on day one. In your Loom, address: Walk through the full flow: a client logs in, triggers a module, the module runs, a human approves it, the result goes live. What is happening on the backend at each of those steps? What would your database schema look like, at a high level, to support that flow? What tools, languages, and services would you use, and why those specifically over alternatives? How would you structure the project so it could be handed off or expanded by another developer later, not just work while you're the one maintaining it? Realistically, how long would this take you to build to a working first version? Break it down by phase if you can (schema and auth, module run logic, approval flow, billing integration). What is your rate, and what would this project cost us based on your time estimate? Problem 2: Multi Tenant Data Isolation Two types of users log into the platform. Internal team members, who can see data across every client Client users, who must only ever see their own company's data Every client facing table (module runs, approvals, generated content, calendars) will carry a client_id column. The naive approach is to filter by client_id in the application code on every query. We do not want that approach, since one missed filter in one endpoint means client A sees client B's data. In your Loom, address: How would you enforce this isolation at the database level, not just in application code? Have you used Postgres row level security in production? Walk through how a policy would work for this schema. How would internal team accounts bypass the isolation to see across all clients, without weakening the isolation for client accounts? Problem 3: Cost Control on AI Spend Every module run calls a paid AI API. Every API call costs real money based on tokens used. Client companies pay a flat monthly fee for a set number of module runs. If a client's usage is not capped before the API call fires, they can burn through cost that our monthly fee does not cover, and we lose money on that account. We will track every API call in a table like this: usage_events (id, client_id, module_run_id, model_used, input_tokens, output_tokens, cost_usd, created_at) In your Loom, address: Where in the request flow would you place the check that compares a client's current usage against their plan limit? What happens to a module run if the client is over their limit? Walk through the state it should land in. How would you prevent a retried or duplicate request from charging a client twice for the same module run? How would you structure the code so we could route cheaper tasks to a lower cost model and reserve the expensive model for higher value tasks? What We Are Listening For Do they walk through the full system clearly, or only the parts we already gave them language for? Do you reach for row level security on your own, or only when prompted? Do you mention the cost check as a step that happens before the API call, not after? Do you ask about scale (how many clients, how many module runs a day) before describing your approach, or jump straight to a generic answer? Is your reasoning specific to this schema and this business model, or is it a general backend answer that could apply to any app? Is the timeline realistic, or does it sound like a number picked to look impressive? Does the pricing match the scope they just described, or does it feel disconnected from the work? What to Submit A Loom video, twenty to thirty minutes, walking through the full system plus the isolation and cost problems above No code required. We want your reasoning, not a working build A rough timeline estimate broken down by phase Your rate and a total cost estimate for a working first version If you have built row level security or usage metered billing before, mention the project and what you learned Stack Context Postgres via Supabase, including Supabase Auth Node.js backend An AI API for module logic Stripe for subscription billing and metered overage Send your Loom link along with your resume. We will review within a few business days.