A Holofante começou com uma restrição prática: fazer um laboratório de R&D crescer sem contratar uma camada administrativa. As propostas, contratos, cobranças, aprovações e status de entrega ficavam espalhados entre conversas e ferramentas. Cada projeto novo criava mais trabalho de coordenação.[1]
A resposta foi tratar a operação como produto. O sistema conectou o ciclo quote-to-cash a um estado compartilhado de projeto, para que cliente e estúdio soubessem o que aconteceu, o que estava bloqueado e qual ação vinha a seguir.
DesignOps como infraestrutura
A primeira decisão foi construir um framework de componentes multiestado, em vez de telas específicas para cada projeto. A mesma interface podia representar um projeto pausado, uma ação do cliente, uma aprovação, um erro ou um fallback offline. Isso trouxe consistência aos oito marcos do projeto e reduziu o custo de criar novos fluxos.
A segunda decisão foi renderizar a interface a partir dos estados. Proposta, contrato, pagamento e entrega determinavam qual componente e qual ação apareciam. Um contrato assinado podia liberar a próxima etapa sem outra página ou atualização manual.
Automação com fronteiras
O Notion virou fonte da verdade dos projetos, enquanto funções serverless em Node.js conectavam registros a pagamentos, assinaturas, notificações e visões para clientes. UUIDs e campos sensíveis criptografados mantinham valores fora de URLs públicas previsíveis.
O sistema foi construído dentro do ecossistema JavaScript existente e em paralelo ao atendimento de clientes. Essa restrição favoreceu automações pequenas e composáveis, em vez de uma reescrita completa da plataforma.
O Holofante aumentou o MRR em 340%, recuperou mais de dez horas por semana e suportou doze projetos simultâneos. O resultado não foi apenas administrar mais rápido: foi dar a um negócio de serviços um modelo operacional repetível, no qual design, engenharia e operação compartilham os mesmos estados.
Projeto solo: Lio Schimanko foi a única pessoa envolvida e atuou como solo founder. ↩︎
