Turn a Spreadsheet Into a Web App With Claude Code

Prepare a Safe Copy

A spreadsheet is a perfectly good tool for simple work. This guide is for the one that has outgrown direct row editing — where people edit the wrong cells, statuses are inconsistent and several people need access at once.

Leave your original spreadsheet exactly as it is Export a copy of the data, preferring CSV because it is easy to inspect and migrate If several tabs hold related datasets, export each relevant tab as its own file Put the exported file or files in a folder inside your Claude Code project

Project folder migration-data

IMPORTANT

Never let the migration work on your original file. The spreadsheet stays untouched and keeps running the business until the new app is verified — it is your backup for the whole of this guide.

You do not need to retype your columns anywhere. Claude reads the real file in the next task.

Understand the Spreadsheet

Open the project in Claude Code and use this prompt. It only reads — nothing is built or imported yet.

Analyze the Spreadsheet

Ask Claude to understand what the spreadsheet tracks, which columns matter and what the business actually does with the data.

Inspect the spreadsheet file or files in this project. Do NOT build anything yet. Do NOT modify the spreadsheet. Do NOT import data yet. First understand the DATA and the BUSINESS WORKFLOW it represents. 1. INSPECT THE FILE Report the filenames, the sheet or tab where relevant, the row count, the columns, the likely field types, empty or missing values, obvious duplicate rows, inconsistent values, date formats, numeric fields, status-like fields, identifiers, and any relationships between files or tabs. Do not print large amounts of private spreadsheet data. Use representative examples only where they are necessary. 2. UNDERSTAND THE BUSINESS Work out what ONE ROW represents — one client, one order, one project, one request, one product, one job, one task, or something else. Then identify what staff appear to DO with these records: add them, update a status, assign dates, change quantities, write notes, search, filter, mark something complete. Do not invent workflow the spreadsheet does not support. 3. CLASSIFY THE COLUMNS For each important column, classify it as one of: IDENTIFIER, TEXT, NUMBER, MONEY, DATE / TIME, BOOLEAN, STATUS, RELATIONSHIP, NOTES, CALCULATED / DERIVED, or POSSIBLY UNNECESSARY. 4. CALCULATED COLUMNS Identify formulas and derived values where you can. Do not assume every calculated spreadsheet field should become permanent database data. For each one, say whether the future app should calculate it dynamically, store it, or drop it — based on how it is actually used. 5. DIRTY DATA Identify migration risks: duplicate identifiers, mixed date formats, empty required fields, different spellings of the same status, numbers stored as text, duplicate records. Do NOT silently clean uncertain business data. Flag anything that needs my confirmation. 6. SENSITIVE DATA Say whether the sheet contains private information such as customer contact details, internal notes or financial information. That data must not be exposed publicly in the future application, and you should not reproduce those values unnecessarily in your output. Return: SPREADSHEET AUDIT Files: Rows: What one row represents: Business workflow: Important columns: Status fields: Calculated fields: Possible relationships: Data-quality issues: Sensitive/private fields: Migration risks: Columns that may not belong in the new app: Questions requiring confirmation: Then return exactly one: READY TO DESIGN APP or: NEEDS A DECISION Do not modify files yet.

Read the audit properly — this is the part that decides what gets built. Answer any question it raises about a status, a date format or a duplicate before moving on.

Turn the Workflow Into an App

Now turn what the spreadsheet does into the smallest app that can replace it.

Plan the Spreadsheet Replacement

Turn the spreadsheet's actual workflow into a simple protected business app without copying the spreadsheet interface.

Using the approved Spreadsheet Audit, design the smallest useful web application that replaces normal spreadsheet editing. Do NOT build yet. 1. THIS IS NOT A PRETTIER TABLE Do not simply recreate rows and columns inside a nicer grid. The app should give staff an operational interface that fits the real workflow. A sheet of Name / Email / Status / Next Follow-Up / Notes might become a list, a record detail view, a controlled status, a follow-up field and private notes — but only if that is what this spreadsheet actually represents. Build what the DATA says, not what a generic business app usually looks like. If this sheet tracks projects, design project work. If it tracks orders, design order management. If it tracks requests, design request handling. Do not force CRM concepts such as lead, opportunity, sales pipeline or won/lost onto a spreadsheet that is not about sales. 2. THE APP Define the purpose, who uses it, and the main business record the app manages. Use the minimum useful pages — typically a login, a dashboard or list, a record detail view, and a create or edit form. Do not add navigation the workflow does not need. 3. LIST The main list shows only the information needed to identify and act on a record quickly. Do not show every field at once. 4. SEARCH AND FILTERS Create only the filters the real workflow justifies — status, date, category or an assigned value are the usual ones. Add simple search over the text fields that are genuinely searched. 5. STATUS If the spreadsheet has a workflow or status column, convert it to controlled application values, so "In progress", "In Progress", "working" and "Started" stop being four different things. But do not merge values where the business meaning is uncertain — ask me instead. 6. DASHBOARD Add only useful operational information: records needing action, overdue records, open requests, records by approved status. No decorative graphs, no meaningless totals, no vanity dashboard. 7. ACCESS This is a protected staff application. Use Supabase Auth, and keep one trusted staff or admin access model. Do not build complex roles unless this workflow genuinely requires them. Return: WEB APP PLAN Purpose: Users: Main record: Pages: Record fields: Create workflow: Edit workflow: Status model: Search: Filters: Operational dashboard: Authentication: Authorization: Fields intentionally removed: Calculated fields: Migration approach: Features deliberately excluded: Then return exactly one: READY TO BUILD or: NEEDS A DECISION

If the audit says this sheet is really stock levels — quantities in, quantities out, what is left — the dedicated inventory guide is the better path than a general records app.

Build and Deploy an Inventory Management System With Claude Code

Use this instead if your spreadsheet is really tracking stock quantities.

/video/build-inventory-system-claude-code

Confirm the Replacement

Make sure the approved plan covers exactly this:

The original workflow is understood

The app reflects business actions, not spreadsheet cells

Only useful fields are included

Private data is protected

Search and filters are defined

The import plan is defined

No unnecessary features were added

Create or Reuse Supabase

If this project already uses the correct Supabase project, reuse it — do not create a second one. If Supabase is missing, create the project first:

Open Supabase

Create the project, or open the one this app should use.

https://supabase.link/r4gdwhi

The browser side of the app needs only the Project URL and the Publishable key, under the environment-variable names this project already uses.

IMPORTANT

The Supabase Secret key and the service-role key are server-side values only. A migration script may use them outside the browser, but they never belong in client code or in the repository.

Add a Database to Any AI-Built Website or Web App With Supabase

Use this if this is your first Supabase project.

/video/add-a-database-to-any-ai-built-website-or-web-app-with-supabase

Create the Data Model

Turn the approved structure into real tables — not a copy of the sheet.

Create the App Database

Turn the approved spreadsheet structure into a clean Supabase data model with protected staff access.

Using the approved Spreadsheet Audit and Web App Plan, create the minimum Supabase data model this application needs. Do not mechanically create one database column for every spreadsheet column. 1. DATA MODEL Normalize only where it genuinely improves the workflow, and do not over-normalize a small business app. If the spreadsheet is one clear entity, one primary table may be enough. If several tabs represent genuinely related concepts, use the smallest correct relationships. 2. FIELD TYPES Use appropriate database types: dates as dates or timestamps, numbers as numeric types, booleans as booleans, statuses as constrained or validated values. Do not keep an obviously wrong type just because the original cell was text. 3. IDENTIFIERS Create stable database ids. Where the spreadsheet has a real business identifier, preserve it where it is useful. Never rely on a row number as permanent identity. 4. STAFF AUTHORIZATION Use proper staff or admin authorization. Do not treat every authenticated Supabase account as automatically allowed to reach business data. Store staff status somewhere a signed-in user cannot change about themselves, and check it in the database rules. Do not rely on hidden routes, localStorage, frontend state or client-editable metadata. Tell me how to grant the FIRST staff account safely — for example one reviewed SQL statement run once in the Supabase SQL Editor. 5. PRIVATE DATA This is an internal business app. Do not give anonymous visitors read access to business records unless the approved plan explicitly requires public data. 6. ROW LEVEL SECURITY Use appropriate RLS and access rules. Do not disable RLS to make CRUD easier, and do not use a broad USING (true) on private business tables without a real reason. 7. IMPORT SUPPORT Design the schema so the existing spreadsheet records can be imported safely. Where it helps, add a source or migration identifier and the unique constraints that prevent a duplicate import. Keep migration-only fields out of the normal product interface unless they stay useful afterwards. Return: 1. Tables reused 2. Tables created 3. The final field mapping 4. Fields intentionally not migrated 5. How calculated fields are handled 6. Relationships 7. Staff authorization 8. The RLS / access model 9. Duplicate and repeat-import protection 10. ONE reviewed SQL / migration block where appropriate 11. Any blocker Do not use destructive DROP statements. If a table with the same name already exists, warn me instead of replacing it. Do not execute destructive database changes automatically, and do not build the interface yet.

Review the SQL before running it in the Supabase SQL Editor, and grant your first staff account the way the answer describes.

Build the Operational App

This is the interface staff will use instead of editing rows.

Build the Business Web App

Build the protected interface staff will use instead of editing spreadsheet rows.

Build the approved business application using this project's existing design system and the new Supabase data model. Do not recreate the spreadsheet visually. 1. ACCESS Use Supabase Auth, reusing trusted authentication if the project already has it. The app requires authorized staff access, and a signed-in account without staff access sees a clear "no access" state. 2. MAIN LIST Build a useful operational view showing only the important summary fields, with the approved search, filters, status filtering and sorting where it helps. 3. RECORD DETAIL Create a clear detail and edit view with related information grouped logically. Do not present thirty spreadsheet columns as one giant form when they can be organized. 4. CREATE Let staff create records from the app, validating required fields. Do not expose raw database fields staff should not control. 5. EDIT Let staff edit only the appropriate fields. For controlled values use a select, buttons, a toggle or a date picker rather than free text. 6. STATUS Where a workflow status exists, use the approved controlled values and transitions. Do not build a workflow engine. 7. CALCULATED VALUES Where the spreadsheet used formulas, compute those values through the approved application or database logic. Staff must never have to recalculate something by hand. 8. STATES Add proper loading, empty, success and error states. Never show a raw Supabase error to a normal user. 9. RESPONSIVE Keep the app usable on desktop, tablet and phone, according to how this workflow is actually done. When finished, report the routes, how sign-in and the staff check work, where staff permissions are enforced in the database, the list view, the detail view, and the create and edit behaviour.

Supabase is the backend you configure once. The app is what the business opens every morning.

Verify the New Workflow

Create two or three test records by hand and do a normal day's work in the app before importing anything real:

Create a record

Open it and edit the fields you would normally edit

Change the status, if your workflow has one

Set a date, if your workflow uses one

Save a note, if your workflow uses one

Search for the record

Filter the list down to it

Refresh and confirm everything persisted

If anything here is more awkward than the spreadsheet was, fix it now. Do not import hundreds of real records into a workflow that has not been tried.

Import the Existing Spreadsheet

Move the real records across — with a dry run before anything is written.

Import the Spreadsheet Data

Clean and import the approved spreadsheet copy without duplicating records or changing the original source.

Migrate the approved spreadsheet data into the new Supabase model. Use the COPY or EXPORT inside this project. Do NOT modify the original spreadsheet. 1. BEFORE IMPORT Validate the expected file, the expected columns, the row count, the required fields, the approved status mappings, date parsing, numeric parsing and duplicate identifiers. Do not silently guess ambiguous data. Report uncertain records separately. 2. DRY RUN FIRST Before inserting anything, perform a dry-run analysis and report: ROWS FOUND ROWS READY ROWS WITH WARNINGS ROWS BLOCKED POTENTIAL DUPLICATES Do not write any data in this pass. 3. IMPORT Once the mapping is safe, import the approved records using the smallest safe migration mechanism appropriate to this project. A migration or admin script may use trusted server-side credentials, but never expose a private credential in browser code. 4. DUPLICATES Make the migration safe against accidental repeat execution. Running the import twice must not create a second copy of the business's records. Use the source or business identifier, an upsert only where that is semantically correct, or explicit duplicate detection — whichever fits the real dataset. 5. ERRORS Do not silently skip failed rows. For each one report the row or reference, the reason, and whether it was imported. Do not print full sensitive records unnecessarily. 6. AFTER IMPORT Compare SOURCE ROWS against SUCCESSFULLY IMPORTED RECORDS and account clearly for skipped headers, intentionally excluded rows, duplicates and invalid or blocked rows.

Read the dry run before approving the real import. Rows with warnings and blocked rows are decisions for you, not for the importer to guess.

Verify the Migrated App

Compare the source with the app, then do real work on migrated data.

Verify the Spreadsheet Migration

Compare the source data with the new app and test the real workflow before retiring the spreadsheet.

Perform a focused post-migration verification. Do not add features. 1. DATA COUNTS Verify the expected records exist, that the import count reconciles with the source, and that no duplicates were created. 2. SAMPLE RECORDS Choose representative safe sample records and compare the important fields between the spreadsheet and the web app: text, status, dates, numbers, relationships and calculated values where they apply. 3. WORKFLOW Using the migrated data: search for a record, filter the list, open a detail view, make one safe test update, create one new record, and verify everything persists. 4. AUTHORIZATION Verify authorized staff can use the app, that a signed-out user cannot reach private business data, and that an authenticated account without staff access cannot get in. 5. ORIGINAL SPREADSHEET Confirm the original source is unchanged and that nothing in the migration depended on deleting or altering it. Return exactly one: MIGRATION VERIFIED or: NEEDS ATTENTION Use MIGRATION VERIFIED only when the counts reconcile, the representative data matches, the normal app workflow works, authorization works, and no unexplained duplicate or import problem remains. If NEEDS ATTENTION, list only the migration blockers. Do not tell the business to retire the spreadsheet yet.

Keep using the spreadsheet as normal until the live app is verified in the next section. Nothing has been taken away from you yet.

Deploy the Web App

Before pushing to GitHub, check:

The project builds successfully

No .env or other secret files are being published

The migration files holding real business or customer data are removed or ignored

No Supabase Secret or service-role credential is in browser code

You know the production environment variable names

IMPORTANT

Your export holds real customer records. Never commit it to a public repository — remove it or add it to .gitignore first. If the codebase genuinely needs sample data, create a small fake sanitized file instead.

Push the project to GitHub with Claude Code or your normal GitHub workflow. If the app already has a repository, use it.

Deploy on Hostinger

Recommended plan: Business

USED IN TUTORIAL

https://www.hostg.xyz/SHK1P

Hostinger Websites Add Website Node.js Web App

Choose Import Git repository Connect GitHub and select the app's repository Review the detected framework and build settings Add the environment variables with your project's exact names Click Deploy and wait for the result

If staff sign-in needs it, set the production Site URL and Redirect URLs once the live address exists:

Supabase Authentication URL Configuration

Fix a Failed Website or Web App Deployment With AI

Use this if the Hostinger deployment fails.

/video/fix-a-failed-website-or-web-app-deployment-with-ai

Test the Live Replacement

Do one real piece of work on the production app:

Staff sign-in works and unauthorized users stay blocked

The migrated data appears

Search and filters work

A record detail view opens correctly

Create one safe production test record

Edit it and use the main workflow or status action

Refresh and confirm it persisted

The main workflow is usable on the screen sizes your staff actually use

Verify the Live Spreadsheet Replacement

Check that the Hostinger app can safely replace the spreadsheet workflow before the business switches over.

Perform a focused production verification of this app. Do not add features. 1. GITHUB Verify the approved source is current, that the real spreadsheet or business data is NOT committed, and that no secrets are committed. 2. HOSTINGER Verify the deployment succeeded, the correct repository and branch are connected, and the required environment variables exist. 3. SUPABASE Verify the intended production project is in use, that staff authentication and authorization work, and that the migrated data is still correct. 4. WORKFLOW Test the core workflow the spreadsheet used to handle: records can be found, new records can be created, approved fields can be updated, the status or workflow actions work, and values persist after a refresh. 5. DATA Verify representative migrated records still match the expected source values. 6. ACCESS Verify signed-out and unauthorized users cannot reach private business data. Return exactly one: WEB APP READY or: NEEDS ATTENTION Use WEB APP READY only when this application is ready to become the business's normal operational interface. If NEEDS ATTENTION, list only the blockers.

Switching over

Once you have WEB APP READY, the business can stop using the spreadsheet for normal daily work. Keep the original file as an archive for as long as you need it — nothing here asks you to delete it.

IMPORTANT

Pick a cutover moment and stick to it. Staff updating both the spreadsheet and the app for weeks is the one outcome worth avoiding: two sources of truth means neither one is correct.