Toneladas de ingrediente chegavam por dia. Cada entrada era digitada numa planilha e depois limpa antes de o número servir. Subestimou, a cozinha fica sem; superestimou, vai para o lixo. O time gastava boa parte do tempo na etapa de tratamento, não na decisão que ela deveria informar.
Pesou uma vez, o estoque está certo
Uma empresa de cozinhas de delivery trocou linhas de planilha digitadas à mão, um app de coleta que deixava o tratamento manual e o fechamento de números no fim do ciclo por um sistema de estoque alimentado direto pela balança.
Uma empresa de cozinhas de delivery que compra em peso e vende em unidade.
Toneladas de ingrediente entram todo dia; cada um é pesado, armazenado, preparado e vira um bowl que precisa sair no mesmo dia. Ingrediente estraga, entrega chega faltando, uma contagem erra por uma caixa.
Dark kitchens, comida fresca
2016Fundada
2.000Saladas por dia, na época do case (2022)
160Pessoas no time, na época do case
2022Rodada de R$ 30 milhões, para abrir mais cozinhas e o primeiro restaurante
350.000+Saladas entregues no anoDado publicado pela própria Olga Ri no cabeçalho do case. O ano não aparece no texto; o case foi publicado em 2022. É porte da empresa, não resultado do sistema.
2.000Saladas por diaMesma fonte, mesma data. Descreve a operação para a qual o sistema foi construído, e nada na fonte o atribui ao sistema.
160Pessoas no timeMesma fonte, mesma data. A imprensa de negócios no mesmo ano falou em quase 200, então o número é tratado aqui como aproximado.
5Dark kitchens em operaçãoBrazil Journal e Exame, 2022, na cobertura da rodada daquele ano. É porte da empresa, não resultado do sistema.
“Em estoque, certo e quase certo são mundos diferentes. Produto estraga, entrega pode não chegar. Saber o número certo é o que mantém a operação inteira nos trilhos. Para mim, usar o Jestor e outros softwares é exatamente isso: a diferença entre certo e quase certo.”
Diogo KudoPlanejamento e Controle de Produção, no case publicado em 2022
AntesDepois
- Uma linha de planilha digitada por entrega recebidaA balança envia o peso pela API e o sistema atualiza o estoque
- Limpeza e tratamento manual de cada númeroO sistema trata o dado que chega antes de ele entrar no estoque
- Extração e importação repetidas a cada relatórioEstoque por item por cozinha, com histórico, num lugar só
- Painéis montados sobre dado periódicoVisões montadas sobre o número de estoque vivo
- App só de coleta para saída de estoqueUm app dedicado para lançamentos manuais, em que o lançamento dispara as automações seguintes
- Contagem física anotada e conciliada à mãoApp de contagem diária: lista de itens, digitação no celular, comparação automática entre teórico e real
- Estimativa de compra sobre número vencidoEstimativa sobre estoque atual e histórico por cozinha
As balanças ficaram. As cozinhas e a contagem física diária ficaram. Canais de pedido e frota de entrega não fizeram parte dessa construção. O case descreve o sistema como o centro do processo de estoque, coletando e enviando dado para outros softwares quando preciso; não afirma ter substituído esses outros softwares.
O gargalo era operacional, não comercial
A Olga Ri prepara e entrega saladas e bowls a partir de dark kitchens, vendendo por app e site próprios e pelos marketplaces de delivery, com frota própria de motoboys. A empresa nasceu em 2016 em São Paulo como Casa Buon Gusto, virou Olga Ri em 2020 e recebeu o primeiro aporte da Kaszek em 2019. Na época deste case, publicava 2.000 saladas por dia, mais de 350 mil no ano e 160 pessoas no time. Em 2022 levantou R$ 30 milhões, com a Kaszek de novo à frente, para abrir mais cozinhas e o primeiro restaurante físico, inaugurado perto da Paulista em 2023; naquele ano operava cinco dark kitchens, fazia cerca de 40 mil pedidos por mês e tinha faturado R$ 21 milhões em 2021.
Cozinha de comida fresca compra em peso e vende em unidade. Toneladas de ingrediente entram todo dia; cada um é pesado, armazenado, preparado e vira um bowl que precisa sair no mesmo dia. Ingrediente estraga, entrega chega faltando, uma contagem erra por uma caixa. O plano de compra de amanhã é tão bom quanto o número de estoque de hoje, e em hortifrúti a diferença entre "está acabando" e "acabou" são algumas horas.
Por isso o gargalo era operacional, não comercial. Demanda havia e crescia. O que faltava ao time era um número de estoque em que pudesse confiar sem gastar o dia montando. A pesagem já acontecia; o número só não chegava ao sistema sozinho.
“Mesmo sendo uma startup, fica a impressão de que o único caminho é construir algo do zero. O Jestor nos deu uma alternativa que não só pareceu mais natural como foi realmente o único jeito de chegar rápido onde queríamos.”
O evento físico era instantâneo e o evento de dado era em lote
“Em estoque, certo e quase certo são mundos diferentes. Produto estraga, entrega pode não chegar. Saber o número certo é o que mantém a operação inteira nos trilhos. Para mim, usar o Jestor e outros softwares é exatamente isso: a diferença entre certo e quase certo.”
Relatórios e painéis eram montados sobre dado já envelhecido. A linha entre "está acabando" e "acabou" era mais borrada do que o time podia bancar.
O time tinha montado um app pequeno num construtor baseado em planilha para registrar saída de estoque. Anotar ficou mais fácil. Tudo depois, extrair, importar, tratar, continuou tão manual e tão lento quanto antes. Um ERP tradicional foi avaliado e deixado de lado: imporia um formato sem resolver esse problema específico.
O padrão: o evento físico (uma caixa na balança) era instantâneo, o evento de dado era em lote, e uma planilha ficava no meio. Nada estava quebrado a ponto de parar a cozinha. Tudo estava lento a ponto de limitar até onde ela cresceria sem contratar gente para digitar.
Item a item, o que fazia cada trabalho antes e o que faz hoje
| O que fazia isso antes | O que faz hoje |
|---|---|
| Uma linha de planilha digitada por entrega recebida | A balança envia o peso pela API; o sistema registra e atualiza o estoque |
| Limpeza e tratamento manual de cada número | O sistema trata o dado que chega antes de ele entrar no estoque |
| Extração e importação repetidas a cada relatório | Estoque por item por cozinha, com histórico, num lugar só, lido direto |
| Painéis montados sobre dado periódico | Visões montadas sobre o número de estoque vivo |
| App só de coleta para saída de estoque | Um app dedicado para lançamentos manuais, em que o lançamento dispara as automações seguintes |
| Contagem física anotada e conciliada à mão | App de contagem diária: lista do que contar, digitação no celular, comparação automática entre teórico e real |
| Estimativa de compra sobre número vencido | Estimativa sobre estoque atual e histórico por cozinha |
O que não foi trocado. As balanças ficaram. As cozinhas e a contagem física diária ficaram. Canais de pedido e frota de entrega não fizeram parte dessa construção. O case descreve o sistema como o centro do processo de estoque, coletando e enviando dado para outros softwares quando preciso; não afirma ter substituído esses outros softwares. Nenhum sistema financeiro ou contábil é nomeado na fonte, então nada é afirmado sobre um.
A cadeia, ponta a ponta
- 1A compra chega e vai para a balançaPessoa
Chega à cozinha e alguém coloca na balança.
- 2A balança envia o peso pela APIAutomático
A API aberta é a única integração em que o fluxo se apoia.
- 3O sistema trata a leitura e atualiza o estoqueAutomático
Daquele item, naquela cozinha, no momento da pesagem.
- 4O app de contagem entrega a listaAutomático
Quem está no estoque recebe a lista do que contar naquele dia.
- 5A pessoa conta e digita a quantidade realPessoa
No celular, na hora, sem papel no meio.
- 6O sistema compara teórico com contadoAutomático
Aponta a diferença, que diz algo sobre eficiência e condição de armazenagem.
- 7O planejamento dimensiona a próxima compraPessoa
Estoque e histórico por cozinha são revisados e o pedido é definido.
- 8O fornecedor entrega, e a caixa volta para a balançaExterno
Fora do sistema, no ritmo que os fornecedores já mantêm.
Os elos difíceis são o 1 e o 5. O sistema não sabe que a caixa existe até alguém colocar na balança, e não sabe que o número teórico está errado até alguém contar. O desenho não finge o contrário. Ele faz das duas ações a versão mais barata possível delas: pesar uma vez, sem nada para anotar; contar a partir de uma lista, no celular, com a comparação feita para você.
“Agora é só pesar o produto e o estoque atualiza sozinho. Não ter que anotar cada quantidade entre uma pesagem e outra deixa tudo dez vezes mais rápido e não sobra margem para erro.”
Cada mudança, com a base ao lado
| Indicador | Resultado | De onde sai |
|---|---|---|
| Atualização de estoque no recebimento | De linha de planilha digitada e tratada para atualização automática pela balança | Case publicado, seções "Antes" e "Depois" |
| Latência do dado | De dado periódico e painel virado para o passado para estoque atualizado no momento da pesagem | Case publicado; nenhuma latência foi medida |
| Esforço de relatório | De extração e importação repetidas para leitura de estoque e histórico por cozinha num lugar só | Case publicado |
| Contagem física | De contagem anotada e conciliada à mão para lista, digitação no celular e comparação automática teórico versus real | Case publicado |
| Tempo em tratamento de dado | Descrito pelo time como tempo que hoje vai para planejamento em vez de escrituração | Case publicado; o "dez vezes mais rápido" do estoquista é estimativa dele numa citação, não medição |
Nenhum número medido de tempo, custo ou perda existe na fonte. O case descreve as rotinas trocadas e cita o time sobre o efeito. Não reporta horas por semana antes e depois, taxa de perda, frequência de ruptura ou acurácia de compra. A única afirmação numérica, "dez vezes mais rápido", vem de um entrevistado descrevendo a própria rotina e é reportada aqui como tal.
"Automático" começa na balança, não antes dela. A leitura da balança é automática. Colocar a caixa na balança é uma pessoa. A precisão do sistema é exatamente a disciplina da etapa de pesagem mais a contagem diária que pega o que a pesagem deixou passar.
Os números de porte não são resultado. Saladas por dia, saladas por ano e tamanho do time descrevem a operação para a qual o sistema foi construído. Nada na fonte atribui nenhum deles ao sistema, e este case também não.
O que este case não mede
Vale dizer, porque é o que normalmente aparece inflado.
Toda descrição do antes e do depois e todas as citações vêm da equipe da Olga Ri conforme publicado. Nenhum processo foi observado ou cronometrado de forma independente.
Horas por semana em estoque, perda como percentual da compra, rupturas por mês, erro de previsão de compra: nada disso aparece antes ou depois. São os números que um comprador quer, e não foram medidos.
Descreve a experiência de uma pessoa em uma tarefa, pesar sem anotar. Não é medição de vazão e não é usada como tal.
O case foi publicado em abril de 2022. Desde então a empresa levantou nova rodada, abriu mais cozinhas e o primeiro restaurante. Não sabemos se o sistema descrito aqui roda sem alteração hoje.
O case diz 160 pessoas; a Exame, em agosto de 2022, falou em quase 200. Provavelmente medidos em momentos diferentes; nenhum dos dois é verificado aqui.
A fonte diz que um ERP tradicional foi avaliado e não adotado para esse problema. Não diz o que a empresa usa no financeiro, então este case também não diz.
A fala do fundador no case original inclui um julgamento genérico sobre ERPs tradicionais e software houses. Essa frase foi removida; as partes que descrevem a situação da empresa e a escolha dela foram mantidas.
Food service é a maior fonte de desperdício fora de casa
| Indicador | Número | Fonte |
|---|---|---|
| Faturamento da alimentação fora do lar no Brasil em 2025 | R$ 495 bilhões, contra R$ 455 bilhões em 2024 | Abrasel, citada por imprensa econômica em março de 2026 |
| Empresas no setor de food service no Brasil | Cerca de 1,35 milhão | Abrasel, janeiro de 2025 |
| Alimento desperdiçado no varejo, no food service e nos lares, mundo, 2022 | 1,05 bilhão de toneladas, cerca de 19% do alimento disponível ao consumidor | UNEP, Food Waste Index Report 2024, março de 2024 |
| Parcela desse desperdício gerada pelo food service | 28%, cerca de 290 milhões de toneladas | UNEP, Food Waste Index Report 2024 |
| Perda de frutas e hortaliças entre colheita e varejo, mundo | 25,4% em 2023, o maior índice entre todos os grupos de alimento | FAO, portal de dados do indicador ODS 12.3.1, atualizado em junho de 2026 |
Mais de um quarto do desperdício no nível do consumidor acontece no food service. Uma cozinha cujo insumo principal é hortifrúti, o grupo com a maior taxa de perda da cadeia, está exposta nas duas pontas: pode perder produto antes de cozinhar e depois.
Comprar contra uma contagem vencida significa comprar demais de insumo perecível ou faltar e substituir. O sistema deste case não mexe em cadeia de frio nem em vida útil; mexe no número de onde a decisão de compra parte. É a parte do desperdício que é de informação, não física, e é a parte que uma construção de software consegue mover.
"Um terço de toda a comida" descende de uma estimativa de 2011 que a FAO substituiu por duas medidas separadas: perda antes do varejo (cerca de 13%) e desperdício do varejo em diante (cerca de 19%). A manchete velha continua em todo lugar. Quem opera cozinha deve usar a fatia do food service no índice atual, não o número de 2011.
O sistema é feito sob medida e a responsabilidade por ele continua nossa
A Olga Ri já tinha tentado os dois caminhos óbvios. Um app de coleta empurrou o problema para frente. Um ERP tradicional resolveria dentro de um formato com o qual a cozinha teria que conviver. A pergunta que um sistema sob medida precisa responder é o que acontece no ano dois: um app de estoque que ninguém pode mexer vira a nova planilha em três anos, com login.
Um construtor toca cada pedido do começo ao fim, com um sempre em execução.
Um novo fluxo, uma nova automação ou um novo relatório entram pelo mesmo canal, sem virar projeto novo.
Se o que foi construído não está bom, ele é refeito. Revisões ilimitadas dentro da assinatura.
Assento nunca é a régua de cobrança, o que importa quando planejamento, cozinha, estoquistas e compras tocam a mesma operação.
As pessoas aprendem a usar o app delas como aprendem qualquer app, abrindo. Construir, configurar e manter continua do nosso lado.
Exportação completa a qualquer momento, por CSV e API. Conformidade SOC 2, sem taxa de saída. Dá para pausar em um clique e os sistemas continuam rodando.
Metodologia e fontes
As descrições de antes e depois e as três citações vêm do case que o Jestor publicou em abril de 2022, escrito a partir de entrevistas com a equipe. São o relato da própria equipe e não foram auditadas. A citação do fundador foi encurtada para remover um julgamento genérico sobre outras categorias de software.
Saladas por dia, saladas por ano e tamanho do time: cabeçalho do case publicado, sem data no texto, tratados como da época da publicação. Fundação em 2016, rebranding em 2020, primeiro aporte da Kaszek em 2019, rodada de R$ 30 milhões em 2022, cinco dark kitchens, 40 mil pedidos por mês, R$ 21 milhões de faturamento em 2021 e restaurante em 2023: Brazil Journal (fevereiro de 2020 e 2022), Exame (agosto de 2022), Projeto Draft (fevereiro de 2023) e ArchDaily (2023).
Abrasel, conforme citada por imprensa econômica em março de 2026 e janeiro de 2025. UNEP, Food Waste Index Report 2024 (março de 2024). FAO, portal de dados do indicador ODS 12.3.1 (atualizado em junho de 2026).
Nenhum tempo economizado, perda reduzida, ruptura evitada ou acurácia de compra é afirmado como resultado, porque nada disso foi medido na fonte. A estimativa "dez vezes mais rápido" aparece só como citação, rotulada como estimativa.