Key takeaways
- A spreadsheet becomes an app in three moves: rows become records with ids, the things you do with it become screens, and one server function owns every write.
- Four or more of the eight signs below means the sheet is done; the most common are a second editor, a phone in the field, and re-typing rows into another system.
- The failure that only appears after you leave the sheet is two taps saving over each other. My fix took three review rounds and comes down to one compare-and-write rule.
- My snow route app kept eight of the sheet's fields and dropped the notes column, the running total and the group text.
- My bookkeeping app imported 1,229 rows, reconciled 69 of 69 statement sections, and found a five-figure transfer the sheet had called income.
- A three-to-four-screen internal app gets a set build price quoted up front and a monthly plan for just the services it uses. The size of the import, the number of people tapping it and the alerts are what move the build price.
How to turn a spreadsheet into an app in three moves
The method is the same whether the sheet tracks snow clients, rental units or jobs in progress.
- Rows become records. Each row gets a permanent id that survives sorting, each tab becomes a table (or, for a small app, one document with a list per tab), and a column holding two things ("owes $50, gate code on the fence") splits in two.
- Habits become screens. Not the tabs you have, the things you do: scan for who is next, open one row, change a status, add a new one. That is a list, a detail page and a form, and most small businesses need no more than four screens.
- One function owns every write. Phones never touch the data directly. They ask a small server function, which reads the current record, checks nobody changed it since, and saves. Sheet-to-app tools skip this step, and it is why a shared sheet corrupts itself.
Add a public form that writes into the same records and a push to one phone, and you have what I run: one HTML file, two small functions (one for my taps, one for the public form), one record store, on my home screen since September. If the sheet belongs to one person and never leaves a desk, tidy the sheet instead; the eight signs below tell you which you are.
The eight signs your business has outgrown spreadsheets
I kept my own sheets well past the point where they cost me money. Four or more of these and the sheet is done.
- More than one person edits it. Or one person edits it and everyone else texts them changes, so the chat becomes the real system. That was my snow route.
- You use it on a phone in the field. Pinch-zooming a dozen columns in a skid steer at five in the morning edits rows by accident.
- You re-type it somewhere else. Invoices, a text to the customer, the calendar. Every re-type is a place the copies drift apart.
- A formula nobody dares touch. If one cell holds the business together and you wrote it three years ago, it is a liability.
- It has already cost you. A wrong cell sent someone to the wrong address or missed an invoice. One costly error is the sheet telling you it is time.
- You need status at a glance. Who is done, who owes, what is next. Color-coding is a status column pretending to be a feature.
- It should remind you and cannot. No sheet buzzes your phone when a sign-up arrives or a payment is 30 days late.
- It grows by more than 50 rows a month. Above that you need search, filters and an archive, and the sheet crawls on a phone.
Tick your boxes below. Zero to three: make the sheet better. Four to seven: it is time, and the question is rent or build. Eight: build.
Spreadsheet vs database vs app, in plain English
Owners hear "you need a database" and picture a server room. Here is the difference in practice.
A spreadsheet keeps the data, the math and the display in the same cells. That is its genius for one person and its flaw for two: anyone can type over a formula, sorting one column scrambles the rows, and nothing stops two people saving different versions of row 40.
A database is only the data, with rules: every record has an id, every field has a type (a date is a date, not "next Tues"), and a write that breaks the rules is refused. It has no face.
An app is the face plus the rules: screens for the things you actually do, and a single path every change takes. The database can be tiny. My snow app's is one JSON document; Fischer Books, the bookkeeping app I built the same month, uses SQLite, a single file on my Mac.
Before: a sheet and a group text. After: four tabs on my phone
Last winter the snow side of Revisions Unlimited ran on a sheet grouped by road and a text thread. The sheet had names, addresses, prices and a notes column that held everything else. The thread had the truth: who was done and who had paid.
In September I replaced both with an app at an unlisted address on my own website. Four tabs:
- Storm day: every on-route client in fastest road order, one stop at a time with Navigate, On my way, Done and Skip, and a finish-by time checked against the 12 hours I promise.
- Clients: grouped by road like the sheet, each with a status, a plan, price, paid, owed and a visit count against my 12-visit cap.
- Quote: for pricing a driveway on the spot.
- Flyers: the run I do each fall, plus a tracker for the 80 local businesses on my October outreach list.
What it kept: name, address, road, phone, plan, price, paid and owed, eight fields almost unchanged; the grouped-by-road view; and the sheet itself as an export.
What it dropped:
- The notes column (gate codes, "owes $50," "call after 6" in one cell); each item is now a field or a status.
- The "last plowed" column; a Done stamp per storm replaced it, and the visit count falls out for free.
- The running-total formula, which became two tiles, Contracts signed and Each storm, because the single total had let me feel good about a winter I had not sold.
- The text thread, replaced by a public sign-up form that writes a prospect into the same records and pushes to my phone, tagged with its source.
The route math, the geocoding trap that put a driveway 90 miles away and the GPS rules are in the snow app post; those are plowing problems.
The second sheet: a budget spreadsheet that became a bookkeeping app
The same month I replaced a very different sheet. For about a year and a half my money lived in a spreadsheet fed by a script that scraped my credit union's PDF statements into a 967-row export. One row showed a lunch at Culver's for $18,818.10, a running balance the script had grabbed instead of the amount, and the sheet totaled it like any other expense.
143 rows sat in "Other" because categorizing by hand is the task I skipped every Sunday, and nothing told me whether a month actually reconciled.
The after is Fischer Books, a desktop app with three books in one SQLite file: Revisions Unlimited, Style Marking and personal. It imports the statements, reconciles every section against the printed opening and closing balances, categorizes with rules first and an AI suggestion only for what the rules miss, and prints my CPA package.
The migration brought over 1,229 transactions, 69 of 69 statement sections reconciled to the penny, with 500 automated tests behind the import. It kept the categories, the 494 payee aliases from the old sheets and the CSV export; it dropped every formula, because math in code with tests is the whole difference between a formula nobody dares touch and one that proves itself every run.
And it caught what the sheet hid. When a savings section opened at $0.00, the old script dropped the zero and shifted every amount by one row; in March 2025 that turned a five-figure transfer into the same amount of dividend income, and the old "reconciliation" hunted for any number that made the arithmetic close, then reported success.
A check that searches for a value that makes the math work is not a check. The app now fails loudly when opening plus activity does not equal closing. The long version is in the bookkeeping post.
Two taps, one record: the bug that only shows up after you leave the sheet
In a spreadsheet, two people editing the same row is visible: two cursors, or two files named "final." In an app it is silent.
The snow app stores everything in one document. Tap Done and the phone reads the document, marks that stop, and writes it back. Now picture my phone and a browser tab doing that in the same second. Each read the same original, each wrote its own version, and the last write wins. One Done quietly disappears, and in February that is a driveway I think I plowed and did not.
It took three review rounds to get the rule right:
- Read the record with its version tag (an ETag) and write back only if the tag still matches. If someone wrote in between, the function re-reads and retries up to eight times, then tells the phone it failed instead of pretending.
- Treat "success" with suspicion. My storage library reported a refused write as successful, with an empty version tag. A write now counts only when a new tag comes back. That was round two.
- Read your own writes. The default storage mode was "eventually consistent," so a Done tapped three seconds ago could be missing on the next read. Switching to the always-latest mode was round three.
- No slow work between read and write, ids assigned first, taps queued offline. A map lookup mid-write widened the collision window; a pre-assigned id stops a retry making a duplicate; offline Done taps replay in order when the signal returns.
Rented sheet-to-app tools leave the Google Sheet as the database underneath and inherit this exact failure. If two people will ever tap the same row within a minute, ask whoever builds your app how they handle it. A blank look is your answer.
What drives the cost, when to rent a tool or build, and moving the data without losing a row
Tidy the sheet when one person owns it and nothing downstream depends on it. Rent a tool (Glide, AppSheet, Airtable, or a trade product like Jobber) when a template matches your workflow nine times in ten and paying per user every month is fine. Build small when the workflow is the business: columns no template has, two or more people touching it, or a phone that needs to buzz.
What drives the cost
Most of the "you have outgrown spreadsheets" articles I have read end at a quote around $40,000. The $15,000 to $100,000 quotes I have seen from dev shops are not dishonest; they are for a different problem: multi-company logins, roles, audit trails, an admin console, a native app in two stores. A one-person shop needs none of it.
When we build one, a three-to-four-screen internal app like the snow route, with a public form and a push to one phone, is a small build. Something like Fischer Books is a much bigger build, because the parser, the reconciliation and the 500 tests are where the weeks go, not the screens. Either way the build price is set and quoted up front before work starts, then a monthly plan covers just the services the app uses, such as hosting, the alerts, support and updates, priced to compete with the per-user tools above; ask for a free quote.
Migrating without losing a row
- Freeze the sheet. Duplicate it, date the copy, stop editing the original. Two live copies for a week is how rows vanish.
- Export to CSV and count rows and the sum of every money column.
- Split the junk-drawer columns and give every row an id in the sheet, where you can see them, so an import run twice updates instead of duplicates.
- Import, reconcile, run both for one cycle: same count, same totals, ten rows spot-checked, and one storm or one month of books on both before the sheet is deleted.
To start this week: take the quiz above, write down the three things you actually do with the sheet, and split the notes column. If you want the app instead, tell me what the tabs are and who touches them through the contact page and we will come back with a set build price and the services the monthly plan would cover. Our development team works remotely with owners anywhere, and in Minnesota the team can visit in person.
Frequently asked questions
Count the signs: a second editor, a phone in the field, re-typing rows elsewhere, a formula that scares you, a costly error already, status you cannot see at a glance, alerts it cannot send, or more than 50 new rows a month. Four or more and you have outgrown it; one or two means a better-built sheet is still the answer.
Yes, two ways. Glide or AppSheet put a phone face on the sheet in an afternoon and leave the sheet as the database, which suits one editor and a simple list. A small custom app moves the rows into a record store with a single write path, which you need once two people tap the same row or a public form feeds it.
It depends on what the app has to do. A three-to-four-screen internal app with a shared record store, a public form and a push to one phone is a small build; one with a heavy import or reconciliation engine is much bigger. Either way you get a set build price quoted up front, then a monthly plan for just the services it uses, priced to compete with per-user tools like Airtable or Jobber. The big dev-shop quotes you may have seen are for multi-user platforms a small shop does not need.
Silent overwrites when two people edit, formulas that break when a row is inserted or a column sorted, numbers that look right and are not (my sheet carried an $18,818 lunch for months), no alerts, and no record of who changed what. None show up as an error; they show up as a wrong invoice, a missed stop or a tax number you cannot defend.
If one person tracks a few dozen contacts and nothing needs to alert you, a disciplined spreadsheet works. Once leads arrive from a website form or more than one person follows up, you need a single write path: a rented CRM when its template matches how you sell, a small custom list app when your pipeline has steps no template has.
A spreadsheet keeps the data, the math and the display in the same cells, so anyone can type over a formula and sorting one column can scramble the rows. A database holds only the data, with rules: every record has an id, every field has a type, and a write that breaks the rules is refused. An app is the screens and the single write path on top.
Have a sheet that has become the business?
Tell me what the tabs are, who touches them and where it goes wrong. You'll get a clear scope with a set build price for the small app that replaces it, quoted up front, then a monthly plan for just the services it uses, priced to compete with the per-user tools. Our development team builds it around how your business works, and you talk directly with the people building it.
Founder, Style Marking · owner, Revisions Unlimited. Jacob builds custom websites, apps and operations systems for small-business owners — and runs a remodeling company on the same tools he builds for clients. Every post here comes from systems he has actually shipped.