SaaS de agenda que atende do profissional autônomo à rede com franquia no mesmo motor.
Conduzi o benchmark, a lista mestre de funcionalidades, o empacotamento por plano, a
arquitetura de acesso e as telas. O escopo saiu de quatro concorrentes mapeados em
agosto de 2026, não de suposição sobre o mercado.
Papel
Product Designer, PM e PO. Benchmark, definição de escopo, empacotamento por plano, arquitetura de acesso e desenho das telas.
O que eu fiz
Mapeamento de quatro concorrentes, lista mestre priorizada de P0 a P3, modelo de cinco planos, matriz de papéis e permissões, navegação e interface.
Alcance
Do autônomo que atende sozinho à rede com franquia. Dentro do estabelecimento, quatro papéis: administrador, gerente, recepção e profissional.
Formato
Plataforma multi-inquilino. Um motor só, cinco faixas de plano, e a marca do cliente aplicada em tempo de execução.
Telas do ambiente de desenvolvimento, com contas e dados fictícios. O produto está em
construção: parte dos módulos aparece nas capturas como escopo declarado na própria tela,
e é assim que eles estão hoje.
Tela Clientes, na conta de quem administra uma rede
A linha embaixo do título é a regra comercial escrita na tela: sem limite de
clientes, em qualquer plano. O que separa os planos é tamanho de equipe e
complexidade da organização, nunca o recurso essencial.
01 O contexto e quem era afetado
Dois públicos, e o mesmo motor.
De um lado a lash designer que atende sozinha e decide a compra em minutos, pelo
celular, olhando o preço no site. Do outro a rede de quatro unidades, com recepção,
gerente e escritório central. Os dois compram agenda, e quase nada mais é igual.
O que cada um precisa não se sobrepõe:
quem trabalha sozinho quer cliente novo, menos falta e sair do WhatsApp o dia inteiro;
quem tem quatro unidades quer acerto de comissão correto, padrão entre lojas e número consolidado;
quem atende sozinho opera no celular, entre um cliente e outro; a recepção opera num desktop, com alguém esperando na frente;
o autônomo não pode nem ver multi-unidade, permissão e DRE, porque cada campo a mais é um motivo de desistir na primeira semana.
A saída comum do mercado é vender isso como plano barato e plano caro, e tratar
a diferença como quantidade de recurso liberado. O efeito prático é que quem cresce
precisa trocar de ferramenta, e quem é pequeno paga para não usar.
02 O que eu descobri
Quatro concorrentes, e uma interseção vazia.
Mapeei quatro produtos em 03/08/2026: Trinks, AgendaBella, Gendo e Reservio. Preço
público faixa a faixa, o que cada plano inclui, add-on cobrado à parte, cota de
mensagem, teto de profissionais e o que simplesmente não existe no produto.
Descoberta 01. Os três eixos que decidem a compra no Brasil nunca aparecem
juntos. WhatsApp de transação (agendar, reagendar e cancelar dentro da conversa),
sinal via Pix com confirmação automática e cálculo de comissão por profissional. Cada
um dos quatro entrega parte, e nenhum entrega os três.
Eixo
Quem entrega, entre os quatro
WhatsApp de transação
um só, e ele não calcula comissão. Nos outros é notificação por add-on, ou chatbot com cota apertada.
Sinal via Pix
três dos quatro. O que não tem é o de fora do Brasil, que também não tem WhatsApp.
Comissão por profissional
dois dos quatro, e são justamente os dois sem WhatsApp de transação.
Os três no mesmo produto
nenhum. É o posicionamento que estava livre, e é a tese do produto.
Descoberta 02. A rede pequena não tem para onde ir. Entre duas e cinco unidades,
o salão é grande demais para os produtos de teto baixo, que param em dez profissionais,
e pequeno demais para o comercial dos grandes, onde o preço vira “sob consulta”.
Ele quer preço publicado e comissão automatizada, e hoje precisa escolher um dos
dois.
Descoberta 03. O que sobe de plano, nos quatro, é recurso essencial. Lembrete de
horário como add-on pago, cota de vinte mensagens por mês, histórico de relatório
cortado no plano de entrada. Quem cancela não cancela por falta de função: cancela por
cobrança surpresa e por cota estourada em dia cheio.
Não existe plano barato e plano caro. Existe um motor que precisa nascer com unidade e
escopo de permissão, mesmo quando o cliente tem uma cadeira só.
Descoberta 04, e é ela que decidiu a arquitetura. Multi-unidade, perfil de acesso e
consolidação de relatório não são funcionalidade para acrescentar depois: são modelo de
dados. Retrofitar isso é reescrever o produto, e é o motivo de o concorrente de teto
baixo não conseguir subir para a rede.
03 Como o escopo foi decidido
Uma lista mestre, com prioridade e onda.
O benchmark virou uma lista única de cerca de 150 funcionalidades, em 17 seções de
módulo. Cada linha carrega o que cada concorrente entrega, para qual dos dois públicos
ela serve, e a prioridade de P0 a P3. É dela que sai o que entra no MVP.
A prioridade não é opinião sobre importância. P0 é o que faz o produto bater os
quatro na interseção vazia, e o resto desce: P1 fecha o salão de seis a vinte
pessoas, P2 abre a rede, P3 depende de contrato com terceiro. Split de comissão na
maquininha, por exemplo, é a arma comercial do maior concorrente e ficou em P3 por
depender de parceria de adquirente. Prometer isso em roadmap sem contrato assinado é
criar dívida com o cliente.
A rastreabilidade não parou no documento. Cada item do menu declara a seção da
lista mestre que o originou, a onda a que pertence e o plano em que aparece. Quem abre
um módulo que ainda não faz nada lê o escopo dele e a origem, em vez de encontrar uma
tela vazia.
Tela Um módulo que ainda não faz nada, e declara isso
As duas etiquetas do alto dizem quando e para quem: onda 1 do MVP, a
partir do plano Solo. Embaixo, a linha que fecha a honestidade da tela:
“estrutura criada, comportamento ainda não”. Um módulo em branco vira defeito
reportado; um módulo que declara o próprio estado vira previsibilidade.
04 O empacotamento
Cinco planos, e nenhum recurso essencial fora.
Solo, Studio, Salão, Rede e Franquia. WhatsApp, Pix, comissão, lembrete e histórico
ilimitado entram em todos, inclusive no mais barato. O que sobe de faixa é número de
profissionais, número de unidades, perfis de acesso, profundidade de relatório e marca
própria.
É o oposto do que dois dos quatro concorrentes fazem, e é o argumento comercial contra
eles. Cobrar o lembrete à parte rende no primeiro mês e produz o cancelamento do sexto.
O plano não é escolhido, é derivado do tamanho da equipe. Isso muda uma pergunta
de produto inteira: prender um módulo a uma faixa alta deixa de significar
“recurso avançado” e passa a significar “esta tela só existe acima de N
cadeiras”. Foi o que aconteceu com a tela de unidades, presa ao plano Rede até
10/08/2026: um studio de três pessoas pode ter três endereços, pagaria por eles e não
teria onde administrá-los. Ela desceu para o plano de entrada, e a regra que ficou é
perguntar, antes de gatear qualquer módulo por plano, se o critério real é
tamanho de equipe. Quando não é, o recorte certo é por papel.
Tela Console da plataforma, na conta de quem administra a Nexa
O console é outro produto para outro público: quem opera aqui é a equipe da
plataforma, com tabela de usuário, cookie e prefixo de rota próprios. Nenhuma sessão de
salão alcança esta tela. Os dois estabelecimentos da lista existem de propósito:
com um só, uma falha de isolamento entre clientes passaria despercebida em todo teste.
05 Decisões de design
Quatro decisões de design, e a origem de cada uma.
5.1
O que o plano não inclui some da tela
Módulo fora do plano não fica cinza, não ganha cadeado e não abre página de
venda. Ele não existe na navegação, e a API responde que está fora do plano se
alguém tentar o endereço na mão.
A razão é a descoberta 01 lida ao contrário: para o autônomo, cada linha de menu
que ele não pode usar é uma decisão a tomar e um motivo de achar o produto grande
demais. Cadeado é anúncio, e anúncio dentro da ferramenta que a pessoa já pagou é
atrito, não conversão.
Vem da descoberta 01
5.2
Duas perguntas que nunca se misturam
O plano inclui este módulo é pergunta comercial. O papel pode esta
ação é pergunta de segurança. As duas moram em funções separadas, e misturá-las
é como um desconto comercial vira permissão de acesso.
A permissão é lista de liberação, nunca lista de bloqueio: módulo ausente no mapa do
papel é acesso negado. Recepção fecha comanda e recebe, e não toca em conta a pagar
nem em comissão. Profissional edita a agenda dele, e a regra de quem é o dono do
horário é do servidor, não da tela.
Vem da descoberta 04
Telas A mesma barra lateral, no mesmo plano, em dois papéis
A administradora alcança dezoito itens em cinco grupos, e troca de
unidade pelo seletor do topo.
A recepção vê dez itens, e o grupo Configurações não aparece. O seletor
de unidade está fixo: ela pertence a uma unidade, e o vazio embaixo da lista
mostra que não há porta escondida.
5.3
A marca do cliente é aplicada em tempo de execução
A paleta inteira do produto deriva de três variáveis: o matiz da marca, o
matiz de apoio e um multiplicador de saturação. Trocar as três recalcula todos os
degraus, nos dois temas, sem recompilar nada. Cor escrita à mão em componente
quebraria isso em silêncio, então nenhuma existe: componente consome token, nunca
degrau da rampa.
Isso é o que torna white label uma configuração do cliente e não um projeto por
cliente. A rede que quer o próprio nome na tela do funcionário deixa de ser um
pedido de customização, com prazo e orçamento, e vira um campo no cadastro.
Vem da descoberta 02
Tela A mesma interface, com duas marcas trocadas ao vivo
Em cima a marca padrão, embaixo a mesma tela depois de trocar as três variáveis. As
rampas são recalculadas em oklch, com o croma de cada degrau limitado ao que
cabe em sRGB naquela luminosidade: sem esse limite o navegador aperta a cor por
conta própria, e os degraus deixam de ser uniformes justamente na marca do cliente.
O rótulo da rampa continua dizendo blue e purple nas duas metades
porque ele nomeia o padrão do produto, e não a marca que está aplicada.
5.4
O celular é o aparelho de quem trabalha sozinho
O painel é desenhado a partir de 375px, e não reduzido a partir do desktop. Alvo de
toque de 44 por 44 em tudo que se clica, e a barra de baixo com quatro módulos mais
“Mais”: quem atende sozinho abre o sistema entre um cliente e outro, de pé,
com uma mão.
A navegação inteira sai de uma fonte só. Barra lateral, gaveta e barra de
baixo leem a mesma lista, e é isso que impede o item novo de entrar em dois lugares
e sumir no terceiro, que é o defeito clássico de produto com três formas de menu.
Vem da descoberta 01
Telas O celular de quem opera, e o de quem agenda
Quem opera. A tabela vira cartão, e cada cliente traz as duas ações que
importam no balcão. A observação da ficha aparece aqui, e não atrás de um
clique: alergia é o tipo de informação que não pode depender de alguém lembrar
de abrir.
Quem agenda. A página pública carrega a marca do estabelecimento, não a
da plataforma, e os três cartões são os três eixos da descoberta 01, ditos na
linguagem de quem vai marcar horário.
06 Como saiu do papel
Um repositório só, e o contrato num pacote.
React 19 com Vite e Tailwind no painel e no console, Fastify 5 com Postgres 18 na API,
e 51 rotas hoje. O que atravessa a fronteira entre os dois lados, tipos de domínio,
planos, papéis e o mapa de permissões, vive num pacote importado pelos dois.
Isso não era assim, e a conta apareceu. Painel e API eram dois repositórios, com
o mapa de autorização duplicado e um comentário no topo pedindo para mudar os dois na
mesma sessão. Quando viraram um pacote só, as duas cópias já tinham divergido em
49 linhas. Divergência ali não é detalhe de organização: é o painel mostrando um
botão que a API recusa, ou seja, o usuário clicando em algo que o sistema já decidiu
negar.
O design system também é um pacote, consumido pelo painel e pelo console. O console tem
aparência distinta sem código próprio: ele sobrescreve as mesmas três variáveis de
marca da decisão 5.3.
07 Qualidade e escala
O isolamento entre clientes é do banco.
A lista de clientes de um salão é o ativo dele. Num produto multi-inquilino, a pergunta
que decide a confiança não é se a tela filtra certo: é o que acontece quando alguém
esquece o filtro.
Por isso o recorte por cliente não é do código de aplicação. Ele é do Postgres, com
política por linha e três papéis de banco distintos: o papel com que a API conecta
não é dono das tabelas e não pode ignorar a política. Consulta sem contexto
devolve zero linha, e não a tabela inteira.
Garantia
O erro que ela transforma em nada
Isolamento no banco
rota nova que esqueceu o filtro por cliente. Sem contexto, ela devolve zero linha em vez de vazar a base.
Sessão em cookie, estado no servidor
credencial guardada no navegador, que qualquer script da página consegue ler.
A barreira é a API
confiar no que o painel escondeu. O navegador é da pessoa, e o que vale é o servidor perguntar de novo.
Contraste medido no processo
par de cor que reprova em silêncio, inclusive na paleta que o cliente escolheu para a própria marca.
Nada disso vale como promessa. Um script prova o isolamento contra o banco real,
em 21 verificações: que o papel da API não ignora a política, que a consulta sem
contexto volta vazia, que gravar com o identificador do vizinho é recusado, e que o
contexto não vaza para a próxima consulta que reusar a mesma conexão. O contraste é
medido sobre o CSS de verdade e derruba o processo quando um par exigido reprova.
Toda tela que busca dado tem três estados definidos antes do caminho feliz:
carregando, vazio e erro. O vazio explica o que apareceria ali e oferece a ação que cria
o primeiro item, porque a primeira tela que todo cliente novo vê é justamente a vazia.
O que vem a seguir no produto
A frente de operação, com serviço, profissional e disponibilidade, que é o que
destrava a agenda e o link público de agendamento. Depois dela, os itens de P0 que
esperam a escolha entre a via oficial e a não oficial do WhatsApp, que é o que define
custo por mensagem e se dá para prometer cota generosa.
Quer ver o sistema rodando
As telas desta página são do sistema, e o resto dele também sobe. Demonstração ao
vivo, do painel ao console da plataforma, é conversa de trinta minutos.
