Há duas formas de transformar uma folha de cálculo numa app. A primeira mantém a folha como base de dados e põe uma aplicação por cima: a Glide, o AppSheet e a Softr fazem-no numa tarde, e cada edição na app cai numa célula. A segunda passa os dados para uma verdadeira base de dados e gera a aplicação sobre ela: demora um dia ou dois e, em troca, tem perfis, histórico de alterações e nenhum limite de linhas. A regra prática é simples. Mantenha a folha se uma só equipa a usa, sobretudo para ler, e ela tem alguns milhares de linhas. Mude os dados se várias pessoas escrevem nela todos os dias, se algumas não devem ver tudo, ou se o ficheiro se tornou, sem ninguém dar por isso, o sistema de registo da empresa.
Este guia cobre os dois caminhos: os limites que tornam a mudança necessária, como preparar o ficheiro, que é a maior parte do trabalho seja qual for o caminho, um método em cinco passos e as ferramentas comparadas em preço, limites de linhas e no que fica seu no fim. Aplica-se ao Excel e ao Google Sheets por igual, e à exportação CSV de quase tudo o resto.
Duas formas de transformar uma folha de cálculo numa app
A expressão "folha de cálculo para app" esconde duas operações muito diferentes. Na primeira, nada se move: uma ferramenta liga-se ao seu Google Sheet ou ficheiro Excel, lê as linhas e mostra-as como listas, formulários e páginas de detalhe num telemóvel ou num navegador. Na segunda, as linhas são importadas uma vez para uma base de dados, a folha é arquivada e a aplicação passa a ser dona dos dados.
| Caminho | Como funciona | Primeira versão | A folha de cálculo passa a ser | Ideal para |
|---|---|---|---|---|
| Uma app por cima da folha (Glide, AppSheet, Softr) | A ferramenta lê e escreve as linhas da folha; cada coluna passa a ser um campo | Horas | A base de dados, como antes | Formulários, listas e consultas para uma equipa pequena; recolha de dados no terreno |
| Uma base de dados e uma app gerada (Cadrant, ou low-code sobre PostgreSQL) | As linhas são importadas para tabelas com relações; ecrãs e perfis são gerados | Um dia ou dois | Um arquivo | Ferramentas multiutilizador com perfis, regras e histórico |
Quando uma folha de cálculo deixa de chegar
Os limites técnicos são generosos e raramente são o verdadeiro problema. Uma folha de Excel suporta 1,048,576 linhas por 16,384 colunas, e um ficheiro do Google Sheets suporta até 20 milhões de células. Os limites que se atingem primeiro são os humanos.
| Limite | Folha de cálculo | Aplicação sobre uma base de dados |
|---|---|---|
| Tamanho | Excel: 1,048,576 linhas por folha. Google Sheets: 20 milhões de células. XLS antigo: 65,536 linhas | Milhões de linhas por tabela sem limite do produto |
| Várias pessoas a escrever | Ganha a última gravação, ou aparece uma cópia em conflito | Cada linha é gravada por si; sem sobreposições |
| Quem vê o quê | Separadores ocultos e intervalos protegidos, fáceis de contornar | Perfis aplicados na base de dados, linha a linha |
| Quem alterou o quê | Histórico de versões do ficheiro, não do registo | Um registo por entrada, com autor e hora |
| Regras | Fórmulas e validação de dados, que qualquer editor pode apagar | Validações e restrições que ninguém pode saltar |
O problema mais discreto é o erro. A compilação de auditorias de campo de Ray Panko, na Universidade do Havai, concluiu que 88% das 113 folhas operacionais auditadas desde 1995 continham erros, a maioria em fórmulas que ninguém tinha verificado. Se o seu ficheiro mostra dois ou mais dos cinco sinais do nosso guia sobre como criar ferramentas internas, vários editores, linhas ocultas, um separador em que ninguém ousa mexer, nenhum histórico, dados reescritos, é o segundo caminho que deve planear.
Preparar o ficheiro: das colunas às tabelas
Seja qual for a ferramenta que escolher, ela vai ler o seu ficheiro da mesma maneira: uma linha de cabeçalho, um registo por linha, um valor por célula. A maioria das folhas que cresceram ao longo de anos quebra as três regras em algum ponto. Uma hora de limpeza antes da importação poupa um dia de correções depois.
Segue-se o passo que transforma uma folha num modelo de dados. Procure valores que se repetem: um nome de cliente escrito em quarenta linhas de encomendas, um produto e o seu preço copiados em cada linha. Cada coisa repetida passa a ter a sua própria tabela, com um ID, e a linha original guarda apenas o ID. Chama-se normalização, e é a diferença entre um ficheiro e uma base de dados.
Cada fórmula merece uma decisão. Uma coluna que calcula um total a partir da quantidade e do preço passa a campo calculado. Uma coluna que assinala encomendas atrasadas passa a regra da aplicação. Um separador de tabela dinâmica que resume as vendas por mês passa a ecrã de dashboard, gerado a partir da tabela de encomendas. Nenhuma é importada como dados.
Construir a app em cinco passos
- 1. Congele o ficheiro e exporte-o. Anuncie uma data, ponha a folha só de leitura e exporte um CSV por separador. No primeiro caminho, é aqui que liga a ferramenta à folha.
- 2. Crie as tabelas e importe as linhas. Importe primeiro as tabelas de referência (clientes, produtos) e depois as que apontam para elas (encomendas). Confira o número de linhas com a folha antes de avançar.
- 3. Gere os ecrãs. Uma lista, uma página de detalhe, um formulário e uma mudança de estado para cada tabela principal. Nada mais na primeira versão: sem relatórios, sem notificações.
- 4. Refaça as regras. A validação de dados passa a campos obrigatórios e valores permitidos. As fórmulas passam a campos calculados. O código de cores passa a estados. Escreva a matriz de perfis: quem pode ver, criar, editar e apagar em cada tabela.
- 5. Use as duas durante uma semana. Três utilizadores reais, dados reais, a folha de cálculo congelada ao lado. Reúna todas as queixas numa só lista, corrija o modelo de dados uma vez e depois reforme o ficheiro.
Na Cadrant, os passos 2 a 4 são o que a plataforma gera a partir desse briefing. Cria uma aplicação React ligada a uma base de dados PostgreSQL no seu próprio projeto Supabase, com tabelas, relações e índices derivados da descrição, e páginas de login no Supabase Auth com os perfis que indicou. As linhas são importadas a partir de CSV no painel do Supabase, que pode abrir a partir do painel Base de dados do projeto, e as políticas de segurança ao nível da linha que determinam quem vê o quê são criadas na base de dados a partir do prompt; a documentação recomenda revê-las antes de ir para produção. O plano Starter custa $20 por mês, quantos forem os colegas a usar a ferramenta, e a partir do plano Pro ($40 por mês) o código sincroniza com um repositório GitHub. Os detalhes estão na página do criador de ferramentas internas.
Que ferramenta para que folha de cálculo
Os preços são os preços de tabela públicos em setembro de 2026, com faturação anual quando há escolha. Listamos a Cadrant em primeiro lugar por ser o nosso próprio produto e a única abaixo que segue o segundo caminho; as outras três são as ferramentas de referência do primeiro caminho e, para uma equipa pequena que sobretudo lê, são a resposta mais rápida.
| Ferramenta | Abordagem | Preço | Limite de linhas | O que fica seu | Ideal para |
|---|---|---|---|---|---|
| Cadrant | Importação para PostgreSQL, app gerada a partir de uma descrição | Fixo, a partir de $20 por mês, sem utilizadores | Nenhum do produto | Base de dados no seu Supabase, código no GitHub (plano Pro) | Ferramentas multiutilizador com perfis e regras |
| Glide | App por cima de Sheets, Excel ou das suas próprias tabelas | $19 a $199 por mês; utilizadores empresariais além de 30 a $5 cada; atualizações medidas | 25,000 linhas por app sobre uma folha de cálculo | A folha; a app fica na Glide | Apps móveis polidas para uma equipa pequena |
| AppSheet | App por cima de Sheets, Excel ou de uma base de dados | $5 a $20 por utilizador por mês; Core incluído na maioria dos planos pagos do Google Workspace | O da origem, com limites de sincronização | A folha; a app fica no AppSheet | Recolha de dados no terreno numa empresa com Google Workspace |
| Softr | Portais sobre Airtable, Sheets ou SQL | $25, $119 ou $395 por mês com quotas de utilizadores | O da origem | A origem; a app fica na Softr | Portais de cliente sobre dados que guarda noutro sítio |
Se os seus dados já estão no Airtable e não numa folha, aplica-se o mesmo raciocínio com mais uma variável, a fatura por utilizador; o nosso guia das alternativas ao Airtable trata esse caso.
- Dois caminhos: uma app por cima da folha em horas, ou os dados passados para uma base de dados e a app gerada em um dia ou dois.
- As folhas de cálculo falham nas pessoas antes de falharem no tamanho: edições simultâneas, sem perfis, sem histórico, regras que qualquer um pode apagar.
- A preparação é a maior parte do trabalho: uma linha de cabeçalho, um valor por célula, um ID por linha, valores repetidos separados nas suas próprias tabelas.
- Importe primeiro as referências, gere os ecrãs mais pequenos, refaça as regras, use as duas durante uma semana.