Esse é o vigésimo post do blog. Parece a hora de escrever algo diferente — não uma análise detalhada de um recurso, mas um relatório de status honesto sobre onde o produto está, o que foi entregue, o que não foi, e para onde a gente está indo.
O que foi entregue O importador com IA é o destaque. Substituiu um importador rígido de só-Excel que estava no lugar desde as versões mais antigas da plataforma. O importador antigo funcionava só se a planilha do fornecedor batesse exatamente com o layout de coluna esperado — qualquer desvio, qualquer coluna extra, qualquer nome de cabeçalho minimamente diferente, e a importação falhava com erro críptico. O importador com IA aceita PDF, XLSX, XLS e CSV, lida com qualquer layout que o fornecedor usar, e classifica cada linha como match exato, decisão da IA, ou não encontrado. As primeiras importações de clientes reais validaram a aposta central: que um pipeline aumentado por LLM conseguiria lidar com a bagunça dos documentos de fornecedor do mundo real sem exigir que o fornecedor mude o formato.
Junto com o importador, completamos cobertura trilíngue da UI para cada superfície nova. A plataforma agora serve en-US, pt-BR e es-US em todas as páginas — não só nos fluxos principais de cotação e inventário, mas em cada tela de configuração, cada mensagem de erro, cada diálogo de confirmação, e cada template de email. O sistema de tradução roda como infraestrutura de CI: um passo de build verifica que todo arquivo de locale tem toda chave presente na base en-US, e chaves faltando quebram o build. Nunca mais 'essa string só tá em inglês porque a gente esqueceu de adicionar nos outros arquivos.'
O ledger de movimento de estoque foi entregue como peça fundamental do sistema de inventário. Toda mudança de estoque — reserve, release, ship, return, receive, adjustment — é registrada como movimento tipado com delta com sinal, FK de documento fonte, timestamp, e o usuário que iniciou. O ledger é append-only: linhas nunca são editadas, nunca deletadas. O cache guarda o saldo corrente; o ledger é o registro durável. Qualquer equipe pode auditar o histórico completo de qualquer produto em qualquer local sem pedir para engenharia rodar query.
Três documentos de fulfillment — DeliveryNote, ReturnNote e StockReceipt — agora compartilham um fluxo único de posting. Postar uma entrega move estoque de reservado para expedido. Postar uma devolução move de expedido de volta para disponível. Postar um recebimento registra inventário entrando de fornecedor. Todos os três criam movimentos de estoque com o ID do documento na FK fonte, todos os três atualizam o mesmo cache, e todos os três respeitam as mesmas fronteiras de permissão. O fluxo compartilhado significa que equipes de almoxarifado aprendem um padrão, não três.
A matriz de permissão se sustentou. Quatro grupos — admin, manager, commercial, warehouse — com matriz documentada mostrando quem faz CRUD em quê. Sem overrides por tenant, sem ACL por usuário, sem classes de permissão customizadas espalhadas por views. Novas features começam adicionando uma linha na matriz, depois ligando o check. A simplicidade é a feature: quando um cliente pergunta 'quem pode aprovar uma devolução?' a resposta está numa tabela markdown, não espalhada em seis arquivos.
O blog que você está lendo foi lançado junto com o redesign do site de marketing. Vinte posts cobrindo as decisões técnicas por trás do produto — não cópia de marketing, mas explicações honestas de por que a plataforma funciona do jeito que funciona. O blog é superfície de SEO e também sinal de credibilidade técnica: um cliente potencial que lê três posts sabe mais sobre como o Quotery lida com inventário do que aprenderia em uma dúzia de demos de concorrentes.
O que não foi entregue A gente queria entregar um módulo de relatórios — dashboards com tendências de venda, giro de inventário, taxas de conversão de cotação. Não aconteceu. O importador consumiu mais tempo de engenharia do que o planejado, e a gente fez a escolha deliberada de entregar uma coisa bem em vez de duas coisas pela metade. O modelo de dados de relatório está projetado e as queries estão escritas; a peça faltando é a superfície de frontend. É a prioridade máxima para o próximo ciclo.
Integrações contábeis continuam no roadmap. A plataforma pode exportar dados em formatos que ferramentas contábeis consomem, mas não tem integração direta de API com nenhum pacote contábil. Isso é em parte técnico — APIs contábeis são notoriamente inconsistentes — e em parte escolha de sequenciamento: integrar com uma ferramenta que você ainda não usa diariamente é prematuro. Agora que os fluxos principais estão sólidos e clientes estão no ar, integrações se tornam a próxima camada natural.
Otimização mobile para fluxos de almoxarifado é parcial. A plataforma é responsiva e funciona no celular, mas a experiência de almoxarifado — escanear, separar, postar entregas — foi projetada para navegador desktop. Uma visão mobile-first dedicada para almoxarifado, otimizada para leitura de código de barras e operação com uma mão, é o terceiro item principal no roadmap.
O que vem O módulo de relatórios vem primeiro. O objetivo não é um dashboard genérico de analytics com uma dúzia de widgets que ninguém usa. São três visões focadas: performance de vendas (volume de cotação, taxa de conversão, receita por cliente e produto), saúde de inventário (giro, estoque parado, frequência de ruptura), e atividade da equipe (cotações criadas, entregas postadas, devoluções processadas por usuário). Cada visão tem um gráfico principal, uma tabela resumo, e um botão de exportar. O princípio de design é o mesmo que a gente aplicou no importador: responda a pergunta mais importante primeiro, depois saia do caminho.
Integrações contábeis vêm depois. A gente está avaliando com qual pacote integrar primeiro baseado em demanda de cliente e qualidade de API. A integração vai ser unidirecional no começo — Quotery empurra faturas e avaliações de estoque para o sistema contábil, mas não puxa dados de volta. Sincronização bidirecional é um problema mais difícil (resolução de conflito, ownership de dado, reconciliação) e a gente prefere entregar uma integração unidirecional confiável do que uma bidirecional não confiável.
A visão mobile de almoxarifado é o terceiro item principal. Não é um app mobile — é uma visão web responsiva otimizada para a ergonomia específica de trabalho de almoxarifado. Alvos de toque grandes para mãos com luva, leitura de código de barras pela câmera do dispositivo, navegação de um dedão, e posting tolerante a offline (enfileira o post, sincroniza quando a conectividade voltar). A visão desktop de almoxarifado continua para trabalho de back-office; a visão mobile é para gente em pé.
Além dos três grandes, tem uma cauda longa de polimento. Restauração de posição de scroll na navegação. Atalhos de teclado para usuários avançados — fechar cotação, postar entrega, aprovar devolução, tudo do teclado. Mensagens de erro melhores em edge cases que são difíceis de atingir mas confusos quando acontecem. Esqueletos de carregamento que batem com a forma do conteúdo que estão substituindo. Esses não são itens de roadmap com prazo; são trabalho contínuo que acontece entre features. Os detalhes silenciosos que separam software que você tolera de software em que você confia.
O que a gente aprendeu A maior lição do ano: features de IA têm sucesso ou falham na UX de revisão, não na acurácia do modelo. O LLM no nosso importador é bom — classifica mais ou menos 90% das linhas que tenta corretamente. Mas se confirmar esses 90% parecesse trabalho, a feature teria falhado. A UI de revisão — comparação inline, confirmação de um toque, hierarquia visual clara — é o que torna a acurácia usável. Um modelo 95% acurado com experiência de revisão ruim é pior que um modelo 85% acurado com uma boa, porque o usuário passa mais tempo lutando com a UI do que corrigindo o modelo.
A segunda lição: modelos de dado append-only valem a complexidade inicial. O ledger de movimento de estoque levou mais tempo para projetar e implementar do que uma abordagem simples de saldo corrente teria levado. Mas toda pergunta de auditoria, toda investigação de discrepância, todo 'por que esse número estava diferente terça passada?' é respondível com query em vez de chute. O ledger já se pagou em sessões de debugging evitadas e respostas confiantes para perguntas de cliente.
A terceira lição: suporte trilíngue não é três vezes o trabalho. Uma vez que a infraestrutura de tradução está no lugar — lookups por chave, enforcement de CI, formatação com locale para datas e números — adicionar uma terceira língua é majoritariamente trabalho de tradução, não de engenharia. A primeira língua depois do inglês exigiu construir a infraestrutura. A terceira exigiu escrever strings em espanhol. O custo marginal cai drasticamente.
Um obrigado Para as equipes iniciais que empurraram PDFs reais de fornecedor pelo importador e disseram exatamente o que quebrou: obrigado. A disposição de vocês de testar uma ferramenta nova com documentos reais — não dados de teste, não amostras sanitizadas, mas os PDFs bagunçados de verdade que os fornecedores de vocês mandam — é o que tornou o importador bom. Todo edge case que a gente lida hoje (o PDF com senha, o scan só de imagem, o fornecedor que usa seis formatos de SKU diferentes na mesma página) existe porque alguém bateu nele e nos contou.
Para todo mundo que leu esses posts do blog e mandou feedback: obrigado. Escrever sobre decisões técnicas em público é uma função forçante para clareza. Vários posts nessa série começaram como notas para mim mesmo e viraram explicações que a gente agora usa em conversas de venda e sessões de onboarding. O blog virou um ativo que a gente não antecipou.
Tem muito mais para construir. O módulo de relatórios, as integrações contábeis, a visão mobile de almoxarifado, e o polimento silencioso que faz tudo parecer um pouco mais sólido. Mas a fundação é real: o importador funciona, o ledger é append-only, as permissões são simples, e as traduções estão completas. O ano três começa de um lugar bom.