Replacing the Shared Spreadsheet: Model the Data Before You Build the Screens

The spreadsheet three people are editing right now

The process runs, so it works. But you cannot answer questions about it, you cannot stop people overwriting each other, and you cannot let a client see their own row without a hand-made export. You are not getting an engineer this quarter.

So the question is what to build, what to refuse to build, and which decisions are expensive to reverse in eight months. The answer to the last one is almost never the interface.

The line: what belongs in a visual builder

The test is not complexity. It is who bears the consequences when the platform's constraints and your requirements diverge.

Good candidates: an internal CRUD tool over a process you already run by hand. An approval queue, where a decision is recorded with an actor and a timestamp. An intake form that routes work. A read-mostly client-facing status portal. A prototype meant to be thrown away once it has answered a question.

Bad candidates:

• Regulated data you cannot afford to put in a platform you do not control. You are adopting someone else's security posture, and you must be able to defend that in writing.
• Anything with a hard performance ceiling. High-volume real-time processing, heavy computation, large nightly batch jobs. These platforms optimize for build time.
• Anything that must run offline. If a network gap breaks the workflow, this is the wrong shape of tool.
• Your core differentiator. If the thing is why customers choose you, you have outsourced your most important asset to another company's roadmap and pricing decisions.

And be honest about lock-in: you generally cannot export a visual application as portable source code. Data exports; logic and screens stay in the platform's own representation. So when someone says "we can migrate later," translate it out loud — that is a rewrite, not a migration.

The data model is the decision that hurts later

Screens are cheap to change. The data model is not: every workflow, filter, permission rule, and report is written against it, and the tool will not tell you what you broke until a user finds it. The failures that happen:

• Modeling the spreadsheet instead of the business. A row is flat by necessity, with the customer, the owner, and the status as text in adjacent cells — a rendering constraint, not reality. Underneath are entities and relationships: a Request belongs to a Customer and is assigned to a Reviewer. If a sentence like that sounds odd said out loud, the model is wrong.
• Nesting a list of children inside the parent. Line items inside the order, comments inside the ticket. It works at ten and collapses at ten thousand, because paginating a list buried in a parent record is a different operation from querying a type with its own records. Unwinding it means rewriting every workflow that touched that list, on a live system.
• One overloaded type with a "kind" field. Two kinds of request share some fields and differ in the rest, so one type looks simpler than two. Then every form has conditional fields, every workflow opens with a branch, and fields that apply to one kind sit blank on the other, so "does not apply" and "someone skipped it" become indistinguishable.
• Using a display name as identity. Storing "Northwind Trading" as the link to a customer is fine until they rebrand or someone fixes a typo. Then every record pointing at the old string is orphaned, with no error — you find out when a report comes back short.
• Storing what you could compute. A total that sums its line items, a count of open requests. Each is a promise to update it everywhere the inputs change, including the bulk import someone runs next year. It drifts silently: nothing errors, the numbers stop agreeing.
• Not modeling time. A status field moves to In Review, then Approved, and the previous value is gone. In month three someone asks how long requests sit in review, and you cannot reconstruct history you never recorded. The fix is cheap up front: a transition record per change, with old value, new value, actor, and timestamp.

The rule: sketch the entities and relationships on paper before you build a single screen, marking each line one-to-many or many-to-many, and name them after the business rather than the interface — Request, Reviewer, Approval, never MainList.

Permissions are not an interface concern

The idea non-engineers most reliably get wrong: hiding an element in the interface is not security. Conditional visibility controls what is displayed, not what is reachable — if the data is reachable by the client, the record is retrievable whether or not a button was drawn on screen.

Access has to be enforced at the data layer, per record type, based on the logged-in user's relationship to the record — not "show this if the user is a manager," but "readable by its owner, its assigned reviewer, or a member of the owning team."

• Roles and per-record ownership, both. Roles alone give you the failure where any reviewer can open any request, including ones about their own compensation. Ownership alone leaves no way for an administrator to clean up a mess.
• The open default is yours to close. Treat "any logged-in user can read all records of this type" as a starting state you must dismantle deliberately, type by type.
• The audit question. Someone will ask who changed this and when. If the answer is a status field with no history, you have no answer — which is why the time-modeling and audit decisions are one decision.
• Offboarding. If ownership drives access and the owner leaves, does the work go invisible? Make reassignment a first-class action, and deactivate accounts rather than delete them.
• Compliance. If a data category carries a legal obligation, you must be able to explain these rules to an auditor. "We hid that page from non-managers" does not survive review.

Where the platform fits in the sequence

All of that happened before you opened a builder. Once the entities and access rules are sketched, the practical need is one place that gives you a database, an interface, and workflow logic together. That is the step where a platform like Bubble fits: a visual builder for web applications with a built-in database, workflow logic you configure rather than write, and privacy rules attached to data types, so access is enforced where the data lives rather than where it is displayed.

The limits are real: a performance ceiling you do not control, an application that is not portable source code, and a vendor's roadmap as a dependency. For an internal approval queue those are cheap trades. For the system customers pay you for, they are not.

Signals it is time to move to code

• Performance degrades under real data volume, not demo data: lists that were instant in testing take seconds against a year of production records.
• You keep bolting on external services to express one workflow, until the platform is only the user interface and the real logic lives elsewhere.
• A required integration has no path at all, such as an authentication scheme the platform cannot perform.
• More than one person depends on it, so you need real version control, code review, and automated tests before a Friday change breaks someone's Monday.
• Operating cost or a platform constraint has become a business risk — a vendor decision could disrupt operations and you hold no lever.
• It became the product you sell, which moves it onto the bad-candidate list.

The clean model is the escape hatch. In a rebuild the expensive part is rarely the screens; it is untangling data. If entities are clean, relationships are real references, children are their own types, and history exists as events, the export maps onto a real schema. If the model is a transcribed spreadsheet, the first month is archaeology.

And the honest opposite: most internal tools should never move to code. If your approval queue serves forty people and has not changed shape in a year, rebuilding it in a real framework buys nothing but a maintenance burden. Either way the work starts on paper, with the nouns of your process.