Replacing spreadsheets with a system: when a dashboard pays off

The short answer

A custom internal dashboard is a small web system built for one of the company's own processes, with a database, individual logins and rules the system enforces on its own; it pays off when a shared spreadsheet has reached the point where several people edit the same data and mistakes cost money. A spreadsheet does not break because it is big. It breaks in four places: concurrent editing, history that explains nothing, permissions that do not separate people, and business rules nobody checks at entry. The custom systems hub shows where this kind of dashboard fits in relation to other projects. The cutoff for switching is not revenue or headcount: it is how many people write to the same spreadsheet and how much it costs when a wrong value moves downstream. Below you will find how to recognize each breaking point, the cutoff test, and what to gather before asking for a dashboard.

What system replaces Excel?

There is no single program that replaces Excel in every company. For an operational process, the replacement is usually a custom internal dashboard or an off-the-shelf tool with a database, users and permissions. The choice depends on the rules that need to be enforced, the systems already in place and whether each person should see only the data that matches their role.

Excel is still useful as a spreadsheet for analysis, import and export. It stops being a good official source when the same record passes through sales, inventory, finance and shipping, because a cell does not represent the whole operation. At that point, the system should hold the core data, block invalid combinations and record who made each change.

1. The four places a shared spreadsheet breaks

A spreadsheet is an excellent tool for one person to think with. The problems start when it becomes the system behind an entire process, with people from different departments writing to it all day. Google Sheets and Excel each have a feature for every problem below. What is missing is not the feature: it is the feature being mandatory instead of depending on the goodwill of whoever is editing.

Each row of this table becomes a section. The question in every one is the same: when the rule fails, who notices, and when.

2. Concurrent editing: the problem is not the file, it is the operation

Co-authoring solved the old "file locked for editing" problem. Today several people open the same spreadsheet and type at the same time. In Excel, Microsoft's documentation makes this conditional on storing the file on OneDrive or SharePoint Online and using versions that support co-authoring. In Sheets, it is the default behavior.

What co-authoring does not solve is that a business process is rarely a single cell. "Picking the order" touches the status, the reserved quantity, the ship date and sometimes the inventory balance on another tab. The spreadsheet syncs each cell in isolation. It does not know that those four cells make up a single operation.

How this shows up day to day

• Two people reserve the last unit of the same item, each on a different row, because the balance only updates after the formula recalculates.
• Someone sorts the whole tab while another person is typing, and the typed value lands on the wrong row.
• A filter applied by one person hides rows that someone else is reviewing, and the review ends with "nothing pending".
• A formula dragged down to the end of the column gets wiped out by someone pasting data over it.

None of these cases is carelessness by a specific person. It is the predictable result of several people writing to a structure that has no concept of a transaction.

What a database does differently

In a dashboard backed by a relational database, "picking the order" is a transaction: either all the changes go in, or none do. If two people try to reserve the last unit, the database serializes both attempts and the second one gets a clear error instead of a silent negative balance. Sorting and filtering become part of each person's own screen, without changing anyone else's data.

3. History: knowing something changed is not knowing why

Google Sheets version history shows earlier versions and who edited, and lets you restore them. It is a good feature for undoing damage. For running a process, it has two limits.

The first is granularity. Restoring a version undoes everything that happened after it, including other people's correct work. In practice nobody restores: someone compares versions by hand and fixes things cell by cell.

The second is context. The history records that the cell went from "pending" to "paid". It does not record which order that was for, which receipt it was based on, or whether the person who changed it had the role to mark payments as received. When the question is "who authorized this?", the spreadsheet can only answer "who typed it".

What counts as useful history

Useful history answers four questions without anyone having to open old versions: what changed, from which value to which value, who changed it and through which action in the system. That becomes an audit table in the database. The PostgreSQL PL/pgSQL documentation itself includes an example trigger function that writes every insert, update and delete to a separate table, with the user and the timestamp.

CREATE TRIGGER auditar_pedidos
AFTER INSERT OR UPDATE OR DELETE ON pedidos
FOR EACH ROW EXECUTE FUNCTION registrar_auditoria();

The difference from spreadsheet history: the record is created together with the change, through the same door, and editing data through the system leaves a trail by definition.

4. Per-person permissions: protecting a cell is not access control

In Google Sheets you can protect a sheet or a range and choose who can edit it, or just show a warning to anyone who tries. In Excel there is password-based worksheet protection. Both work to keep someone from deleting a formula by accident. Neither was designed to separate what each person can see.

Microsoft is blunt in its documentation: Excel worksheet protection is not a security feature. It prevents changes to locked cells, and that is all. In Sheets, protection controls editing; anyone with access to the file can still see the contents of every tab.

Where this becomes a problem

• A salesperson needs to see their own orders, but there is only one spreadsheet and it shows everyone's commission.
• Finance needs to mark payments as received, but the same spreadsheet lets the warehouse edit the "paid" field.
• An outside contractor needs to update delivery status and, to do so, gets access to the entire file, customer data included.

The third case carries legal weight. In Brazil, the LGPD requires, in art. 46, technical and administrative measures to protect personal data against unauthorized access. Sharing the whole spreadsheet so someone can edit one column is hard to defend as an adequate measure.

How the dashboard solves it

In the dashboard, permissions are by role and, when needed, by row. The salesperson sees their own orders; finance sees the payment field and nothing else; the contractor sees only the deliveries assigned to them. PostgreSQL does this in the database itself with Row Level Security, and the documentation describes the default behavior when no policy is defined: "a default-deny policy". In other words, the database denies by default and allows only what has been explicitly permitted. It is the opposite of the spreadsheet, which allows everything and tries to protect pieces.

5. Business rules at entry: validation that only warns

Data validation in Sheets has two options for when the data is invalid: show a warning or reject the input. Many operational spreadsheets are set to warn, because at some point someone needed to "just let this one case through" and rejection got in the way. From then on, the rule is a suggestion.

Even when set to reject, validation applies to the cell. It checks that a date is a date, that a value is on a list. It does not know that the delivery date cannot be earlier than the order date, that a discount above a certain ceiling needs approval, or that a cancelled order cannot have a payment marked as received. Those rules live in the heads of the people doing the work and, with luck, in a document nobody opens.

The rule in the right place

In a dashboard, business rules live in two places. On the screen, to guide whoever is typing. In the database, to refuse anything that got past the screen by any route: import, integration, manual correction. The PostgreSQL documentation is direct: when you try to store a value that violates a constraint, "an error is raised".

ALTER TABLE pedidos
  ADD CONSTRAINT entrega_depois_do_pedido
  CHECK (data_entrega >= data_pedido);

With that, the rule no longer depends on someone remembering it. Wrong data does not get in, and the error message says why.

6. The cutoff: how many people edit and what an error costs

The criterion that comes up most in conversation is size: "once the company grows, we'll build a system". Size is a poor indicator. A large company can have a spreadsheet that only the controller edits, and it works. A small company can have an orders spreadsheet edited by sales, inventory, shipping and finance, and it is already the bottleneck.

Two variables decide better:

1. How many people write to the same data. One person editing and several reading is healthy spreadsheet use. Several people writing to the same rows is where all four breaking points show up together.
2. How much it costs when a wrong value moves downstream. An error someone notices right away and fixes on the spot is cheap. An error that turns into a wrongly invoiced order, a hole in inventory, a duplicated payment entry or exposed customer data is expensive, and it is usually discovered late.

The last row of the table is where the dashboard pays for itself. Not through productivity gains anyone can promise as a number, but because every error avoided there has a direct cost the company can measure itself: a cancelled invoice, a reshipped delivery, a refunded customer, hours spent reconciling.

7 signs your spreadsheet has stalled

1. There is someone whose informal job is "fixing the spreadsheet".
2. There are copies of the spreadsheet per department, and the meeting exists to reconcile the copies.
3. Someone has already asked "who changed this?" and the answer was to compare old versions.
4. The spreadsheet has a tab called "do not touch".
5. Changing a formula or filter changes the result for everyone.
6. The same order has to be typed into more than one file.
7. Nobody can explain which version is the official source of the data.

Internal business system: what goes into a dashboard

"Dashboard" is sometimes taken to mean a screen of charts. Here it means something else: the tool where the work actually happens, with charts as a by-product. A well-built custom internal dashboard has, at a minimum:

• A relational database with business rules as constraints, so the database refuses invalid data whether it comes from the screen, an import or an integration.
• Individual logins and roles (sales, inventory, finance, external), with permissions per screen, per field and, when needed, per row.
• An automatic audit trail: what changed, from what to what, who and when.
• Screens built around tasks, not tables: "pick order", "mark as paid", "record return", each one touching only what the task requires.
• Import and export to spreadsheets, because the spreadsheet is still great for one-off analysis. The difference is that it becomes an output, not the source.

Cost and timeline depend on scope, mainly integrations with other systems, permission granularity and auditing. If the dashboard also feeds a public front end, the article on headless WordPress helps separate operations from presentation.

How much does it cost to replace a spreadsheet with a system?

There is no responsible price without understanding the process. Integrations, permissions, auditing and data migration change the scope more than the number of screens does. The article How much does custom web system development cost explains how to compare proposals and running costs without turning an estimate into a promise.

8. How to map the process before asking for a dashboard

The most useful input for an honest quote is the current spreadsheet with the process described around it. Before talking to whoever will build it, write down:

• Who edits what. A list of people or roles and which columns each one changes day to day.
• The rules that currently live in people's heads. "A discount above a certain amount needs approval", "a cancelled order cannot be marked as paid", "only finance marks things as paid".
• The errors that have already happened. A few concrete cases, with what each one cost. They show where the rule needs to live in the database.
• What the spreadsheet talks to. ERP, online store, bank, email, another spreadsheet. Every integration is scope.
• Who needs to see without editing. Leadership, the accountant, outside contractors.

With that in hand, you can separate what is essential for the first version from what can wait. An internal dashboard does not need to cover the entire process from day one: starting with the part where several people write and errors are expensive already takes the spreadsheet off the critical path.

Frequently asked questions

Can't this be solved with Apps Script or a macro in the spreadsheet itself?

You can automate tasks and reinforce some rules. The limit stays the same: anyone with edit permission on the file can bypass the rule by editing the cell directly, and the spreadsheet still has no transactions and no per-row permissions. A script is a good stopgap when the problem is repetition; it does not solve things when the problem is several people writing to the same data with costly errors.

Wouldn't a no-code tool solve the same problem?

In many cases, yes, and it is worth considering before a custom dashboard. No-code tools with a database behind them already provide individual logins and some permission control. The cutoff usually appears when the business rule is too specific for the tool, when permissions need to go down to the row level, or when there is an integration with an ERP or store that the tool does not cover.

Will the team lose the flexibility of the spreadsheet?

They lose the flexibility to change the process without anyone knowing, which is exactly what causes the errors. The flexibility for analysis remains: the dashboard exports to a spreadsheet, and anyone can build whatever pivot table they want on top of data that is now reliable.

Does the dashboard replace the ERP?

That is not the goal. The dashboard covers the process the ERP does not cover, or covers poorly, and that is why it ended up in a spreadsheet. When there is an ERP, the dashboard reads from and writes to it through an integration, instead of duplicating records.

Conclusion

A shared spreadsheet becomes a bottleneck when several people write to the same data and errors are expensive, not when the company grows. The symptoms repeat: edits that overwrite, history that does not explain, permissions that do not separate and rules that only warn. A custom internal dashboard solves all four by putting the rules in the database instead of in the memory of the people doing the work. If this sounds like your situation, send the process currently running on the spreadsheet and how many people edit it through oailton.dev/en/contato, and I will tell you whether it calls for a dashboard, an adjustment to the spreadsheet itself or an off-the-shelf tool.

To see how I run custom system projects, from discovery to maintenance, the Systems page sums up the service and the portfolio shows delivered cases.