AssistShop
Validar a ideia com usuários resolveu uma parte do problema. A outra continuava em aberto: de onde viriam os preços? Na primeira versão do app, eles dependiam de atualizações feitas pelos próprios usuários. Para funcionar em escala, o AssistShop precisava de uma base de preços que se atualizasse sozinha.
Uma base de preços construída do zero
Construí um sistema que coleta automaticamente os produtos e preços publicados nos sites de supermercados e guarda tudo em um banco de dados próprio. Hoje ele cobre cinco redes: Pão de Açúcar, Carrefour, St. Marche, Mambo e Atacadão. A última coleta completa registrou mais de 50 mil produtos.
Cada site é construído de um jeito diferente, por isso cada mercado exigiu um caminho próprio de coleta. A regra foi a mesma para todos: capturar o máximo possível e saber exatamente o que ficou de fora, e por quê. O projeto tinha ainda uma restrição clara: custo zero, sem ferramentas pagas.
O desafio real: reconhecer o mesmo produto
Coletar os preços foi a parte simples. O difícil foi reconhecer o mesmo produto em mercados diferentes, já que cada rede escreve o nome do seu jeito. Sem isso, não existe comparação.
A solução combina duas camadas. A primeira é o código de barras, que identifica o produto com certeza quando o mercado o publica. A segunda compara o significado dos nomes, para quando o código não está disponível. Por cima delas, criei regras para situações que confundiriam qualquer sistema:
Um pack com 6 unidades não é o mesmo produto que a unidade avulsa.
"Leve 3, pague 2" é promoção do mesmo produto, então o preço é comparado por unidade.
Frutas, verduras e legumes a granel são comparados pelo preço do quilo.
Vinhos da mesma vinícola, mas de linhas diferentes, não se misturam.
Diferenças de preço fora do padrão passaram por revisão manual, com consulta à fonte original quando havia dúvida. Em uma das rodadas, a taxa de comparações corretas subiu de 79% para 89%.
O resultado
Mais de 7.300 produtos encontrados em pelo menos dois mercados, com diferença média de 21,9% entre o lugar mais barato e o mais caro.
Um bot para testar antes do app
Antes de levar esses dados para o app, eu precisava saber se eles funcionavam nas mãos de alguém. Construir telas só para descobrir isso seria caro e lento. Por isso criei um bot no Telegram conectado ao mesmo banco de dados. Escolhi o Telegram por ser mais barato e não exigir um número comercial, como o WhatsApp.
O bot em uso no Telegram
A pessoa escreve a lista de compras do jeito que fala, e o bot responde:
Para um produto, mostra o preço em cada mercado e destaca o mais barato.
Para uma lista, indica o mercado com o menor total. Quando a economia compensa, sugere dividir a compra entre mercados.
Lembra a última lista enviada, então dá para ajustar com um simples "tira o leite".
O que o bot revelou
Usado como teste real, o bot mostrou problemas que nenhum relatório tinha apontado:
As pessoas escrevem "café" com acento, mas a base guardava "CAFE". A busca não encontrava nada.
Quem procurava "manteiga" podia receber uma pipoca sabor manteiga. A relevância da busca importa mais do que a quantidade de mercados que têm o produto.
Um frango orgânico chegou a aparecer como se fosse o mesmo produto de um frango comum.
Produtos vendidos em um único mercado ficavam invisíveis, porque não havia com o que comparar.
Os dois primeiros foram corrigidos no próprio bot. Os outros viraram melhorias planejadas para a base de dados.
Próximos passos
Conectar a base de preços ao app, que está em desenvolvimento em Flutter com um desenvolvedor parceiro.
Definir o servidor que vai guardar usuários, listas e compras.
Tornar a coleta diária e automática quando o app entrar em uso. Hoje ela é feita manualmente.
No bot, criar uma busca guiada por botões para pedidos vagos como "café", ajudando a escolher marca e tipo.
Aceitar listas enviadas por áudio.
O maior aprendizado desta fase: o dado também faz parte da experiência. Uma comparação errada quebra a confiança no app mais rápido do que qualquer problema de interface.
O AssistShop nasceu de uma observação pessoal: ao fazer compras, não havia uma forma prática de saber se o produto da lista seria mais barato em outro estabelecimento próximo. O projeto começou como exercício de produto próprio e evoluiu para um MVP testado com usuários reais ao longo de dois anos.
Decidir onde fazer compras envolve mais variáveis do que preço unitário, mas o usuário não tinha acesso fácil a essa informação no momento em que precisava dela.
Identificação do problema e definição de oportunidade de produto
Pesquisa qualitativa e quantitativa com usuários
Design do fluxo mobile-first do zero
Prototipagem e condução de testes de usabilidade
Iteração baseada em resultados de teste
Descoberta
Entrevistas com usuários para entender o comportamento real de compras antes de qualquer solução. O foco era descobrir a dor principal sem contaminar com hipóteses de produto.
Definição do produto
Escopo mínimo centrado em dois pontos: construção de lista de compras e comparação de preço por item entre estabelecimentos próximos. Tudo fora desse escopo foi descartado na primeira versão.
Prototipagem e testes
Ciclos iterativos de protótipo e teste com usuários. A cada rodada, o que mudava eram os elementos que geravam dúvida ou abandono de tarefa.
Identificação de pontos de atrito
Análise dos pontos de queda no fluxo, com refinamentos específicos para cada um. A maior descoberta foi que o usuário queria confirmar a lista antes de ver os preços.
Lista antes do mapa
O ponto de entrada é a lista de compras, não o mapa de estabelecimentos. Testes mostraram que usuários queriam saber o que precisavam comprar antes de pensar em onde ir.
Mobile-first como restrição de projeto
Decidimos não construir versão web. Isso concentrou o esforço no contexto de uso mais realista: o usuário no supermercado com o celular na mão.
Produto validado com usuários reais
O fluxo principal de criar lista, comparar preços e escolher estabelecimento funcionou sem necessidade de instrução prévia em testes com usuários.
- ✓197 respostas na pesquisa quantitativa validaram frequência e comportamento de compra
- ✓72,6% dos pesquisados usariam um app com comparativo de preços
- ✓Completion rate consistente no fluxo principal após três ciclos de iteração
Produto pessoal tem uma armadilha: o designer também é o usuário, o que cria vieses difíceis de perceber. A pesquisa com pessoas diferentes de mim foi o que mais mudou o produto. O que eu achava óbvio no fluxo não era óbvio para mais ninguém.