A Domínio Visual não é uma startup. É uma empresa de sinalização visual — letras de bloco, fachadas, painéis, sinalização interna — que atende 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 planilhas de Excel, cadernos e conversas de WhatsApp, e passa a operar através de uma plataforma digital construída sob medida. O que se ganha, o que se perde, e o que quase sempre dá errado 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 o faturamento depende de quem lembra do que foi feito. Um software genérico não resolve nada disso porque o vocabulário é errado. A solução é uma plataforma pensada em torno do fluxo real da empresa, com estados que correspondem às fases físicas do trabalho e uma interface que qualquer pessoa da equipe consegue usar sem treinamento.
No caso da Domínio Visual, isso significou modelar dez estados que vão de "visita técnica" a "faturamento", um banco de dados MariaDB desenhado em torno de ordens de serviço, e um frontend que assume que o usuário está no meio de uma obra e não olhando para um dashboard de métricas.
O problema de negócio
Uma empresa de sinalização funciona por projeto. 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 externa, faz-se a montagem na fábrica, agenda-se a instalação, entrega-se, e só depois se fatura.
Cada uma dessas 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 perguntando "então, como está o meu trabalho?" para qualquer um deles.
Sem plataforma, a resposta a essa pergunta depende de quem atende. Cada pessoa tem uma parte do quebra-cabeça. A visão consolidada não existe em lugar nenhum — está distribuída.
Por que isso importa mais do que parece
Há três custos escondidos nesse 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 andamento e você tem várias horas por dia de gente qualificada fazendo 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 e-mail de três semanas atrás, ou porque a medição foi anotada a lápis e ninguém consegue ler.
Terceiro — e esse é o mais caro — o custo de faturamento perdido. Trabalhos que foram instalados mas nunca faturados 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 faturamento não emitido ou não cobrado. Não é um número que apareça em lugar nenhum — some silenciosamente.
O que significa "plataforma digital" para um negócio desses
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 exatamente ao que a empresa faz.
A diferença é sutil mas decisiva. Se o software chama uma ordem de serviço de "deal", "opportunity" ou "task", a equipe nunca vai usar consistentemente. Se chama "OS" e tem os estados que a equipe já usa mentalmente — visita, layout, aprovação, impressão, corte, serralheria, produção, montagem, expedição, faturamento — a adoção é imediata.
Esse é o argumento central para software sob 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 pensando no impacto operacional, não no que é interessante para o programador.
O banco de dados é MariaDB relacional, não um banco NoSQL da moda. Porque uma ordem de serviço tem relações rígidas com cliente, itens, histórico e faturamento, e quando um contador precisa rodar uma query para o fim do ano, SQL é uma linguagem que muita gente sabe ler.
A autenticação usa bcrypt para novos usuários mas mantém compatibilidade com MD5 legado. Não é elegante. É pragmático: significa que usuários existentes não precisam recuperar senha no dia da migração, o que é a diferença entre "todo mundo usa" e "metade da equipe desistiu".
O frontend é um SPA rápido servido por Nginx, com uma API Fastify em Node.js por trás. Poderia ser uma aplicação Rails clássica com renderização server-side. A escolha do SPA vem de um requisito concreto: quem está em campo fazendo instalações precisa atualizar estado pelo celular, muitas vezes com conexão de dados fraca. Um SPA com estado local e sincronização assíncrona funciona melhor nesse contexto do que um sistema que exige round-trip completo a cada clique.
Essa é a única razão pela qual a decisão faz sentido. Se todo mundo trabalhasse de escritório com fibra, um app tradicional teria sido mais barato de construir e manter.
Modelar o fluxo real: o problema dos estados
O erro mais comum quando se digitaliza um negócio desses é traduzir o fluxo real para um modelo simplificado de três ou quatro estados: pendente, em andamento, concluído. Fica limpo no diagrama e é inútil em campo.
A Domínio Visual opera com dez estados distintos. Cada um corresponde a uma fase física do trabalho e a uma equipe ou pessoa responsável:
- Encerrada (0) — estado final, após faturamento
- 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
- Serralheria (5) — estrutura metálica se aplicável
- Produção (6) — montagem na fábrica
- Montagem (7) — instalação no cliente
- Expedição (8) — logística de entrega
- Faturamento (9) — emissão de nota fiscal
- Aprovação de layout (10) — cliente valida antes de imprimir
Esse nível de granularidade não é excesso de engenharia. Cada estado corresponde a uma pessoa concreta que precisa 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 dela. Adoçã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 registrado com timestamp e usuário que fez a alteração.
Essa é 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 reclamando, qualquer pessoa consegue reconstruir a cronologia exata do trabalho sem depender da memória de quem esteve envolvido.
Quando há uma discussão interna sobre "quem disse o quê para quem", há um registro neutro que resolve a discussão em segundos.
Quando um novo membro da equipe entra, consegue entender o contexto de trabalhos antigos sem precisar perguntar para 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 que estar no histórico. Sempre.
O que quase sempre dá errado na primeira tentativa
Vale a pena ser específico sobre os erros que aparecem em quase todos os projetos desse tipo, para que quem estiver considerando avançar saiba o que evitar.
Erro um: começar pelo módulo de faturamento. É intuitivo — o faturamento é onde o dinheiro entra, então parece prioritário. É errado. Se o resto do sistema não estiver sendo usado, o faturamento continua sendo feito fora do sistema como antes. Comece pelo estado operacional das ordens; o faturamento segue naturalmente.
Erro dois: pedir opinião para toda a equipe antes de construir. Cada pessoa quer otimizar o software para a sua parte do fluxo, o que gera um Frankenstein de features contraditórias. Escolha uma ou duas pessoas experientes que vejam o negócio de ponta a ponta e ignore 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 equipe continua indo no antigo para consultar o passado. Migração de dados é chata, técnica e sem glamour, mas sem ela a adoçã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 todo mundo. 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 é sinalização, mas o padrão se aplica a qualquer empresa que venda projetos: agências criativas, construção civil, arquitetura, oficinas, gráficas, integradores de AV, empresas de eventos.
- Modele os estados que a equipe 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 obrigue todo mundo a recuperar senha no primeiro dia
- Banco de dados relacional para dados operacionais; se precisar de análise complexa depois, exporte
- Interface pensada para uso em celular com conexão ruim, não para monitor de escritório
- Faturamento vem depois do fluxo operacional estar consolidado, nunca antes
- Um responsável interno com poder de decisão para o projeto, não um comitê
Sobre a escolha entre software genérico e sob medida
A pergunta correta não é "custa mais fazer sob medida?". Custa. A pergunta é: quanto vale que a equipe use o sistema todos os dias e não abandone depois 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 equipe traduza mentalmente o vocabulário do software para o vocabulário do negócio. Essa tradução falha exatamente nos momentos em que o sistema mais precisava ser usado: quando há pressão, cliente irritado, prazo apertado.
Software sob 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 seu próprio schema — que você pode consultar, exportar, analisar sem depender de exports limitados de terceiros — é difícil de superestimar.
Isso não é uma regra universal. Uma equipe pequena começando deve usar Notion ou uma planilha até doer. Quando começa a doer, é sinal para construir.
Segurança e continuidade
Uma plataforma que gerencia ordens de serviço, dados de cliente e histórico de faturamento se torna rapidamente crítica para o negócio. Isso 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. Faça uma restauração completa num ambiente separado pelo menos duas vezes por ano.
HTTPS obrigatório e certificados renovados automaticamente com Let's Encrypt. Isso é padrão desde 2016 e ainda hoje aparecem empresas com o cadeado quebrado no navegador. Não há justificativa técnica em 2026 para servir uma aplicação de gestão empresarial em HTTP.
Controle de acessos por função. Nem todo mundo precisa ver tudo. Se o comercial não precisa ver margens, não vê. Se o instalador só precisa do endereço e do horário, é só isso que aparece. O princípio do menor privilégio, como o OWASP descreve há décadas, não é paranoia — é higiene básica.
LGPD: o que muda quando é software próprio
Empresas de serviços no Brasil lidam com dados pessoais de clientes: nomes, endereços, contatos, muitas vezes CPF ou CNPJ. A LGPD, no seu Artigo 7º, exige base legal clara para o tratamento desses dados e o Artigo 46 exige medidas técnicas apropriadas.
Software próprio dá vantagens concretas aqui: você consegue implementar retenção de dados adequada, pseudonimização onde faz sentido, direito ao apagamento sem depender de tickets de suporte para fornecedores externos, e logs auditáveis do quem-fez-o-quê. Software SaaS genérico dá tudo isso em teoria; na prática, cada uma dessas capacidades depende do plano contratado e da resposta do suporte.
Custo real: o que ninguém diz nas propostas
Um projeto como esse, 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 transformar isso em algo consistente para importar, consome mais tempo do que qualquer estimativa razoável sugere. Reserve pelo menos 15% do orçamento.
Treinamento e acompanhamento nas primeiras semanas. As primeiras duas semanas depois do arranque determinam se a adoção pega ou não. Ter alguém disponível para responder dúvidas, corrigir bugs pequenos rapidamente e ajustar detalhes de UX é o que separa "a equipe adotou" de "a equipe voltou para o WhatsApp".
Manutenção contínua. Servidor, backups, atualizaçõ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 quebrar.
Sinais de que chegou a hora de fazer isso
Alguns sinais concretos, do mais suave ao mais grave, que indicam que uma empresa de serviços está atingindo o limite do modelo de gestão manual:
- Você recebe ligações de clientes perguntando por trabalhos e precisa perguntar para três pessoas antes de responder
- A pessoa que gerencia o Excel principal saiu de férias e o negócio desacelerou
- Você descobre trabalhos concluídos há semanas que nunca foram faturados
- Discussões internas acabam com "achei que você ia cuidar disso"
- Novos colaboradores demoram semanas para entender onde está o quê
- Quando você cresce 20%, a coordenação piora exponencialmente em vez de escalar linearmente
Se você reconhece dois ou três desses sinais, provavelmente chegou a hora. Se reconhece quatro ou mais, a hora era 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 celular de quem está em campo.
A decisão entre genérico e sob medida é uma decisão sobre custo total de propriedade e sobre a probabilidade real de adoção pela equipe. Genérico é mais barato para arrancar; sob medida é mais barato de manter e usar. Para operações críticas, sob 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, até o melhor sistema fica meio adotado.
A próxima peça editorial olha para o oposto: quando faz sentido manter tudo em planilhas e resistir à tentação de digitalizar cedo demais. Nem toda empresa está pronta, e às vezes construir um sistema é mais uma forma de procrastinar decisões operacionais que precisam ser tomadas antes.