From a spreadsheet to your first app

Most non-engineers who try to build their first app already have a spreadsheet running the workflow. The sheet is doing the job. It is also slowly breaking under the weight of the job. This page is the reference for turning that sheet into a real app without losing what the sheet already does well.

The companion page on scoping a first project covers picking the right project from scratch. This page is for the case where the project has already picked you. The sheet is the project.

The signals your sheet has outgrown itself

Any one of the signals below is a yellow light. Two or more, and the sheet has stopped scaling with the work.

1. More than one person edits the sheet, and at least once a month somebody overwrites somebody else’s row.
2. The rows are being copy-pasted into another tool (a CRM, an invoice, an email) more than once a day.
3. The workbook has more than six tabs that reference each other through INDEX/MATCH or VLOOKUP, and you are the only person who remembers how the lookups fit together.
4. The formulas have silently broken at least once, and nobody noticed for a week.
5. There is a tab called “do not edit” or “Sheet1 (old)” or “archive” and people still edit them.
6. Opening the sheet on a phone is something you actively avoid.
7. A new team member needs more than thirty minutes of explanation before they can use the sheet.

When any of these fire, the sheet is no longer a tool you are using. It is a tool that is using you.

The three patterns

There are three ways to promote a spreadsheet into an app. Picking the right one is most of the decision.

Pattern one: app on top, sheet as the database. The sheet stays. A custom page reads from it (and optionally writes back to it) through the Google Sheets API. The team can still open the sheet. The app gives them a cleaner surface for the daily work. This is the right first pattern for almost every project. It keeps the source of truth where the team already trusts it, and it lets you ship the first useful version in a weekend.

Pattern two: migrate the data, keep the sheet for archive. The data moves out of the sheet and into a real database (Airtable, Supabase, or a simple Postgres). The sheet stays around as the historical record, exported once if anyone needs to look back. The app reads and writes the new database. This is the right pattern when the sheet has hit a real ceiling: thousands of writes per day, multiple editors at once, or formulas the team needs to stop trusting.

Pattern three: keep the sheet, automate the copy-paste. The sheet stays the canonical view. A small script reads the sheet on a schedule and pushes the rows somewhere they are actually needed (a CRM, an invoicing tool, an email). No new app, no new UI. This is the right pattern when the sheet itself is fine, but the work happening around the sheet is what is wasting time.

Most first projects start with pattern one and graduate to pattern two only when the sheet itself starts to limit the app. Pattern three is the simplest and is sometimes all the team actually needs.

How to pick the one tab to promote first

Pick the tab that gets edited the most, not the one that has the most formulas.

The tab edited the most is the one carrying the daily workflow. Promoting it to a real surface saves the team the most time per week. The tab with the most formulas is the tab that is the hardest to migrate, which is a different problem and not the first one to solve.

If the workbook has more than one heavily-edited tab, pick the one whose readers and writers are the same people. A tab where one person enters data and a different person reads the totals is fine in a sheet. A tab where the same five people enter and read all day is where the app pays for itself.

What not to do

The mistakes below are the ones we see most often in freelancers and small teams who try this on their own, in roughly this order.

Migrating the data first. Almost no first project needs the data moved out of the sheet on day one. Moving the data adds two weekends of work, breaks every existing formula that referenced the sheet, and means the team is using the new tool before it is actually better. The order should be the opposite: build the app on top of the sheet, prove it is better, then migrate the data only if the sheet becomes the bottleneck.

Rebuilding every tab. A workbook with twelve tabs becomes twelve screens in the rebuild. The freelancer or operator burns out in week three. Pick one tab. Ship one screen.

Adding features the sheet does not have. The first version of the app should do what the sheet does today, faster and with less misery. New features come in version two, after the team has accepted the new surface for two weeks. Adding features before adoption is how good apps die before launch.

Letting the sheet drift. While the app is being built, the sheet keeps being the source of truth. If the team adds new columns to the sheet that the app does not know about, the app starts to lie. Either freeze the sheet’s column structure for the two weeks the build runs, or have the brief say explicitly which columns the app reads and which it ignores.

Building a second sheet inside the app. Recreating the spreadsheet grid inside the app is almost never the right move. Either the user wants a grid, in which case they should stay in the sheet, or they want something the grid was always wrong for (a job board, a single-record view, a status board, a chart), in which case build that, not the grid.

The four-weekend shape

A spreadsheet-to-app project that ships in four weekends tends to follow this rhythm. If any weekend ends without the milestone below, the scope needs a cut.

Weekend 1. A standing brief at the root of the project, and a working first screen with hardcoded data that matches the shape of three real rows from the sheet. The brief says which sheet and which tab. The screen shows one row, well.

Weekend 2. The screen is now reading from the actual sheet through the Google Sheets API. The page can be opened by anyone with a link. The data the page shows matches what is in the sheet, even when the sheet is edited.

Weekend 3. The page can write back to the sheet (or, if pattern two, to the new database). Edits made in the app appear in the sheet within five seconds. The verification ladder is passing clean on the workflow the app handles and on at least one workflow it does not touch.

Weekend 4. The page is shared with the people who use the sheet, with the sheet still open in another tab. Feedback gets collected. One small adjustment lands. The brief gets updated with what was learned.

If weekend one ends with no visible screen reading from the actual data, the scope is too big. Cut a column. Cut a feature. Ship the smallest visible thing first.

When to graduate from pattern one to pattern two

Pattern one (the sheet as the database) usually hits its limits in one of three places. None of them happens in the first month. All three happen eventually if the app gets used.

The first is concurrency. When five people are editing the sheet through the app at the same time, the Google Sheets API rate limits start to bite. The app starts to feel laggy. Writes occasionally lose to each other. At that point the data wants to live in Airtable or a real database, with the sheet kept as a read-only export.

The second is querying. Sheets are bad at “show me all the records where X is true and Y is false and Z is between two values.” The app starts to load slowly because it is pulling thousands of rows and filtering in memory. A real database fixes this in an afternoon of migration work.

The third is permissions. The sheet sees all the data, all the time. If the app needs to show person A only some rows and person B different rows, the right answer is a database with row-level permissions, not a sheet with cleverly hidden tabs.

When any of those three fire, the migration is worth a weekend. Before any of them fire, keep the sheet.

What to read next

• The reference page on scoping a first project from scratch: /learn/scoping-your-first-ai-app.
• The reference page on writing the standing brief once the scope is set: /learn/claude-md.
• The reference page on the director’s loop and the verification ladder: /learn/directing-ai-agents.
• The essay on writing a CLAUDE.md for a first-time builder: /blog/non-coders-claude-md.