The Excel Architecture Model

Before we open Supabase or write a single SQL query, we need to understand why software has a backend at all. What problem does it solve? What breaks without it?

The best way to answer that question is with a tool you already know.

The file has three sheets. Each sheet is a different answer to the question: "How do I show my client list to myself?"

Sheet 1 — The Database Tab

Click the Database tab. This sheet is intentionally plain. No colours, no logic — just columns and rows.

This is what a backend database looks like underneath every application you have ever used.

This is the single source of truth. Every other view in the application reads from here. There is no copy of this data anywhere else. If you update a row here, every view that reads this sheet reflects the change immediately.

In your CA Practice Manager app, this is your Supabase clients table. Identical columns. Same structure. The only difference: Supabase stores it on a server so any browser, any device, any location can read it.

Sheet 2 — App with Backend

Click the App with Backend tab.

Notice cell B2 — the yellow cell with a dropdown. This represents your login. You are "logged in as" one of the CAs in the firm.

Try this right now:

1. Click cell B2
2. Change it from Ravi to Priya
3. Watch what happens to the table below

When you switch to Priya, you see only Priya's clients. Ravi's clients are replaced by [Hidden by RLS].

Switch to Admin — all 10 clients are visible.

Switch back to Ravi — only Ravi's clients.

That is Row Level Security. The same data is in the database. But each user only sees what belongs to them. The rule: "show this row only if the assigned CA matches the logged-in user, or if the user is Admin."

In this Excel file, the rule is written as a formula in every cell:

=IF(OR(Database!F4=$B$2, $B$2="Admin"), Database!B4, "[Hidden by RLS]")

In your Supabase database, the same rule is written as a SQL policy:

create policy "CA can read own clients"
  on clients for select
  using (auth.uid() = user_id);

Same logic. Different syntax. Same result: the data is there, but you only see yours.

Now try this:

Go to the Database sheet and change the Monthly Fee for C001 (Mehta Industries) from 12000 to 15000. Press Enter and switch back to App with Backend. The fee has updated automatically.

This is the backend. The frontend does not store the data — it reads it from the source. Change the source, the frontend reflects it immediately.

Sheet 3 — App without Backend

Click the App without Backend tab.

This looks identical to Sheet 2. Same layout, same columns. But look at the warning at the top:

LAST MANUALLY UPDATED: 01 Jun 2026

And at the bottom:

MISSING: C009 - Joshi Pharma Pvt Ltd and C010 - Kapoor Retail LLP were added on 5 Jun 2026 — nobody updated this file, so they are invisible here.

This sheet has no formulas linking it to the database. Every value was typed directly. When someone added two new clients on June 5, this sheet had no way to know. It sits there, silently incomplete.

Now go back and change the Monthly Fee for C001 in the Database sheet again. Switch to this sheet — the fee has not changed. It still shows the old value. Because there is no connection.

There is also no security. This sheet has no login dropdown. You cannot show Ravi only his clients. Anyone who opens the file sees everyone. Because Row Level Security requires a live connection to a database that enforces the rule. A hardcoded sheet cannot enforce anything.

This is exactly what happens when developers build apps without a proper backend:

• Data goes stale immediately
• You can't enforce access rules
• Every update requires manual intervention
• Two people update different copies and the versions diverge

The Three-Layer Map

Here is how each sheet maps to the real technology you will use in Weeks 5–10:

The only thing that changes when we move from Excel to Supabase + React is the tool. The concept — source of truth, access rules, live reads from a single location — stays exactly the same.

The One Question to Hold

Every time you make a decision about your application — where to store something, who can see it, how to display it — ask:

Is this the source of truth, or is this a view of the source of truth?

The database is the source. Everything else — your dashboard, your client list page, your compliance task table — is a view. Views read from the source. They do not copy it. They do not own the data.

When you understand that distinction, you understand every database design decision we make for the rest of this programme.

Check Your Understanding