Pare de querer construir um aplicativo.

Tallis Gomes queria construir um aplicativo. Só não era o Easy Taxi.

Em junho de 2011, Tallis Gomes chegou ao Startup Weekend no Rio de Janeiro com uma ideia na cabeça: criar um aplicativo relacionado a ônibus e geolocalização.

A ideia não sobreviveu ao primeiro contato com o evento.

Em entrevista ao Mobile Time, Tallis contou que Dave McClure, então fundador da 500 Startups e mentor da competição, apontou que o Google já trabalhava em uma solução semelhante. A equipe precisaria encontrar outro problema para atacar.

Naquela noite, depois das 22h, Tallis tentou voltar para casa de táxi.

Ligou para uma cooperativa. Esperou. O carro não chegou. Ligou novamente e recebeu a informação de que não havia táxi disponível. Saiu para a rua, debaixo de chuva, tentando encontrar um.

Foi aí que uma tecnologia que já estava em sua cabeça encontrou outro problema.

A ideia anterior usava geolocalização para acompanhar ônibus. A pergunta passou a ser outra: por que não usar geolocalização para encontrar o táxi mais próximo?

O próprio Tallis voltou a contar a história anos depois, em artigo publicado pela Exame, descrevendo a origem da Easy Taxi como uma dor pessoal: esperar por um táxi em uma noite de chuva e perceber como aquele processo funcionava mal.

A parte mais interessante dessa história não é que alguém teve uma ideia de aplicativo.

É a ordem em que as coisas aconteceram.

A Easy Taxi não nasceu porque faltava um aplicativo. Nasceu porque pedir um táxi funcionava mal.

O aplicativo veio depois.

O aplicativo foi uma resposta. O problema veio antes.

É fácil olhar para a Easy Taxi depois de pronta e resumir a empresa como “um aplicativo para chamar táxi”.

Mas essa descrição começa pela solução.

O problema era mais simples e mais concreto.

O passageiro queria sair de um lugar e chegar a outro. Havia táxis circulando pela cidade. Mesmo assim, coordenar esses dois lados era lento, incerto e dependia de intermediários que tinham pouca visibilidade sobre onde cada carro estava.

O passageiro ligava, esperava e torcia.

O motorista podia estar relativamente perto sem saber que havia alguém precisando de uma corrida naquela região.

A geolocalização e o smartphone criaram uma forma melhor de aproximar essas duas pontas.

Isso parece óbvio olhando para trás. Em 2011, não era.

E é justamente essa distinção que interessa para qualquer empresa que esteja discutindo tecnologia hoje.

“Quero um aplicativo” já é uma resposta.

Assim como:

• “precisamos de um dashboard”;
• “precisamos trocar de sistema”;
• “precisamos automatizar isso”;
• “precisamos colocar IA no atendimento”;
• “precisamos de uma plataforma para a operação”.

Todas essas frases podem terminar em boas decisões.

Mas nenhuma delas, sozinha, explica o que está funcionando mal.

Quando a conversa começa pela ferramenta, existe um risco silencioso: escolher a forma da solução antes de compreender o problema que deveria justificar sua existência.

A parte mais interessante da Easy Taxi é que nem a solução inicial permaneceu intacta

A história real de um produto raramente segue a linha limpa que aparece depois em uma apresentação.

Problema identificado. Aplicativo construído. Crescimento. Sucesso.

Na prática, a Easy Taxi mudou bastante enquanto tentava descobrir como resolver o mesmo problema.

Na entrevista ao Mobile Time, Tallis relata tentativas de trabalhar com cooperativas, de estruturar um sistema de despacho para frotas e até de fornecer aparelhos aos taxistas. O produto e o modelo foram sendo ajustados conforme a equipe encontrava restrições técnicas, comerciais e operacionais.

O próprio processo de validação começou de forma muito mais simples do que o aplicativo que viria depois.

Em uma publicação sobre o primeiro MVP da Easy Taxi, Tallis mostra que a primeira experiência para o passageiro podia ser apenas uma página simples. Quando alguém fazia uma solicitação, ele recebia os dados, localizava pontos de táxi próximos no Google Maps, ligava para o ponto e retornava ao passageiro com uma previsão.

Ou seja: antes de automatizar toda a operação, havia uma pergunta muito mais importante a responder.

As pessoas realmente queriam uma forma melhor de pedir táxi?

A tecnologia sofisticada podia esperar.

O problema precisava ser validado primeiro.

Quando você começa pela ferramenta, mudar a ferramenta parece fracasso. Quando começa pelo problema, mudar a solução é aprendizado.

Essa diferença de mentalidade é enorme.

Uma equipe apaixonada pela ideia de construir um aplicativo tende a defender o aplicativo.

Uma equipe comprometida em resolver um problema tende a perguntar se ainda existe uma forma melhor de resolvê-lo.

Sentir uma dor não significa automaticamente que existe um negócio

Existe um risco em contar histórias de empreendedorismo depois que conhecemos o final.

A narrativa fica limpa demais.

Uma pessoa enfrenta uma dificuldade, tem uma ideia e constrói uma empresa de sucesso.

Não funciona assim.

Uma dor pessoal pode revelar um problema relevante. Ela não prova que existe mercado, que outras pessoas vivem a mesma situação, que alguém está disposto a mudar de comportamento ou que a tecnologia imaginada consegue produzir uma solução economicamente viável.

A dor é um ótimo lugar para começar a investigação.

Não é autorização para passar meses construindo sem testar nada.

No caso da Easy Taxi, havia inclusive uma restrição enorme para a época: a penetração de smartphones com acesso a dados ainda era muito menor do que hoje. Em relato publicado pelo próprio Tallis, ele afirma que apenas uma pequena parcela da população brasileira possuía smartphone com plano de dados quando o produto começou.

A equipe precisava descobrir não apenas se o problema existia, mas se passageiros e taxistas adotariam aquela nova forma de trabalhar.

Até os testes de tracking foram artesanais. Tallis já contou que chegou a usar bicicletas do Itaú para simular o deslocamento de taxistas enquanto validava a tecnologia de localização. A lógica era simples: testar o comportamento crítico antes de construir uma estrutura maior ao redor dele.

Uma matéria da Exame sobre os primeiros protótipos relata que uma versão inicial foi desenvolvida rapidamente e colocada para teste com dezenas de taxistas e passageiros antes do lançamento mais amplo.

O ponto não é romantizar MVP mal acabado.

É entender a ordem.

Uma dor é um excelente lugar para começar uma investigação. Não é licença para passar seis meses construindo.

Primeiro você procura evidência de que o problema merece ser resolvido.

Depois aumenta o investimento na solução.

“Quero um dashboard” é a versão corporativa de “quero construir um aplicativo”

Dentro de uma empresa, a mesma inversão acontece de forma menos cinematográfica.

Ninguém precisa estar na chuva tentando pegar um táxi.

Ela aparece em uma reunião de segunda-feira:

“A gente precisa de um dashboard.”

A frase pode estar correta.

Mas antes de abrir o Figma, escolher indicadores ou discutir qual ferramenta vai gerar o gráfico, existe uma pergunta melhor:

Para decidir o quê?

Um dashboard não é valioso porque exibe dados.

Ele é valioso quando melhora alguma decisão.

Se a empresa não consegue explicar qual decisão precisa ficar mais rápida, precisa ou visível, existe uma chance razoável de que esteja começando pela tela.

O mesmo vale para um novo sistema.

Uma equipe pode pedir uma nova plataforma porque a atual “é ruim”. Mas o que exatamente está ruim?

A informação demora para chegar?

Duas áreas registram a mesma coisa de formas diferentes?

A equipe copia dados entre ferramentas?

Uma aprovação segura o processo por horas?

O vendedor perde contexto quando outra pessoa assume o atendimento?

O gestor precisa juntar três planilhas antes de conseguir decidir?

A operação depende de alguém experiente lembrar o que fazer em cada exceção?

Agora temos problemas.

E problemas são muito mais úteis do que pedidos de tela.

A mesma lógica aparece quando uma empresa começa pela pergunta “onde podemos colocar IA?”. Já discutimos esse risco em IA não é o ponto de partida. O problema é.: escolher a tecnologia antes de compreender o trabalho inverte a ordem da decisão.

Antes da tela, existem perguntas melhores

Quando alguém pede um aplicativo, sistema, dashboard ou automação, três perguntas ajudam a puxar a conversa de volta para a operação.

O que precisa melhorar de verdade?

Não “o que seria legal ter”.

Não “o que deixaria a empresa mais moderna”.

Não “o que o concorrente acabou de lançar”.

O que precisa mudar de forma observável?

Talvez seja reduzir o tempo entre a chegada de um pedido e sua confirmação.

Talvez seja impedir que estoque vendido continue aparecendo como disponível.

Talvez seja responder leads enquanto ainda existe intenção de compra.

Talvez seja eliminar a conferência manual de informações que já existem em outro sistema.

Talvez seja permitir que um gestor enxergue uma exceção antes que ela vire problema para o cliente.

Quanto mais concreta é a melhoria esperada, mais fácil fica avaliar qualquer solução depois.

Onde o fluxo começa a perder eficiência?

O lugar em que a dor aparece nem sempre é o lugar em que ela nasce.

Um dashboard pode parecer insuficiente porque a informação anterior chega incompleta.

O atendimento pode parecer lento porque o vendedor precisa reconstruir o contexto espalhado por várias ferramentas.

O estoque pode parecer inconsistente porque dois processos diferentes registram a mesma movimentação.

Uma equipe pode pedir automação para acelerar uma etapa que nem deveria existir.

Por isso, olhar apenas para a interface em que o problema fica visível costuma ser pouco.

É preciso acompanhar o fluxo.

Qual decisão hoje ainda depende de improviso?

Essa pergunta é particularmente poderosa porque aproxima tecnologia de comportamento real.

Toda operação possui decisões recorrentes.

Aprovar ou não uma condição.

Priorizar um lead.

Separar um pedido.

Escalar uma exceção.

Repor estoque.

Cobrar um cliente.

Transferir um atendimento.

Quando essas decisões dependem de memória, mensagens soltas, experiência individual ou procura manual por informação, existe um ponto interessante para investigar.

A pergunta deixa de ser “qual dashboard você quer?” e passa a ser:

Que informação essa pessoa precisa ter, naquele momento, para decidir melhor?

Nem todo problema merece software

Uma empresa de tecnologia deveria conseguir dizer isso sem desconforto.

Às vezes, o melhor projeto de software é não construir software.

Um gargalo pode desaparecer ao eliminar uma etapa desnecessária.

Uma ferramenta atual pode já possuir uma configuração que ninguém explorou.

Dois sistemas podem precisar apenas trocar informação.

Uma tarefa previsível pode ser resolvida por uma automação pequena.

Uma regra clara pode substituir uma sequência inteira de confirmações manuais.

Um produto de mercado pode resolver bem o problema sem que a empresa precise assumir o custo de manter outra aplicação.

E alguns problemas simplesmente não custam o suficiente para justificar qualquer projeto.

Essa é uma disciplina importante porque construir possui um efeito psicológico perigoso: depois que tempo, dinheiro e identidade foram investidos em uma solução, fica mais difícil admitir que talvez ela nunca tenha sido necessária.

Já discutimos algo semelhante ao comparar CRM próprio e CRM de mercado: não existe mérito em reconstruir aquilo que o mercado já resolve bem quando não há uma razão operacional concreta para fazer diferente.

A tecnologia precisa pagar pela complexidade que adiciona.

Então quando vale construir alguma coisa?

Não existe uma fórmula universal, mas quatro dimensões ajudam a separar uma irritação pequena de um problema que merece investimento.

Frequência

Quantas vezes isso acontece?

Um atrito de dois minutos pode parecer irrelevante. Repetido centenas de vezes por mês por uma equipe inteira, deixa de ser.

Impacto

Quando acontece, qual é a consequência?

Algumas falhas são raras e ainda assim importam porque afetam receita, risco, experiência do cliente ou continuidade da operação.

Escala

Quantas pessoas, clientes, pedidos ou decisões passam por esse fluxo?

Um processo improvisado pode funcionar enquanto três pessoas conseguem se coordenar por mensagem. Aos poucos, a mesma lógica pode virar uma fila invisível quando a operação cresce.

Particularidade

Existe algo nesse processo que realmente não é bem representado pelas soluções disponíveis?

Essa pergunta evita dois extremos.

De um lado, construir tudo porque “nosso negócio é diferente”.

Do outro, forçar uma particularidade valiosa a caber em uma ferramenta que exige tantos contornos que a equipe passa a operar ao redor dela.

O investimento começa a fazer sentido quando a diferença entre a forma atual de trabalhar e a forma desejada tem valor suficiente para pagar a complexidade da mudança.

Essa mudança pode terminar em software.

Pode terminar em integração.

Pode terminar em automação.

Pode terminar em uma ferramenta já existente.

O diagnóstico vem antes da arquitetura.

Primeiro desenhe a forma correta de trabalhar

Antes de desenhar a tela, existe uma pergunta que costuma produzir respostas melhores:

Como esse processo deveria funcionar se a limitação atual não existisse?

A pergunta é deliberadamente independente de tecnologia.

Imagine que o vendedor não precisasse abrir três sistemas durante uma conversa.

Como deveria ser o atendimento?

Imagine que o gestor não precisasse consolidar uma planilha antes da reunião.

Qual informação ele precisaria receber e quando?

Imagine que o estoque pudesse ser consultado por qualquer canal sobre a mesma fonte.

Como os pedidos deveriam reservar e liberar produtos?

Imagine que uma exceção importante não dependesse de alguém perceber manualmente.

Em que momento ela deveria aparecer e para quem?

Só depois de desenhar essa forma desejada de trabalhar começa a discussão sobre implementação.

É uma sequência simples:

Mapear o fluxo → encontrar o atrito → definir o resultado → escolher a tecnologia.

Não precisa de um nome sofisticado.

É apenas uma maneira de evitar que a ferramenta dite o problema.

A tecnologia certa parece mais óbvia depois que o problema fica claro

A história da Easy Taxi não prova que toda dor pessoal esconde uma grande empresa.

Também não prova que começar pelo problema garante sucesso.

Negócios dependem de execução, mercado, distribuição, timing, capital, concorrência e dezenas de outras variáveis.

O que a história mostra é algo mais simples — e mais útil.

Quando o problema fica claro, fica muito mais fácil julgar se a tecnologia proposta faz sentido.

No caso da Easy Taxi, havia pessoas tentando encontrar táxis, taxistas tentando encontrar passageiros e uma camada de coordenação que funcionava mal. Smartphones e geolocalização abriram uma possibilidade concreta de aproximar essas duas pontas.

Mas até chegar à experiência que ficou conhecida, a solução foi testada, simplificada e modificada várias vezes.

O problema deu direção.

A tecnologia foi tomando forma ao redor dele.

É uma boa disciplina para qualquer projeto.

Pare de querer construir um aplicativo.

Pare, pelo menos, até conseguir explicar o que deveria funcionar melhor quando ele existir.

A tela vem depois.

Primeiro o problema. Depois, a solução.

Tecnologia para operações reais.