Turn a Spreadsheet Into an App With AI

To turn a spreadsheet into an app, start by reading the spreadsheet rather than describing the app. Every working sheet already contains the design: the columns are your fields, the repeated blocks are your tables, the formulas are your business logic, and the tab you copy every month is your record boundary. Handing an AI builder "build me a booking app" throws all of that away and asks it to guess. Handing it the actual structure gets you something that matches how you already work.

This walks through the translation, using a booking sheet as the worked example. The method transfers to inventory, quotes, client trackers and most of the other sheets that have quietly become someone's operations system.

The example sheet

A single tab, one row per booking, filled in by hand since 2023:

Below the data, a few summary formulas: total by month, count of unpaid deposits, a conditional format that turns a row red when the date has passed and status is still Pending.

That is a complete specification. Here is how to read it.

Step 1: separate the entities

The most important structural move, and the one an AI builder will not make for you.

A spreadsheet flattens everything into one grid. An application needs to know that Client, Phone and Notes about parking all describe the *same client* across many bookings, while Date, Duration and Status describe *one booking*. In the sheet, "R. Okafor" is retyped every time and the phone number is retyped with it. In an app, the client is stored once and referenced.

The test for splitting a column out: does this value repeat identically across rows, and would changing it mean editing every row? If yes, it belongs to a separate entity.

For the booking sheet:

• Clients: name, phone, notes. One row per client.

• Services: name, default duration, default price. One row per service offered.

• Bookings: date, client reference, service reference, duration, price, deposit paid, status.

Duration and price stay on the booking as well as the service, because the sheet shows they get overridden. That is real information, and it would have been lost by a from-scratch description.

Step 2: turn formulas into logic, and decide where it lives

Every formula is a rule. Each one becomes one of three things, and getting the category right is what stops you rebuilding the spreadsheet's weaknesses.

Note that almost everything is computed on read rather than stored. This is the single biggest quality difference between a spreadsheet and an application, and it is worth being explicit with the model about it. Storing a monthly total is how spreadsheets end up with figures that disagree, because the stored number and the underlying rows drift apart. Calculating it when someone asks means it cannot be wrong.

The exception is the price lookup. That is a *default at creation time*, and it must be stored on the booking, because if you raise your prices next year the historical bookings should not silently change. Anywhere your sheet has a value that was correct when entered and should stay that way, say so explicitly, because the default assumption will go the other way.

Step 3: work out who sees what

The sheet has one implicit answer: whoever has the file sees everything. An app needs a real one, and this is the part people skip.

Write it as a short table before you build:

If only you will ever use it, say that plainly, and build a single-user app. That is a legitimate answer and it saves a lot of work. What causes trouble is leaving it unstated, because a builder will produce something with the shape of multi-user access and none of the enforcement, which looks fine until it is not. This is one of the failure classes covered in the limitations of AI app builders: a permissions bug has no visible symptom.

Once you have decided, how to add user accounts to an AI-built app covers the implementation.

Step 4: write the brief

Now you have something worth handing over. The structure below works because it gives the model the decisions rather than asking it to invent them.

Build a booking management app.

DATA
Clients: name, phone, notes
Services: name, default_duration_minutes, default_price
Bookings: date, time, client (ref), service (ref), duration_minutes,
          price, deposit_paid (bool), status (pending|confirmed|
          completed|cancelled), notes

RULES
- Creating a booking copies duration and price from the service as
  defaults; both stay editable and are stored on the booking.
- A booking whose date has passed while status is 'pending' is shown
  as overdue. Do not store this, compute it.
- Monthly revenue is the sum of price for completed bookings in that
  month, computed on read.

VIEWS
- This week's bookings, grouped by day
- Unpaid deposits, oldest first
- One client, with all their bookings

ACCESS
Single user for now, one login.

Roughly two hundred words, and it contains every decision from the three steps above. Compare that with "build me a booking app for my cleaning business" and the difference in what comes back is not subtle. If you want to go further on writing these, how to write prompts for AI app builders covers the general form, and how long a prompt should be explains why two hundred words is about right.

Step 5: migrate the data last

Build the app, use it with five hand-entered records, confirm the rules behave. Only then import the history.

The reason to wait is that importing early hides structural problems. A sheet with three years of data has inconsistencies in it, guaranteed: the client typed three different ways, the month someone used a different status word, the row where duration is "3h" and another where it is "180". If you import first, you spend your time fixing data and never notice that the model got the overdue rule backwards.

When you do import, expect to clean. The most common issues, in the order they usually appear:

1. Name variants that need collapsing to one client record. "Bell Ltd", "Bell Limited", "bell ltd".

2. Mixed formats in the same column. Dates as text and as dates, durations as hours and as minutes.

3. Meaning encoded in formatting. The yellow rows nobody could explain, which turn out to mean "cash job". Colour is data in a spreadsheet and disappears entirely on export. Find these before you import, because they are invisible afterwards.

4. Blank rows used as separators, which become empty records.

The colour one catches almost everyone. Scan the sheet for formatting that carries meaning and add a column for it before exporting anything.

What you get, and what you have signed up for

The gains are real: no more accidental overwrite, a phone-usable view, permissions if you need them, and figures that cannot disagree with each other because they are calculated rather than stored.

The cost is that you now own an application. It needs somewhere to run and it needs backups, both of which are covered in how to deploy an app built with AI. A spreadsheet in a shared drive has neither problem, which is genuinely a point in its favour.

The honest threshold: make the move when more than one person needs to use it at once, when you need to control who sees what, or when the sheet has grown a set of formulas that only one person understands. If none of those is true, the sheet is doing its job and there is no prize for replacing it. The related path of building an internal tool with AI covers the broader case.

FAQ

Can AI turn my Excel file into an app?

It can build an application from the structure your file already has, but it will not extract that structure reliably on its own. Doing the entity split and the formula translation yourself is what separates a good result from a generic one.

Should I import my spreadsheet data first or last?

Last. Build and test the rules with a handful of records, then import. Importing first means you spend your attention cleaning data instead of checking that the logic is right.

What is the most common mistake?

Keeping the spreadsheet's flat shape. One table with everything in it works in a grid and causes duplication problems in an app. Splitting out the entities that repeat is the step that matters most.

Do I still need the spreadsheet afterwards?

Keep it read-only for a month as a reference while you confirm the numbers match. After that, archive it. Running both in parallel indefinitely is how the two versions start to disagree.

What if my sheet uses colours to mean something?

Add an explicit column for it before you export. Formatting is not included in a CSV export, so anything encoded in colour is lost silently and is very hard to reconstruct later.

Once an app like this is running, the ongoing bill becomes the next question. how much it costs to run an AI-built app breaks down what actually shows up on the monthly invoice.