Excel to Tech — The Master Translation Table

This is the most important page in the glossary.

Every concept in web development has an analogy in the world you already work in. Excel is not a toy — it is a sophisticated data and logic tool. The mental models you have built around it transfer directly. This page makes those connections explicit.

Use this as your primary reference whenever something in the program feels unfamiliar. Before asking "what is this?", ask "what does this remind me of in Excel?" The answer is usually here.

The Table

Full Explanations

Formatted Reporting Sheet → Frontend / React

Excel: The pivot table summary sheet the partner sees. Formatted with charts, slicers, conditional formatting, dropdown menus. Pulls data from the raw sheet and displays it in a business-readable format. Users interact with it — they filter, sort, drill down.

Tech equivalent: The React frontend. This is everything the user sees and clicks on in a browser or mobile app. It fetches data from the backend and displays it in a human-readable, interactive format. Users click buttons, fill forms, see charts.

Why the analogy holds: Both are presentation layers. Both pull data from a source (raw data sheet / database), apply formatting and business logic, and present it to a human. Neither stores data permanently — they display what they fetch. Change the source data and the display updates.

Where you will see this: Every React component you build. The entire frontend module of the curriculum. Project 1 (static site) and Project 2 (full stack) both focus heavily on building this layer.

As a CA building client-facing tools, the frontend is everything your clients interact with — the screen that earns their trust or loses it.

Raw Data Sheet → Backend / Database

Excel: The messy, unformatted sheet with thousands of rows. Column A is an ID, column B is a client code, columns C through Z are raw data. Formulas in hidden columns perform calculations. Macros process data transformations. No user ever looks at this sheet directly.

Tech equivalent: Supabase (PostgreSQL database + Edge Functions). All data lives here permanently. Business logic runs here. Users never interact with it directly — they interact with the frontend, which calls the backend on their behalf.

Why the analogy holds: Both are the source of truth. Both perform computation that users do not see. Both require careful, deliberate structure — a poorly organized raw data sheet breaks every formula that depends on it, just as a poorly designed database schema breaks every feature that depends on it.

Where you will see this: The backend module. Every Supabase table, RLS policy, and Edge Function. The schema design session early in Phase 3.

As a CA, the backend is where client financial data lives — the place where structure, security, and accuracy matter most. Poor backend design creates data integrity problems that surface months later in ways that are expensive to fix.

VLOOKUP Across Sheets → API Call

Excel: =VLOOKUP(A2, Clients!B:F, 3, 0) — your current sheet asks the Clients sheet "give me the city for client code A2." The Clients sheet responds with a value. No manual lookup — it is automatic and immediate.

Tech equivalent: A fetch request from the frontend to the backend. Your React component says "give me the job listings for city Mumbai." Supabase responds with a list of matching records. No manual data transfer — the SDK handles the communication automatically.

Why the analogy holds: Both represent one piece of the system asking another for specific data, receiving a response, and using that response to display or calculate something. Both have a "caller" (the formula / the React component) and a "source" (the Clients sheet / the database).

Where you will see this: React Query's useQuery hook in every data-fetching operation. The supabase-js SDK calls. The networking module when you inspect the Network tab in the browser.

Excel Password Protection → Authentication

Excel: A password on the Excel file. Anyone who wants to open it must know the password. If they do not, they see nothing.

Tech equivalent: The login screen and session management. Users must authenticate (prove who they are) before accessing the application. Supabase handles this — email/password login, Google OAuth, magic links.

Why the analogy holds: Both are gatekeeping mechanisms. Both verify identity before granting access. The password is the credential; the authentication token is the "verified" stamp that persists through the session.

Where you will see this: The auth flow — login page, signup page, ProtectedRoute component, session management. This is one of the first backend features you implement in Project 2.

Every CA client portal you build will have authentication — it is the first barrier between your clients' data and the rest of the internet.

Sheet-Level Protection → Row Level Security (RLS)

Excel: Different users are password-protected from different sheets. The tax team can see Sheet 1 (tax data) and Sheet 2 (client contacts) but not Sheet 3 (partner billing). The billing team sees Sheet 3 but not Sheet 1. The protection is in the file itself — not in an email asking people not to look.

Tech equivalent: Row Level Security in Supabase/PostgreSQL. Database policies that control, at the database level, which rows each user can see and modify. A candidate can only read their own job applications. A recruiter can only read applications to their own job postings. An admin can read everything.

Why the analogy holds: Both protect data at the storage layer, not the display layer. Both use identity to determine access. Both mean that even if someone bypasses the interface and goes directly to the storage, they cannot access unauthorized data. This is far more secure than only hiding data in the UI.

Where you will see this: Every Supabase table requires RLS policies. You write and test these during the backend module. Every table in Udyogaseva has carefully crafted RLS policies that enforce exactly the access rules described above.

As a CA, RLS is not optional — it is the difference between a portal where clients can accidentally see each other's data and one where that is structurally impossible. This is the concept that will make the most sense to you given your professional background in data confidentiality.

Named Ranges → TypeScript Interfaces and Types

Excel: Instead of referencing $B$5 in 200 formulas, you name the cell GST_RATE. Every formula that uses that rate references GST_RATE. The name makes the formula readable and maintainable.

Tech equivalent: TypeScript interfaces and type definitions. Instead of writing (user) => user.some_property and hoping you remembered the property name correctly, you define:

Every time you write user., your editor shows a dropdown of valid properties. user.nme is flagged immediately — the property does not exist.

Why the analogy holds: Both replace ambiguous references with meaningful names. Both make the system self-documenting. Both catch errors early — you know immediately that you used the wrong name, rather than discovering a broken formula or a runtime error later.

Where you will see this: TypeScript is used throughout every project. The database.types.ts file (auto-generated from your Supabase schema) contains interface definitions for every database table. You import and use these everywhere.

As a CA, you already create named ranges and structured templates instinctively. TypeScript interfaces are that same discipline applied to code — every piece of data has a defined shape, and deviations are caught immediately.

Formulas and Functions → JavaScript Functions

Excel: =VLOOKUP(), =SUMIFS(), =IFERROR() — pre-built, reusable logic blocks. You pass inputs; they return outputs. You do not rewrite the calculation logic every time.

Tech equivalent: JavaScript functions. You write a function once:

Call it anywhere: calculateGST(25000, 18) returns 4500. Like Excel functions, you pass inputs and get outputs without re-writing the logic.

Why the analogy holds: Both encapsulate logic behind a name. Both accept inputs and return outputs. Both make code readable — calculateGST(invoiceAmount, gstRate) is as readable as =SUM(B2:B50) once you know the function name.

Where you will see this: Functions are the most fundamental concept in all programming. You write them from day one, in every file, for every piece of reusable logic.

VBA Macros → Edge Functions

Excel: A VBA macro that runs on the server when triggered — consolidates 50 workbooks, sends email alerts, talks to external data sources. The macro does work that the formula layer cannot do alone. It runs on demand, not continuously.

Tech equivalent: Supabase Edge Functions. Small server-side programs that run when triggered — verify payments, send transactional emails, call external APIs. They have access to secrets (API keys) that cannot be exposed to the browser.

Why the analogy holds: Both are triggered, on-demand execution of server-side logic. Both can access resources the presentation layer (Excel UI / React frontend) cannot access directly. Both handle the "heavy lifting" that cannot be done in a formula or a browser-side component.

Where you will see this: Udyogaseva's payment verification Edge Function. EduTrack's fee receipt email function. Any integration with a third-party service (KYC, SMS, payment gateway) happens in Edge Functions.

As a CA, Edge Functions are where sensitive server-side operations happen — payment verification, GST API calls, document generation. These run on secure servers, not in the browser, which is why API keys and credentials stay safe.

Column Data Validation Rules → Zod Schema Validation

Excel: A validation rule on a column: "Must be a number between 0 and 100. Show an error if not." The spreadsheet rejects invalid data immediately, at the point of entry.

Tech equivalent: A Zod schema:

When a form is submitted, Zod validates every field. If salary is -500 or email is "not-an-email", Zod returns specific error messages before the data reaches the database.

Why the analogy holds: Both validate data at the boundary — before it enters the system. Both provide field-specific error messages. Both are declarative — you describe the rules, the tool enforces them.

Where you will see this: Every form in every project. React Hook Form + Zod is our standard form validation stack.

As a CA, bad data in means wrong reports out. Zod is how you enforce clean data at the entry point — the form submission — rather than discovering problems after the data is already in the database.

Google Sheets Cloud Access → Cloud Hosting / Vercel

Excel: A file on your laptop. Laptop is closed — inaccessible. Google Sheets: the file lives on Google's servers. It is accessible from any device, 24/7, with automatic backups.

Tech equivalent: Deploying to Vercel. Your React app runs on Vercel's servers worldwide. Anyone with the URL can access it from any device at any time. Your laptop being off does not affect availability.

Why the analogy holds: Both move from local (your machine) to cloud (someone else's always-on infrastructure). Both enable global access. Both provide reliability that local storage cannot.

Where you will see this: From Project 1 onward, every project is deployed to Vercel. Deployment is part of the definition of "done."

Building something that only runs on your laptop is not done. Vercel is how it becomes accessible to clients and the world — in 60 seconds, automatically, every time you push a change.

Track Changes / Version History → Git

Excel: Track Changes shows who changed what cell, when, and from what value to what value. Version History lets you restore any previous saved version. But it only works per-file, only when enabled, and breaks with too many collaborators.

Tech equivalent: Git version control. Tracks every change to every file in the entire project. Every commit is a named snapshot with a message. Restore any file or the entire project to any previous state. Works with unlimited collaborators, across unlimited files, reliably.

Why the analogy holds: Both create a history of changes. Both allow rollback. Git is simply the professional, programmers' version of this concept — more powerful, more reliable, always-on, and applies to an entire project rather than a single file.

Where you will see this: From day one of every project. git commit is as routine as saving a file.

As a CA, you already understand why audit trails matter — who changed what, when, and why is a professional requirement. Git gives your code that same discipline automatically, without any extra effort.

File Copies ("Model_v2_backup.xlsx") → Git Branches

Excel: Before a major change, you save "Model_v2_backup.xlsx" as insurance. If something goes wrong, you can revert. But now you have two files to manage, and merging changes between them is manual and error-prone.

Tech equivalent: Git branches. Create a branch called feature/add-fee-payment. Work on it. If it goes wrong, delete the branch — main is untouched. If it goes well, merge the branch — Git handles combining changes automatically.

Why the analogy holds: Both are strategies for "protect the working version while I try something new." Git branches are infinitely superior: they are instant (no copying), automatic (Git manages them), mergeable (Git combines changes), and free to create as many as needed.

Where you will see this: Every feature you build lives on its own branch. Branch → work → PR → review → merge is the standard development cycle.

OneDrive / Network Drive → GitHub (Remote Repository)

Excel: The shared drive where the master file lives. Everyone accesses it from their own machine. It is the source of truth. Backed up. Accessible to the whole team.

Tech equivalent: GitHub. The online home for your Git repository. Your local Git history is pushed to GitHub. Everyone pulls from GitHub. GitHub is the source of truth. Backed up. Accessible from any machine.

Why the analogy holds: Both are the central, shared storage location that all collaborators sync to and from. Both provide off-machine backup. Both are the authoritative source — what is on the shared drive / on GitHub is "official."

Where you will see this: Every project has a GitHub repository. Vercel connects to GitHub. Pull Requests happen on GitHub.

Pivot Table Refresh → React Query Cache Invalidation

Excel: You click Refresh Data on a pivot table. The pivot updates to show the latest data from the source sheet. Until you refresh, you are looking at the last cached version.

Tech equivalent: React Query automatically manages data freshness. After a mutation (updating or creating a record), the relevant queries are invalidated. React Query refetches the data in the background. The UI updates to show the latest data — without a page reload.

Why the analogy holds: Both are cache management strategies. Both separate "stored/cached" data from "fresh" data. Both have a mechanism to trigger re-fetching. React Query does this automatically based on rules you configure (staleTime), rather than requiring a manual click.

Where you will see this: Every data-fetching hook in the application. React Query is how we fetch all data from Supabase.

Conditional Formatting → Conditional Rendering

Excel: A cell turns red when the value is negative. A row turns yellow when a deadline is within 7 days. The formatting changes automatically based on the cell's value. You write the condition once; Excel applies it consistently.

Tech equivalent: Conditional rendering in React. A badge turns red when status is "rejected". A warning banner only appears when the deadline is close. The JSX changes based on state or data values:

Why the analogy holds: Both show different visuals based on data conditions. Both are declarative — you describe the condition and the outcome; the system handles when to apply it.

Where you will see this: Status badges, alert messages, empty states, role-based UI rendering — all of these are conditional rendering.

Auto-Calculate on Cell Change → useState (Reactive State)

Excel: Cell B1 contains 10 (quantity). Cell C1 contains 1000 (price). Cell D1 has the formula =B1*C1 (total). Change B1 to 20 — D1 instantly updates to 20,000 without any manual refresh. Excel tracks the dependency and updates automatically.

Tech equivalent: React's useState. A component that stores a quantity in state automatically re-renders everything that depends on that quantity:

Change the quantity via setQuantity(20) and the total updates instantly everywhere on screen.

Why the analogy holds: Both are reactive systems. Both track dependencies. Both update all dependent values automatically when a source value changes. This is the core mental model for React — UI as a function of state.

Where you will see this: Every interactive element in every UI. Forms, filters, counters, toggles — all of these use state.

Sheet Tab Names → Database Table Names

Excel: Sheet tabs — "Clients", "Invoices", "Payments". Each tab is a separate entity with its own rows and columns.

Tech equivalent: Database tables — profiles, students, fee_records, attendance. Each table is a separate entity with its own rows (records) and columns (fields).

Why the analogy holds: Both organize different types of data into named containers. Both have relationships between them. An invoice belongs to a client (via client ID) — an application belongs to a job (via job ID). The structural thinking is identical.

Where you will see this: Schema design. Every Supabase project starts with defining the tables. Understanding table structure is foundational.

Column Headers → Database Schema / Column Definitions

Excel: The first row: "Client_ID", "Client_Name", "Email", "City", "GSTIN". These headers define what data goes in each column. Enforced by convention, not by the spreadsheet itself.

Tech equivalent: Database column definitions in a migration:

These definitions are enforced by the database itself. The not null constraint is mandatory. The unique constraint prevents duplicate emails. The database rejects data that violates these rules — unlike Excel, which accepts anything in any column.

Why the analogy holds: Both define the structure that data must conform to. The difference is enforcement — Excel header rows are suggestions; database column definitions are laws.

Where you will see this: Every migration file. The Supabase dashboard table editor. The database.types.ts TypeScript type file.

VLOOKUP Foreign Key → Database JOIN / Foreign Key

Excel: =VLOOKUP(A2, Clients!B:F, 3, 0) — the invoice row in Sheet 2 stores a client code. The VLOOKUP uses that code to retrieve the client's city from Sheet 1. The client code is the link between the two sheets.

Tech equivalent: A foreign key in the database. The applications table has a job_id column that references the id column in the jobs table. A JOIN query retrieves application data together with the job's title and company:

Why the analogy holds: Both are mechanisms for connecting related data stored in separate containers. Both use a shared ID as the link. The difference is that database JOINs are computed at query time by the database engine — far more powerful than VLOOKUP for complex multi-table relationships.

Where you will see this: Schema design decisions. Supabase query patterns using .select("*, jobs(title, company)"). Every time related data from multiple tables is needed in one query.

Excel Add-In → npm Package / Library

Excel: Power Query, Analysis ToolPak, Solver — pre-built functionality that extends Excel. Someone solved a complex problem and packaged the solution. You install it and use their work.

Tech equivalent: npm packages — React, Tailwind, Zod, React Query, Supabase JS. The open-source community has solved most common problems and published the solutions as packages. We install and use them.

Why the analogy holds: Both extend the base tool with pre-built capabilities. Both are maintained by their creators (Microsoft / open-source community). Both save you from re-inventing solutions to problems that have already been solved.

Where you will see this: package.json lists every dependency. npm install <package> adds a new one. The entire program's stack is built on carefully chosen packages.

IFERROR() → Error Boundary / try-catch

Excel: =IFERROR(VLOOKUP(A2, Clients!B:F, 3, 0), "Client not found") — if the lookup fails for any reason, show "Client not found" instead of crashing the formula.

Tech equivalent: Error Boundaries in React and try-catch in async code. If a component crashes due to an unexpected error, the Error Boundary catches it and shows a friendly message ("Something went wrong — please refresh") instead of crashing the entire page.

Why the analogy holds: Both are graceful degradation strategies. Both prevent one failure from cascading. Both show the user something meaningful instead of a broken, empty, or confusing interface.

Where you will see this: Error Boundaries wrapping major UI sections. try-catch around database operations in Edge Functions. Error state handling in every React Query query.

IF() Formula → Conditional Logic

Excel: =IF(C2>100000, "High Value", "Standard") — check a condition; return one value if true, another if false.

Tech equivalent: JavaScript's ternary operator and if-else blocks:

Or in JSX:

Why the analogy holds: Both evaluate a condition and branch based on the result. The syntax is different; the logic is identical.

Where you will see this: Everywhere. Conditional rendering, conditional styling, conditional form validation, conditional route guards — every non-trivial application is full of if-else logic.

Dragging a Formula Down 500 Rows → A Loop

Excel: You write a formula in D2 and drag it down to D501. Excel applies the formula to each of the 500 rows in sequence. Same logic, applied repeatedly to different data.

Tech equivalent: A loop or array method:

map() applies the same function to each item in the array — exactly like dragging a formula down.

Why the analogy holds: Both apply the same logic to each item in a collection. Both produce a new result for each item. In React, you will use .map() to render a list of components from an array of data — turning an array of job objects into an array of <JobCard> components.

Where you will see this: Every list or table in the UI. Student lists, fee payment history, attendance records, user tables — all rendered with .map().

The One Analogy That Does Not Hold

There is one important place where the Excel analogy breaks down, and you need to understand it:

Excel: Designed for one user working on one file at a time. Collaboration is possible but always involves coordination (who has the file open right now?).

Web app: Designed for thousands of users interacting simultaneously, in real time, from different devices. The database handles concurrent writes without corruption. The UI can update in real time as other users make changes.

This difference is why:

• We need RLS (the database itself enforces rules — not a "please don't look at this tab" convention)
• We need authentication tokens (the system must know which of 10,000 simultaneous users each request comes from)
• We need React Query cache management (data is stale almost immediately in a live system)
• Soft deletes matter (you cannot undo a hard delete when 10 other records already reference that row)

The Excel analogies get you to understanding. Multi-user, real-time scale is what pushes beyond them.