Marketplace de dois lados: o que construir primeiro (e o que improvisar)
Um fundador me apresentou a ideia dele num café na primavera passada. “É o Airbnb das cozinhas comerciais”, disse. Restaurantes com cozinha ociosa de um lado, empreendedores de comida que precisam de uma cozinha licenciada do outro. Ele tinha a oferta encaminhada, um mock-up de designer e um orçamento de uma software house. O que ele não tinha era resposta para a única pergunta que importava: no dia do lançamento, com zero cozinhas cadastradas e zero cozinheiros inscritos, o que alguém vê ao abrir o app?
Tinham vendido a ele a construção. Ninguém tinha falado do problema que a construção não resolve.
Um marketplace de dois lados é uma plataforma cujo valor vem de conectar dois grupos distintos que precisam um do outro, um ofertando algo e o outro demandando, em que o trabalho do produto é justamente fazer o match e ficar com uma parte da transação. O Airbnb conecta anfitriões e hóspedes. A Uber conecta motoristas e passageiros. A Etsy conecta criadores e compradores. O fundador não constrói nem a oferta nem a demanda. Ele constrói a máquina no meio e ganha uma taxa toda vez que ela funciona.
Essa definição soa simples, e esconde as duas coisas que afundam a maioria dos fundadores de marketplace. A primeira: você não está construindo um produto só. A segunda: o software é a parte fácil.
O que é, de fato, um marketplace de dois lados
“O Uber das X” é um ótimo pitch e uma péssima especificação. Ele comprime três produtos separados numa palavra familiar e faz o fundador achar que está construindo um app. Ele está construindo três coisas.
Existe o produto do lado da oferta: como o dono de uma cozinha cadastra o espaço, define disponibilidade, precifica e recebe. Existe o produto do lado da demanda: como o cozinheiro busca, compara, reserva e paga. E existe o motor de matching no meio: a lógica que decide quais cozinhas um determinado cozinheiro vê, em que ordem, filtradas por quê, ranqueadas por quê. Os dois lados quase não dividem tela. A experiência de um anfitrião no Airbnb e a de um hóspede no Airbnb são softwares quase totalmente diferentes que por acaso vivem atrás do mesmo logo.
É por isso que um marketplace custa mais para construir do que um produto único e por isso ele é a forma errada para um MVP no sentido usual. Você não consegue lançar meio marketplace. Um fluxo de reserva sem nada para reservar é uma demo, não um produto. Os dois lados têm que existir, ao menos em esqueleto, antes que alguém consiga usar a coisa uma vez sequer.
O único problema que realmente mata marketplaces
Aqui está a parte que tanto os livros de economia quanto as páginas de venda das plataformas pulam. Um marketplace vazio não vale nada para ninguém. Nenhum cozinheiro entra num app de aluguel de cozinha sem cozinhas. Nenhum dono de cozinha cadastra espaço num app sem cozinheiros. Cada lado está esperando o outro, e o fundador está parado no meio com um produto lindamente construído que não faz nada.
Esse é o problema do cold start, e é a causa mais confiável de morte de marketplace que existe. Andrew Chen, que passou anos cuidando de crescimento na Uber, escreveu um livro inteiro sobre isso por um motivo: a maioria dos marketplaces nunca chega ao ponto em que os dois lados aparecem sozinhos. A tecnologia nunca foi o gargalo. A liquidez foi, aquela condição simples em que um comprador que chega encontra de forma confiável um vendedor, e vice-versa.
A regra que decorre disso não é intuitiva para quem acabou de pagar por um produto de dois lados: não lance com os dois lados. Escolha o lado mais difícil, normalmente a oferta, e construa-o primeiro, na unha se for preciso, até existir massa suficiente para o outro lado ter motivo de aparecer. Os fundadores do Airbnb fotografaram os anúncios eles mesmos. O DoorDash começou como uma página estática com alguns cardápios locais e um telefone que tocava na casa dos fundadores. O marketplace veio depois. A correria manual veio antes.
Se uma software house te orça um marketplace e nunca menciona liquidez ou cold start, ela está te vendendo a metade fácil e te deixando descobrir a metade difícil sozinho.
Exemplos que ensinam a lição de verdade
Sim, a Etsy é um marketplace de dois lados (criadores e compradores). Sim, o Zillow é um, ainda que mais bagunçado, já que conecta compradores, vendedores, corretores e os próprios produtos de dados, o que o aproxima de uma plataforma de múltiplos lados. Os exemplos úteis não são os logos famosos, no entanto. São os lançamentos.
A lição em todo marketplace que deu certo é que ele achou um jeito de ser útil para um lado antes de o outro existir. Alguns tinham um “modo single-player”: uma ferramenta que ajudava o lado da oferta mesmo com demanda zero. O OpenTable deu aos restaurantes um software de gestão de reservas que eles queriam de qualquer forma, e depois transformou essa base instalada no lado da oferta de um marketplace voltado para quem janta. O software se pagou em um lado primeiro. A rede veio como segundo ato.
Para um fundador, a pergunta que vem disso não é “qual é o meu Uber das X”. É “o que posso entregar a um lado que seja valioso mesmo enquanto o outro lado está vazio”. Se você não consegue responder, não tem um plano de cold start, e um marketplace sem plano de cold start é um jeito muito caro de aprender sobre liquidez.
Que software um marketplace realmente precisa
Tire o romantismo e um marketplace são quatro sistemas. Nomeá-los deixa você especificar uma construção em vez de apontar para a Uber.
Duas superfícies de cadastro e listagem, uma por lado. A oferta precisa criar e gerenciar o que está oferecendo; a demanda precisa criar uma conta e dizer o que quer. Em grande parte são padrão. Muitos marketplaces começam por aqui no no-code.
Uma camada de descoberta e matching. Isso é busca, filtro, ranqueamento e as regras que decidem quem vê quem. É também onde o seu produto de verdade mora. A diferença entre um marketplace que parece mágico e um que parece uma planilha está quase toda no matching, e é a única parte específica do seu negócio.
Uma camada de confiança. Avaliações, verificação, resolução de disputas e o que quer que a sua categoria precise para deixar um estranho confortável em transacionar com outro estranho. Num app de aluguel de cozinha, isso pode ser checagem de licença e seguro. Num app de babá, é checagem de antecedentes. Confiança não é uma funcionalidade que você adiciona depois; em muitas categorias, ela é o produto.
Pagamentos, e quase sempre custódia. O marketplace recebe dinheiro de um lado, segura e repassa para o outro depois da transação, descontando a sua parte. Isso é mais complexo que um checkout normal porque você está movendo dinheiro entre dois usuários, em geral com um intervalo e uma janela de disputa. Stripe e outros oferecem os blocos para isso, mas a política, quem recebe quando, o que acontece num cancelamento, é sua para decidir.
Repare no padrão: dois dos quatro sistemas são em grande parte genéricos, e dois deles, matching e confiança, são onde mora a sua defensibilidade. Isso tem consequência direta na próxima decisão.
Construir, alugar uma plataforma ou ir para o custom
Você tem três opções honestas, e a certa depende inteiramente de quão padrão precisam ser o seu matching e a sua confiança.
Uma plataforma de marketplace como a Sharetribe ou ferramenta parecida te entrega um marketplace de dois lados funcionando rápido, com listagens, busca e pagamentos prontos. É o equivalente, no mundo dos marketplaces, a construir em cima de um produto white label: excelente para validar que os dois lados vão de fato aparecer, e limitado no instante em que a sua lógica de matching ou de confiança precisa ser fora do padrão. Se o seu marketplace é “Airbnb, mas para um nicho” com busca convencional e avaliações convencionais, uma plataforma pode te levar mais longe do que os fundadores esperam.
Uma construção em no-code ou low-code fica no meio e funciona pelo mesmo motivo que a plataforma, até o motor de matching de que você realmente precisa brigar com a ferramenta que você escolheu.
Uma construção custom é a escolha certa quando o matching ou a camada de confiança são a sua vantagem, quando aquilo que torna o seu marketplace melhor que o incumbente óbvio é especificamente como você conecta os dois lados ou como faz eles confiarem um no outro. Você não vai para o custom para economizar. Vai para o custom para ser dono da única parte que não pode alugar.
O erro caro é ir para o custom nos 80% genéricos e tratar a lógica de matching como detalhe. Já vimos fundadores gastarem o orçamento reconstruindo formulários de cadastro e barras de busca que uma plataforma dá de graça, e ficarem sem dinheiro antes de chegar no matching que era para ser o ponto inteiro.
O que construir primeiro, e o que improvisar
Comece pelo lado que você vai ter que arrastar para a existência, e construa o mínimo de software que permite atendê-lo na mão. Um fundador validando um marketplace não precisa de um motor de matching automático no primeiro dia. Ele precisa de uma primeira versão que prove que os dois lados vão transacionar, e o matching pode ser um humano, com frequência o próprio fundador, lendo as duas listas e fazendo a conexão por e-mail.
Essa é a abordagem concierge, e para marketplaces não é um atalho, é a primeira construção correta. O matching manual te ensina as regras de matching que você vai um dia automatizar, as regras que software house nenhuma consegue adivinhar por você. Você descobre que cozinheiros se importam mais com metragem do que com localização, ou o contrário, fazendo isso na mão cinquenta vezes. Aí você constrói o motor que codifica o que aprendeu, e o constrói custom, porque a essa altura você já sabe que é a parte que vale possuir. (É a mesma lógica de construir ou comprar que se aplica a qualquer decisão de software, parecida com a do micro SaaS, afiada pelo fato de o marketplace ter um núcleo genérico óbvio e um centro defensável estreito.)
O fundador das cozinhas comerciais voltou à software house e mudou a ordem. Lado da oferta primeiro, anúncios que ele mesmo cadastrou, matching feito por ele via WhatsApp nos primeiros dois meses. A construção custom veio depois, quando ele já tinha trinta cozinhas e uma fila de cozinheiros, quando finalmente soube o que o motor de matching de fato precisava fazer. O app com que ele terminou custou menos do que o que tinham orçado, e, diferente daquele, tinha algo para combinar.
Perguntas frequentes
O que é um marketplace de dois lados?
Um marketplace de dois lados é uma plataforma cujo valor vem de conectar dois grupos distintos que precisam um do outro, um ofertando algo e o outro demandando, em que o trabalho do produto é fazer o match e ficar com uma parte da transação. O Airbnb conecta anfitriões e hóspedes, a Uber conecta motoristas e passageiros, a Etsy conecta criadores e compradores. O fundador não constrói nenhum dos lados; ele constrói a máquina de matching no meio e ganha uma taxa toda vez que ela funciona.
Qual é um exemplo de marketplace de dois lados?
Airbnb (anfitriões e hóspedes), Uber (motoristas e passageiros), Etsy (vendedores e compradores) e DoorDash (restaurantes e quem janta) são todos marketplaces de dois lados. A parte instrutiva não é o logo famoso, é como cada um lançou: todos acharam um jeito de ser úteis para um lado antes de o outro existir, normalmente construindo a oferta na mão antes de a demanda chegar.
A Etsy é um marketplace de dois lados?
Sim. A Etsy conecta dois grupos distintos, criadores independentes do lado da oferta e compradores em busca de produtos artesanais ou vintage do lado da demanda, e fica com uma parte de cada venda. Como a maioria dos marketplaces, ela resolveu a oferta primeiro, atraindo vendedores e o estoque deles antes de ter uma grande base de compradores para oferecer.
O Zillow é um marketplace de dois lados?
Mais ou menos, e é um caso de fronteira útil. O Zillow conecta compradores, vendedores e corretores, e roda os próprios produtos de dados por cima, o que o aproxima mais de uma plataforma de múltiplos lados do que de um marketplace de dois lados puro. Muitos marketplaces reais derivam para esse lado conforme crescem; o modelo de dois lados é o ponto de partida mental, nem sempre a forma final.
Como se constrói um marketplace de dois lados?
Não lance com os dois lados. Escolha o lado mais difícil (normalmente a oferta), construa-o primeiro (na unha se preciso) até existir massa suficiente para o outro lado ter motivo de aparecer, e só então ligue a demanda. Comece com o mínimo de software que permite atender um lado e fazer o match na mão, aprenda as regras de matching manualmente e depois construa as camadas de matching e confiança em custom, porque é onde mora a sua defensibilidade. As superfícies de listagem e os pagamentos são em grande parte genéricos; o matching e a confiança não.
O que é a teoria de mercado de dois lados?
É o conceito econômico de que algumas plataformas criam valor servindo dois grupos de clientes interdependentes ao mesmo tempo, em que o valor de cada grupo cresce com o tamanho do outro (um efeito de rede), e precificar um lado pode subsidiar o outro. É um bom pano de fundo, mas é a moldura do economista; o problema do fundador é o prático de fazer algum dos lados aparecer primeiro.