The spreadsheet worked until it didn't.
Our mum's rental operation ran on Excel files she understood better than anyone else could. Ten-plus BEMER devices, medical wellness equipment she rented to clients across Hungary. Who had what, when it was due back, whether they'd paid, all of it spread across spreadsheets that made sense to her and were invisible to anyone else trying to help. Files multiplied across versions until she lost track of which entry was current.
The question we get asked, from founders running similar operations, is always some version of: did you try Airtable first? Did you look at Notion? Could this have been solved without writing a line of code?
Yes, we looked. Looking made the ceiling visible.
The Problem Spreadsheets Could Not Solve
The breaking point was not a row limit. It was not a formula that became too complex to maintain. The breaking point was a data structure.
Mum's operation required tracking four entities at once: devices, clients, rental contracts, and payment status. Those four entities were not independent. A device query had to resolve its current client. A client record had to surface every active contract. A contract had to trigger a reminder when it was approaching the return date. Payment status had to roll up into a month end view that answered, cleanly, who owed what and for how long.
In a spreadsheet, you model that with columns. One sheet per entity, cross referenced manually. At the end of each month, she pulled both sheets, ran a reconciliation, and hoped the entries agreed. They often did not.
That workflow was not a spreadsheet problem. It was a relational data problem. And relational data problems do not have spreadsheet solutions.
The No Code Alternatives We Considered
We looked at Airtable first because it models tables relationally and the interface is familiar. You can create a Devices table, a Clients table, and a Rentals table, link records between them, and run views across the links. For a small operation it works.
The ceiling appears when you add state transitions and time based triggers. Airtable supports automations. Airtable does not support conditional logic that spans multiple linked entities and fires when a date field on one record changes the status on another. A contract approaching its return date needs to surface a reminder in the app, attached to the correct client record, visible to the distributor who manages that device. Airtable automations can send an email. They cannot update a state machine across three entities and surface the result in a dashboard view that a distributor logs in to check daily.
Notion was out before we looked hard. Notion databases are softer than Airtable's. Relations are looser. Automation support is thinner. A rental management CRM is not a knowledge base.
The category as a whole, Airtable, Notion, similar tools, falls short at the same point: the moment a workflow requires conditional logic across multiple linked entities with persistent state that a user monitors over time, no code platforms require workarounds. Workarounds are manual steps that reintroduce the exact fragility you were trying to remove.
The no-code ceiling hits when a workflow requires conditional logic, cross-entity state, or a custom data model, and every workaround costs more in maintenance than a custom build.
The Decision to Build Custom
Options considered: Airtable with Zapier automations for the reminders layer. Notion with a third party automation tool. A Glide app on top of a Google Sheet. A custom web application.
Chosen: Custom web application.
Rationale: Every no code path required a workaround at the same point. The reminder layer. Device status transitions on return. Month end rollup views with contract state. Each workaround added a manual step or an external automation that could break independently. A custom build meant owning the data model end to end, which meant every feature we built would compose with every other feature without a seam.
Tradeoff: We paid with engineering time. A Streamlit prototype took six weeks. The React production build took five months part-time. A founder with no dev background cannot do this alone, or cheaply. The tradeoff is real. For Mum's operation specifically, it was the right call: the tool she is running today handles more volume, with more accuracy, in less time, than any no code path would have delivered.
What We Built
VitalRegistry is a React CRM on Firebase. The data model has four top level collections: clients, devices, rentals, and contracts. Rentals hold the relationship between a client and a device for a specific time window. Contracts are sub collections on rentals, generated automatically from the rental terms and uploaded back into the system as proof.
The feature set that no code couldn't replicate:
In-app reminders. The system checks contract return dates daily. Three days before a due return, it surfaces a reminder attached to the client record. No email automation. No Zapier webhook. The distributor logs in, sees what needs attention, and acts from within the same tool they use to manage everything else.
Contract generation. Rental terms produce a PDF contract. The contract uploads into the system. The rental record closes when the device comes back and the contract is confirmed.
Google Calendar sync. Rental events push to the distributor's calendar. One way, no sync conflicts. The meetings show up where the distributor's day already lives.
Month end close view. A single screen shows every active rental, overdue contract, and outstanding payment. The distributor does not cross reference two spreadsheets. They look at one screen.
The Firebase decision followed our standard evaluation format. Firestore for data, Firebase Auth for login, Firebase Hosting for the frontend. The rationale: generous free tier for the scale we were at, Google backed infrastructure, and Auth plus Firestore ship with most of what a CRM needs out of the box. Tradeoff: locked into Google's data model and pricing curve. If usage scales hard, the migration off Firestore is the bill we pay later.
The Result
Month-end reconciliation that used to eat a full day now runs in minutes. That is the metric every debate about founders outgrowing their platforms boils down to: hours saved per week, multiplied by the number of weeks left in your career.
Mum saves tens of hours a month. A handful of distributors with ten to thirty devices each are now running on the platform. Real usage found the holes in the data model. We fixed them. The tool that exists today is not the one we shipped first. It is the one that survived contact with actual operators.
The no code path would have delivered something faster in the first week. By month three it would have been a set of Airtable automations that occasionally misfired, a Zapier webhook that nobody trusted, and a spreadsheet she was maintaining on the side just in case.
The Principle
Custom software is what no code is pointing toward. Every no code ceiling exists because the workflow requires something the platform was not designed to express. At that point you are no longer using a tool. You are working around one.
The question is whether the friction from your current platform costs more, in time and trust, than a custom build. For most founders, the answer is obvious and arrives about six months later than it should have.
Is there a workflow in your operation that runs on manual cross-referencing because the tool you picked cannot hold the logic together?
VitalRegistry is open source. Optional donations supported. If you are a BEMER distributor or running a similar rental operation, the code is available.