When a spreadsheet has stopped being enough
Most teams do not outgrow a spreadsheet; they stop noticing the cost of keeping it. It starts as a good tool, because it is. It is flexible, everyone already knows it, and nothing has to be approved. The trouble is that a shared sheet quietly turns into a system of record, and it was never built to be one.
This is a checklist for deciding whether that has happened to you. We sell a product that replaces some of these jobs, so we have tried to be specific about which ones, and about the ones it does not touch.
Five signs
1. There is more than one current version. Someone downloads the file "just to work on it", someone else has a copy on their desktop, and the real numbers are whichever file was saved last. If a meeting opens with "which one is the latest", this is you.
2. Nobody can say who changed a figure, or put it back. A quantity is wrong, and the sheet cannot tell you when it changed or who changed it. A file-level version list, where there is one, answers a different question from "what happened to this one line".
3. Access is all or nothing. The person who needs to see order status also sees salaries or margins, because separating them would mean a second file, and a second file brings back the first problem.
4. Reminders are a person. Someone looks at a date column every morning and nudges whoever is late. When they are on holiday, nothing happens.
5. The same fact is typed in several places. A customer's name lives on three tabs, and a supplier's lead time is copied into every order. The copies drift, and then you have two answers to one question.
If you recognised two of these, the sheet is already costing you more than it appears to. If you recognised all five, the question is not whether to change but how carefully.
What a database app addresses
We will go through them in order, with what the repository supports.
For the first, records live in one database that everyone works in, rather than in files that travel. A save checks that the row has not changed since you loaded it and refuses to silently overwrite a colleague's work, according to docs/security.md. People who only need to look can be given a read-only share link instead of a copy.
For the second, every insert, update, soft delete and restore writes an immutable change entry with the actor and a before and after snapshot, written by a database trigger rather than by application code that could be skipped. Deletes are soft by default, with a trash and a restore. There is a record history panel that can revert one change or restore a record to how it stood at a chosen point.
For the third, there are roles (the app describes them as Admins, Builders, Editors and Read-only) and per-table permission levels of none, view, edit own and edit all, enforced in the database and not just hidden in the screen.
For the fourth, automations can start on a schedule as well as on a record change, and can send a notification or an email. Every run is logged.
For the fifth, a table can link to another, and a lookup or rollup then reads the value from the linked record, so the lead time is typed once. This is how the starter templates are built.
What it does not address
Honesty matters more here than in the section above.
Several of those fixes have conditions. Field-level and view-level permissions are switched on from the Business plan upward and are off on Free and Pro, according to src/billing/plans.js. Revision retention differs by plan, and the product contract says record history retention needs explicit operator settings. The history panel states plainly that nothing before the earliest recorded change can be restored. A restore also cannot remove a field that was added later; it can only empty it. Email reminders depend on the deployment's mail setup. Automation runs are budgeted per month, and a run over the budget is refused rather than queued.
Some things are outside the product on purpose. docs/non-goals.md says Appdor will not be a business-intelligence modelling tool. Dashboard widgets each aggregate one table. If your reporting means joining several sources and modelling them, you export to the tool you already use for that.
A database also cannot rescue a process nobody agrees on. If two people disagree on what "shipped" means, a status column will record the disagreement faithfully. And a table is not a free-form grid: the freedom to put anything in any cell, which made the spreadsheet easy, is exactly what you give up to get checks, links and history.
Finally, exports are available on every tier, so a determined colleague can still download a copy and start the first problem again. A tool can make the shared version the easy one; it cannot make the habit disappear.
How to decide
Do not move everything. Pick the one sheet where wrong data costs you most, usually something with deadlines or stock or money, and rebuild only that. Start from a ready-made template if there is one near your process, or use the import door for the data you already have. Keep the old sheet read-only for a month as a safety net, and see whether people stop opening it.
If that one sheet works, the next one will be easier to judge. If it does not, you have lost a few days, not a quarter. You can try a starting template at Appdor.