How to turn a spreadsheet into an app, step by step

To turn a spreadsheet into an app, clean the sheet so each row is one record, split repeated information into separate tables linked by references, import each table as a CSV, then build screens around the jobs people do and set who can see and change what. Most of the effort goes into the data model. The screens are the quick part.

The seven steps below follow one running example: a single-tab equipment-loan sheet that becomes an app with three tables, Items, People and Loans. They apply to any app builder or database.

When has a spreadsheet outgrown itself?

A spreadsheet is the right tool for one person thinking with numbers. It starts to fail when several people use it to run a process. These are the signs worth taking seriously:

• The same facts are typed in many rows. A borrower's email appears in 40 rows, spelled three different ways, and fixing it means find-and-replace.
• Colour is a data field. Yellow means overdue, and only the person who set it up knows the legend.
• Tabs multiply. A tab per department or per month, each a hand-made copy of the same columns.
• Edits collide. Someone sorts one column without the rest, or pastes over a formula, and nobody notices for a week.
• People work from phones. Adding a row means scrolling sideways through 15 columns.
• Chores repeat. Every Monday someone filters for overdue rows and emails each person by hand.
• Different people need different slices. Borrowers should see only their own loans, but sharing the file shares every row in it.

Size is rarely the first problem. Excel's hard limit is 1,048,576 rows by 16,384 columns per worksheet, and Google Sheets allows up to 20 million cells per spreadsheet as of October 2026 (Google doubled it from 10 million in September 2026). Most process sheets hit the problems above long before either limit.

If three or more of the signs apply and more than two people depend on the sheet, it is working as a database without the parts of a database that prevent mistakes: types, relations, permissions and history.

The example: a single-tab equipment-loan sheet

A facilities team lends cameras, laptops and microphones to staff. Everything lives on one tab, one row per loan:

Four rows already show the trouble. The item name and serial are copied into every loan of that item. Maria has two email addresses and two spellings of her department. Dates come in three formats, one of them a phrase. Returned is "yes", "y" or blank, and a blank could mean "still out" or "nobody updated it".

Step 1: Clean the sheet

Work on a copy and leave the original untouched until the app is live. Then make the copy follow seven rules:

1. One header row. Delete titles, notes and blank rows above the column names. Row 1 holds the names, row 2 holds the first record.
2. No merged cells. Unmerge them and fill the value into every cell the merge covered. A merged "Marketing" across six rows becomes six cells that each say Marketing.
3. One record per row. A row that says "camera + tripod" is two loans and becomes two rows.
4. One type per column. All dates in one format (2026-09-15 imports most predictably), numbers without units (3, not 3 pcs), and yes/no columns with exactly two values.
5. A unique ID per row. Items already have one, the serial. Loans need their own, such as L-0001, L-0002.
6. No totals inside the data. Move subtotal rows, totals and pivot tables to another tab. An app calculates them.
7. No meaning in colour. If yellow means overdue, add a Status column or drop the colour, because overdue can be calculated from Due date.

Step 2: Split repeated information into related tables

The rule: when a value repeats across rows and describes something other than the row itself, it belongs in its own table. In the loan sheet, Item and Serial describe a piece of equipment. Borrower, Borrower email and Department describe a person. Only the dates and the return describe the loan itself. That gives three tables:

In Loans, Item and Borrower are references: each holds a link to one row in Items or People instead of a copy of its text. Fix Maria's email once in People and every loan shows the fix. Returned also changed shape, from yes/no to a Returned on date. The date says more (when it came back), and "still out" is simply an empty cell.

Step 3: Decide where the data lives

Before importing anything, decide which system is the source of truth from now on. There are three common answers:

For a sheet that runs a process, the second or third option is the point of the exercise. Emberblocks takes those routes. Data lives in its built-in database, your own Postgres or an Airtable base, and there is no live Google Sheets connector: you export the sheet as CSV and import it. If the sheet has to stay live because something else writes to it, a tool that reads Google Sheets directly fits better, and the Google Sheets to app page lays out that trade-off.

Step 4: Export the tabs and import them as CSV

Put each cleaned table on its own tab and export each tab as its own CSV file. In Excel, use File, Save As and pick CSV (Comma delimited); Excel saves only the active worksheet, so repeat it for every tab. In Google Sheets, open each tab in turn and use File, Download, Comma-separated values. A CSV holds values only, so a formula column arrives as plain results.

Import in dependency order: Items and People before Loans, so every loan has an item and a person to link to. Keep the key columns (Serial, Email) in the Loans file; they are how each loan finds its item and borrower. Then check the result before building anything:

• Row counts match the sheet, table by table.
• Dates arrived as dates and numbers as numbers. Codes with leading zeros or dashes (0098, CR6-0423) should be text, not numbers.
• Columns with a short list of repeated values (Department, Category) became single-select fields with the options you expect and no spelling variants.
• Every loan points at an existing item and person. A loan that links to nothing usually means a typo in the key.

In Emberblocks you import each CSV into a table in the built-in database, and column types are detected on import, so checking means confirming the guesses rather than setting every type by hand. Built-in tables take up to 60 columns each, with up to 50 tables per database; connect your data covers sources and field types. Table blocks can also let app users import new rows from a CSV later.

Step 5: Design screens around jobs, not tables

The most common mistake in a spreadsheet-to-app move is rebuilding the sheet: one grid per table and nothing else. Nobody wants three grids; they want to get a job done. List the jobs first, then give each one a screen:

Each screen replaces a filter or a habit from the sheet. The overdue list, for example, is a single filter: AND(ISBLANK([Returned on]), [Due date] < TODAY()).

Forms deserve the most care, because they are where bad data gets in. Make Item, Borrower and Due date required, let the borrower field search People instead of accepting free text, and show short option lists as buttons rather than a dropdown. The Emberblocks forms guide covers required fields, per-field hints, half-width fields and select options shown as buttons.

Step 6: Decide who can see and change what

In a shared sheet, everyone with edit access can change every cell, including other people's rows. An app lets you set rules per table and per row. For the loan app:

• Borrowers can create loans and read only their own. They cannot change due dates or delete anything.
• Front desk can create and update loans, and read all items and people.
• Equipment manager can do everything, including adding items and retiring old ones.

Write the rules down before configuring them. It takes ten minutes and catches most surprises. In Emberblocks, roles grant create, read, update and delete per table, and a row filter such as [Borrower].[Email] = USEREMAIL() limits a role to its own loans. The People table can also serve as the app's user list, with rules that assign roles from a column like Department; roles and permissions has the details.

Step 7: Roll out and retire the sheet

The sheet has to stop being an option, or people will keep using it out of habit and you will have two versions of the truth. A cut-over that works:

1. Pick a date. Run a final export and import the day before, so the app starts with the latest rows.
2. Make the sheet read-only. Change every editor to a viewer and put the app's link in a note at the top. Keep the file as an archive.
3. Link the app where people already look: the team chat, the intranet, the front-desk bookmarks.
4. Keep one owner. One person decides changes to fields, screens and rules; everyone else sends requests. A second person should know how it works.
5. Watch the first two weeks. Early questions point at screens that are missing or confusing. Fix those first.

Ship changes the way software teams do. In Emberblocks every publish is a versioned snapshot you can inspect and roll back, so fixing a screen after launch never puts the working version at risk.

Where Emberblocks fits, and where it does not

Emberblocks follows this process closely. You import each CSV into the built-in database (or connect Postgres or an Airtable base), link tables with reference fields, and build the screens as blocks on a grid: a lending form, a table of overdue loans, a calendar of due dates, a record page per item. Roles handle the borrower-only view, and a scheduled workflow can run once for every overdue loan and email the borrower. Ember can also draft the first tables and views from a plain-language description. The spreadsheet to app page lists what the app gains over the sheet.

It is the wrong tool in three cases. If other systems must keep writing to the sheet, you need a live Sheets connector, which Emberblocks does not have. If the sheet is really an analysis (pivot tables, charts, what-if models), keep it a sheet. And if one person uses it alone, an app adds little.

If you want a second pair of eyes on your own sheet before moving it, Google Sheets migration help is the place to ask.