A Domínio Visual não é uma startup. É uma empresa de sinalética visual — letras de bloco, fachadas, painéis, sinalização interior — que trabalha para clientes que precisam do trabalho instalado numa data específica, não numa sprint hipotética.
Este artigo é sobre o que acontece quando um negócio de serviços real decide parar de gerir ordens em folhas de Excel, cadernos e conversas de WhatsApp, e passa a operar através de uma plataforma digital construída à medida. O que se ganha, o que se perde, e o que quase sempre corre mal na primeira tentativa.
Resumo executivo
Um negócio de serviços tem três problemas operacionais crónicos: o estado real de cada trabalho está distribuído por várias cabeças, o histórico do cliente vive em conversas, e a facturação depende de quem se lembra do que foi feito. Um software genérico não resolve nada disto porque o vocabulário é errado. A solução é uma plataforma pensada à volta do fluxo real da empresa, com estados que correspondem às fases físicas do trabalho e uma interface que qualquer pessoa da equipa consegue usar sem formação.
No caso da Domínio Visual, isto significou modelar dez estados que vão de "visita técnica" a "facturação", uma base de dados MariaDB desenhada à volta de ordens de serviço, e um frontend que assume que o utilizador está a meio de uma obra e não a olhar para um dashboard de métricas.
O problema de negócio
Uma empresa de sinalética funciona por projecto. Cada ordem de serviço passa por várias etapas físicas: alguém vai ao local medir, alguém desenha o layout, o layout vai para aprovação do cliente, imprime-se ou corta-se o material, monta-se a estrutura metálica se for exterior, faz-se a montagem em fábrica, agenda-se a instalação, entrega-se, e só depois se factura.
Cada uma destas etapas envolve pessoas diferentes. O comercial que fez a visita não é o designer que faz o layout. O designer não é quem opera a máquina de corte. Quem instala no local raramente é quem esteve na fábrica. E o cliente liga a perguntar "então, como está o meu trabalho?" a qualquer um deles.
Sem plataforma, a resposta a essa pergunta depende de quem atende. Cada pessoa tem uma parte do puzzle. A visão consolidada não existe em lado nenhum — está distribuída.
Porque é que isto importa mais do que parece
Há três custos escondidos neste modelo, e todos consomem margem sem aparecer na demonstração de resultados.
Primeiro, o custo de coordenação. Cada trabalho gera dez a vinte micro-conversas por WhatsApp para confirmar estado. Multiplica isso por trinta ou quarenta obras em curso e tens várias horas por dia de gente qualificada a fazer o trabalho de um sistema.
Segundo, o custo de retrabalho. Sem histórico centralizado, é frequente refazer trabalho porque a versão aprovada do layout está enterrada num email de há três semanas, ou porque a medição foi anotada a lápis e ninguém consegue ler.
Terceiro — e este é o mais caro — o custo de facturação em falta. Trabalhos que foram instalados mas nunca facturados porque saíram do radar. Aditivos combinados verbalmente que nunca chegaram ao orçamento final. Um estudo do Aberdeen Group há alguns anos sugeria que empresas sem processos digitais estruturados perdiam entre 1% e 3% da receita anual em facturação não emitida ou não cobrada. Não é um número que apareça em nenhum lado — desaparece silenciosamente.
O que significa "plataforma digital" para um negócio destes
Não é um CRM. Não é um ERP. Não é um Trello com estados personalizados. É todas essas coisas ao mesmo tempo, mas com um vocabulário que corresponde exactamente ao que a empresa faz.
A diferença é subtil mas decisiva. Se o software chama uma ordem de serviço de "deal", "opportunity" ou "task", a equipa nunca vai usá-lo consistentemente. Se chama "OS" e tem os estados que a equipa já usa mentalmente — visita, layout, aprovação, impressão, corte, serralharia, produção, montagem, expedição, facturação — a adopção é imediata.
Este é o argumento central para software à medida em negócios de serviços: não é sobre features. É sobre linguagem.
As decisões técnicas que importam para o negócio
Cada escolha técnica aqui foi feita a pensar no impacto operacional, não no que é interessante para o programador.
A base de dados é MariaDB relacional, não uma base NoSQL da moda. Porque uma ordem de serviço tem relações rígidas com cliente, itens, historial e facturação, e quando um contabilista precisa de correr uma query para o fim do ano, SQL é uma linguagem que muita gente sabe ler.
A autenticação usa bcrypt para novos utilizadores mas mantém compatibilidade com MD5 legacy. Não é elegante. É pragmático: significa que utilizadores existentes não precisam de recuperar palavra-passe no dia da migração, o que é a diferença entre "toda a gente usa" e "metade da equipa desistiu".
O frontend é uma SPA rápida servida por Nginx, com uma API Fastify em Node.js por trás. Podia ser uma aplicação Rails clássica com renderização server-side. A escolha do SPA vem de um requisito concreto: quem está no terreno a fazer instalações precisa de actualizar estado do telemóvel, muitas vezes com ligação de dados fraca. Uma SPA com estado local e sincronização assíncrona funciona melhor nesse contexto do que um sistema que exige round-trip completo por cada clique.
Esta é a única razão pela qual a decisão faz sentido. Se toda a gente trabalhasse de escritório com fibra, uma app tradicional teria sido mais barata de construir e manter.
Modelar o fluxo real: o problema dos estados
O erro mais comum quando se digitaliza um negócio destes é traduzir o fluxo real para um modelo simplificado de três ou quatro estados: pendente, em curso, concluído. Fica limpo no diagrama e é inútil no terreno.
A Domínio Visual opera com dez estados distintos. Cada um corresponde a uma fase física do trabalho e a uma equipa ou pessoa responsável:
- Encerrada (0) — estado final, após facturação
- Visita (1) — comercial vai ao local medir
- Layout (2) — designer cria proposta visual
- Impressão (3) — vinil ou material impresso
- Corte (4) — corte de letras ou material rígido
- Serralharia (5) — estrutura metálica se aplicável
- Produção (6) — montagem em fábrica
- Montagem (7) — instalação no cliente
- Expedição (8) — logística de entrega
- Facturação (9) — emissão de factura
- Aprovação de layout (10) — cliente valida antes de imprimir
Este nível de granularidade não é excesso de engenharia. Cada estado corresponde a uma pessoa concreta que precisa de saber "quais os trabalhos que estão comigo agora". Colapsar dois estados num só significa que essa pessoa passa a ver trabalhos que não são para ela. Adopção cai imediatamente.
Histórico: a feature invisível que resolve mais problemas do que qualquer outra
Todas as ordens de serviço têm uma tabela associada de histórico. Cada mudança de estado, cada nota, cada anexo, fica registado com timestamp e utilizador que fez a alteração.
Esta é a feature que ninguém pede na fase de levantamento e que passa a ser a mais usada seis meses depois. Porque resolve três problemas operacionais que não pareciam ter solução técnica:
Quando o cliente liga a reclamar, qualquer pessoa consegue reconstruir a cronologia exacta do trabalho sem depender da memória de quem esteve envolvido.
Quando há uma discussão interna sobre "quem disse o quê a quem", há um registo neutro que resolve a discussão em segundos.
Quando um novo membro da equipa entra, consegue perceber o contexto de trabalhos antigos sem ter de perguntar a cinco pessoas.
A regra prática é: se algo pode gerar uma pergunta "então mas quando é que…" ou "quem foi que…" três meses depois, tem de estar no histórico. Sempre.
O que quase sempre corre mal na primeira tentativa
Vale a pena ser específico sobre os erros que aparecem em quase todos os projectos deste tipo, para que quem estiver a considerar avançar saiba o que evitar.
Erro um: começar pelo módulo de faturação. É intuitivo — a facturação é onde o dinheiro entra, portanto parece prioritário. É errado. Se o resto do sistema não estiver a ser usado, a facturação continua a ser feita fora do sistema como antes. Começa pelo estado operacional das ordens; a facturação segue naturalmente.
Erro dois: pedir opinião a toda a equipa antes de construir. Cada pessoa quer optimizar o software para a sua parte do fluxo, o que gera um Frankenstein de features contraditórias. Escolhe uma ou duas pessoas experientes que vejam o negócio de ponta a ponta e ignora o resto até haver uma versão funcional para reagir.
Erro três: não migrar dados históricos. Um sistema novo sem os últimos dois anos de trabalhos é um sistema vazio. A equipa continua a ir ao velho para consultar o passado. Migração de dados é chata, técnica e não tem glamour, mas sem ela a adopção é sempre parcial.
Erro quatro: dashboards antes de fluxo. Gráficos são vistos uma vez por semana pela gerência. O fluxo diário é usado por toda a gente. Uma plataforma sem dashboards mas com fluxo funcional é útil desde o dia um. O inverso não é.
Boas práticas que valem para qualquer negócio de serviços
A Domínio Visual é sinalética, mas o padrão aplica-se a qualquer empresa que venda projectos: agências criativas, construção civil, arquitectura, oficinas, gráficas, integradores de AV, empresas de eventos.
- Modela os estados que a equipa já usa mentalmente, não os que parecem limpos num diagrama
- O histórico de cada trabalho é obrigatório, não opcional
- Autenticação híbrida durante a migração — não obrigues toda a gente a recuperar palavra-passe no primeiro dia
- Base de dados relacional para dados operacionais; se precisares de análise complexa depois, exporta
- Interface pensada para uso em telemóvel com má ligação, não para monitor de escritório
- Facturação vem depois do fluxo operacional estar consolidado, nunca antes
- Um responsável interno com poder de decisão para o projecto, não um comité
Sobre a escolha entre software genérico e à medida
A pergunta correcta não é "custa mais fazer à medida?". Custa. A pergunta é: quanto vale que a equipa use o sistema todos os dias e não abandone ao fim de três meses?
Software genérico — um Monday, um Asana, um HubSpot adaptado com campos personalizados — é mais barato de comprar. É também sistematicamente mais caro de manter, porque exige que a equipa traduza mentalmente o vocabulário do software para o vocabulário do negócio. Essa tradução falha exactamente nos momentos em que o sistema mais precisava de ser usado: quando há pressão, cliente irritado, prazo apertado.
Software à medida com vocabulário próprio elimina essa tradução. O custo inicial é maior. O custo total de propriedade em cinco anos é quase sempre menor. E o valor de ter dados operacionais estruturados no teu próprio schema — que podes consultar, exportar, analisar sem depender de exports limitados de terceiros — é difícil de sobrestimar.
Isto não é uma regra universal. Uma equipa pequena a começar deve usar Notion ou uma folha de cálculo até doer. Quando começa a doer, é sinal para construir.
Segurança e continuidade
Uma plataforma que gere ordens de serviço, dados de cliente e histórico de facturação torna-se rapidamente crítica para o negócio. Isto obriga a três disciplinas que empresas de serviços tradicionalmente subestimam.
Backups. Não semanais. Diários no mínimo, idealmente incrementais horários. Testados. Um backup nunca testado é uma esperança, não é uma garantia. Faz uma restauração completa num ambiente separado pelo menos duas vezes por ano.
HTTPS obrigatório e certificados renovados automaticamente com Let's Encrypt. Isto é padrão desde 2016 e ainda hoje aparecem empresas com o cadeado partido no browser. Não há justificação técnica em 2026 para servir uma aplicação de gestão empresarial em HTTP.
Controlo de acessos por função. Nem toda a gente precisa de ver tudo. Se o comercial não precisa de ver margens, não vê. Se o instalador só precisa da morada e do horário, é só isso que aparece. O princípio do menor privilégio, como o OWASP descreve há décadas, não é paranóia — é higiene básica.
GDPR: o que muda quando é software próprio
Empresas de serviços em Portugal lidam com dados pessoais de clientes: nomes, moradas, contactos, muitas vezes NIF. O RGPD, no seu Artigo 6.º, exige base legal clara para o tratamento destes dados e o Artigo 32.º exige medidas técnicas apropriadas.
Software próprio dá vantagens concretas aqui: consegues implementar retenção de dados adequada, pseudonimização onde faz sentido, direito ao apagamento sem depender de tickets de suporte a fornecedores externos, e logs auditáveis do quem-fez-o-quê. Software SaaS genérico dá isto tudo em teoria; na prática, cada uma destas capacidades depende do plano contratado e da resposta do suporte.
Custo real: o que ninguém diz nas propostas
Um projecto como este, feito bem, tem quatro componentes de custo que a maior parte das propostas subestima.
Desenvolvimento inicial é a parte visível — a construção da aplicação, o design, os testes, a colocação em produção. Tipicamente entre 40% e 60% do custo total no primeiro ano.
Migração de dados é sempre subestimada. Extrair dados de Excels, folhas de papel digitalizadas, sistemas antigos, e transformá-los em algo consistente para importar, consome mais tempo do que qualquer estimativa razoável sugere. Reserva pelo menos 15% do orçamento.
Formação e acompanhamento nas primeiras semanas. As primeiras duas semanas a seguir ao arranque determinam se a adopção pega ou não. Ter alguém disponível para responder a dúvidas, corrigir bugs pequenos rapidamente e ajustar detalhes de UX é o que separa "a equipa adoptou" de "a equipa voltou ao WhatsApp".
Manutenção contínua. Servidor, backups, actualizações de segurança, pequenas melhorias mensais. Um valor mensal previsível que muitas empresas gostam de fingir que não existe até o sistema partir.
Sinais de que está na hora de fazer isto
Alguns sinais concretos, do mais suave ao mais grave, que indicam que uma empresa de serviços está a atingir o limite do modelo de gestão manual:
- Recebes chamadas de clientes a perguntar por trabalhos e precisas de perguntar a três pessoas antes de responder
- A pessoa que gere o Excel principal foi de férias e o negócio abrandou
- Descobres trabalhos concluídos há semanas que nunca foram facturados
- Discussões internas acabam com "achei que tu ias tratar disso"
- Novos colaboradores demoram semanas a perceber onde é que está o quê
- Quando cresces 20%, a coordenação piora exponencialmente em vez de escalar linearmente
Se reconheces dois ou três destes sinais, provavelmente está na hora. Se reconheces quatro ou mais, estava na hora há dois anos.
Key takeaways
Um negócio de serviços não precisa de tecnologia impressionante. Precisa de um sistema que use o vocabulário certo, capture o estado real do trabalho, mantenha histórico auditável e funcione no telemóvel de quem está no terreno.
A decisão entre genérico e à medida é uma decisão sobre custo total de propriedade e sobre a probabilidade real de adopção pela equipa. Genérico é mais barato de arrancar; à medida é mais barato de manter e usar. Para operações críticas, à medida quase sempre ganha em três a cinco anos.
A migração é uma questão de gestão de mudança mais do que de engenharia. O software estar pronto é uma condição necessária mas não suficiente. Sem um responsável interno com autoridade e sem migração séria de dados históricos, mesmo o melhor sistema fica meio adoptado.
A próxima peça editorial olha para o oposto: quando é que faz sentido manter tudo em folhas de cálculo e resistir à tentação de digitalizar cedo demais. Nem toda a empresa está pronta, e às vezes construir um sistema é mais uma forma de procrastinar decisões operacionais que precisam de ser tomadas antes.