When a spreadsheet stops being enough: an internal CRM on WeWeb and Xano
A spreadsheet does not break on the number of rows. It breaks on the number of hands. Here is what a real backend buys you instead of a shared file, with a demo you can log into.
When is it time to move off spreadsheets to a real CRM?
When several people work on the data at once, when you need a history of changes, and when some fields cannot be shown to everyone. A spreadsheet breaks on simultaneity rather than volume: two people edit one row and whoever saved last wins, silently. A real backend makes a stage change one server-side operation that writes the history along with it.
A spreadsheet is an honest first tool. It is free, everybody understands it, and up to a point it genuinely works.
It does not break where people expect. Not on the number of rows, but on the number of hands.
What actually breaks
Two people open the same deal. One moves the stage to “Negotiating”; at the same moment the other types in the amount. Both save. One of those changes is gone, and nobody is told: a spreadsheet does not argue, it records the last thing it was given.
Then it turns out nobody can say who moved a deal, or when. There is a history, but it covers the whole file, and finding one particular change in it is a job of its own.
And third: showing a salesperson their own deals but not everyone’s figures is not something a spreadsheet does. You can hide a column, but that is a polite request rather than an access rule.
What a real backend changes
I built an internal CRM on WeWeb and Xano: the interface on one side, the data and the logic on the other. The demo is open and you can log into it and move deals around.
The difference is not a prettier interface. It is that changing a deal’s stage is not editing a cell, it is one operation on the server. Inside it the stage changes and the move is written to that deal’s history. The two happen together or not at all.
Everything else follows from that. The history appears by itself, because the same operation writes it rather than a person who remembered. The races disappear, because the server decides the order. Permissions become real: the endpoints are closed, and the interface cannot show what the server will not hand over.
Why this pair of tools
Xano takes the data, the authentication and the business logic. WeWeb is the interface that calls it over an API. Neither involves a hand-written server, and yet this is not a spreadsheet with buttons on it: closed endpoints, real authentication, a request log.
For a small team that lands in the middle: more than a spreadsheet, markedly less than bespoke development, and built in days rather than months. The demo linked above was put together in two days.
When not to move
If one person works on the data, the spreadsheet is better. Genuinely. It is more flexible, there is nothing to deploy, and any change to the structure happens on the spot.
If the process has not settled and the columns change every week, it is also too early: you will spend your time reworking the schema instead of working. Let the process settle in the spreadsheet first, then move it.
The sign that it is time: you have started agreeing among yourselves about who edits the file when.
What next
To see what it looks like, open the demo — a pipeline on a real backend, free to log into. How it is built is in the case: the tables, the endpoints, the request log.
If you want the same kind of internal tool for your own process, describe the task.