An Excel to web app move is mostly deciding what a row really is.
Most people looking for an Excel to web app path do not want a prettier grid. They want the file to stop being three tools at once: the place the data lives, the form people type into, and the report somebody reads on Monday. One surface does all three, which is why it works for one person and falls apart at five. The same split shows up in barcode scanner to Excel apps, where the scan is easy and the row it writes is the hard part.
This page covers how to read your own sheet before you build anything, which columns survive and which were never data, what breaks when a second person starts editing, and how to move the rows without losing the history.
Sort your columns firstThe short version
The grid hides the model, and the model is the whole job.
A sheet lets you put anything anywhere. That is its best feature and the reason converting one is harder than it looks. Nothing in the file says which column is the key, which values are typed in and which are calculated, or which rows must never be deleted. All of that lives in the head of whoever maintains it.
So the work is not screen design. It is writing down the rules the spreadsheet has been enforcing socially, then letting software enforce them instead. Skip that step and you ship a worse spreadsheet with a login page on the front.
Your sheet is doing three jobs at once
Open any working spreadsheet and you can see the three jobs stacked on one surface. The left-hand columns are the record. The next few are formulas derived from the record. Somewhere to the right, or on another tab, is a summary somebody prints. A grid lets all three share a space. An app cannot, and that turns out to be the point.
Splitting them is the first real decision. The record becomes a table with typed fields and a key that identifies a row. The derived columns become code that runs when the record is read, so nobody can paste over a calculation. The summary becomes a screen holding no data of its own, so it can be wrong without breaking anything.
This is also where you find out how much of the sheet was never data. A cell reading 12 boxes at 4 each is a note, not a number. A column blank for the last eleven rows is a rule nobody wrote down. An inventory tracking app generated straight from that file inherits every ambiguity and makes it permanent.
The column audit that decides the build
Before any of this becomes screens, go through the sheet one column at a time and label each one. Four labels cover almost everything: identity, typed by a person, derived from other columns, and left over from something that ended two years ago. The last group is always bigger than anyone expects, and deleting it is the cheapest work in the project.
Two traps hide among the typed columns. The first is a column holding two facts at once, such as a site name with its region glued on, which has to become two fields before anyone can filter on either. The second is a date stored as text because somebody pasted it in. It imports as a string and sorts alphabetically forever unless you catch it.
Size is almost never the reason people move. A worksheet holds 1,048,576 rows by 16,384 columns, and one cell takes up to 32,767 characters, so the grid keeps accepting data long after the process around it has stopped working. The limit teams actually hit is human: nobody can say which of the four copies is the current one.
Microsoft, Excel specifications and limits
Try it
What your sheet is already telling you
Tick what is true of the file you have in mind. Each one is a requirement you would otherwise find out about halfway through the build.
0 of 5 apply
Nothing ticked. A sheet one person owns, with no derived columns and no argument behind it, is usually fine left where it is.
What breaks when the second person arrives
One person and a spreadsheet is a fine system. Trouble starts at two, and it is not about editing at the same time, which the cloud versions handle well. It is that a grid cannot express who may see what. You can hide a column. You cannot stop somebody who has the file from unhiding it, or give one person four columns out of twenty.
The second break is history. A cell that changes leaves no trace of who changed it or why, unless somebody opens version history and works out which of four hundred edits mattered. Most teams discover this during an argument about a number, which is the worst moment to find out. An internal business app usually gets built the week after.
The middle path, keeping the sheet as the store and putting a form in front of it, is real but it has a ceiling. The Google Sheets API allows 300 read requests and 300 write requests per minute per project, and 60 of each per minute per user, with no cap on the daily total as long as you stay inside those. That is plenty for a team filling in a form and not enough for a screen that refetches a list on every scroll, so cache on the device and write in batches.
Getting the rows across without losing the history
Export to CSV rather than XLSX if you get the choice. CSV forces every formula to resolve to a value, and it makes the encoding and the delimiter visible instead of silent. Open the file in a plain text editor once before importing. Commas inside free text, a stray quote mark, and dates written 03/04/2025 with no stated order are all cheaper to find now than later.
Expect to import twice. The first pass tells you which rows fail, and the failures are the real specification: blank keys, two customers with the same name, a quantity typed as approx 40. Fix those in the sheet rather than in the importer, because whoever maintains it needs to see what was wrong. Then load again and keep the original export. It is your only audit trail for the day of the move.
One thing to be plain about: an AI app builder will not generally turn a workbook into a running app on the first run, and that includes ours. You can attach files to a Newly chat, up to 10 MB each, and the agent can open and read them while it works. The docs pin down which image formats it accepts. They do not describe a spreadsheet import, and we did not confirm that a CSV or XLSX loads itself into a new build, so do not plan around one. The realistic path is to describe the fields, let the tables get created, then load the rows once. Settle this first: where the rows live once they leave the sheet.
What each option gives you once the sheet outgrows one person
| Option | Works offline | Permissions per person | Who changed what | Data stays yours |
|---|---|---|---|---|
| Shared cloud spreadsheet | partial | No | version history only | Yes |
| Spreadsheet plus a web form | No | on the form only | per submission | Yes |
| No-code sheet to app tool | varies | Yes | Yes | held in the tool |
| Off-the-shelf industry software | Yes | Yes | Yes | export only |
| An app you build | Yes | Yes | Yes | Yes |
Building the app around your own sheet
The reason teams end up building is almost never a missing feature. It is that the sheet encodes a rule no product has: a discount for exactly two customers, a step everybody skips in August, a status that means something different on the warehouse tab. Off-the-shelf tools are built around the common case, and your spreadsheet is a record of every exception since the day it was created.
Cost is the other half. Per-seat pricing punishes the exact shape of team that lives in spreadsheets, where twenty people touch the file and three are heavy users. Price a tool at twenty seats, set that against a build you own, and the build stops looking exotic.
Newly is an AI app builder: you describe the app in plain English and it writes a real React Native and Expo project you own, runs it on a cloud simulator while it builds, and ships iOS through TestFlight with your own Apple Developer account, or Android to Google Play internal testing plus a standalone release APK you can install on a phone directly. It builds mobile apps rather than a browser page, which matters if the people typing will be at a desk. Plans are $25 a month, there is no free plan, and you can pull the code out with the CLI whenever you want it.
Questions people ask about turning a spreadsheet into an app
Not in one step, for any sheet with rules in it. Tools can read a grid and put a form in front of it, which works well for a flat list. What no converter can do is tell you which column identifies a row, which values are derived, and which blank cells mean not applicable rather than not filled in yet. That is a decision, not a conversion.
Write down the rules your sheet has been enforcing
Take one tab, label every column as identity, typed, derived or dead, and describe the app from that list rather than from the grid.
Start building