Pular para conteúdo
Web2026

CasaFácil

Plataforma de serviços domésticos com matching por geolocalização

Cliente
CasaFácil Tecnologia
Ano
2026
Duração
8 semanas
Atuação
Produto, design, desenvolvimento full-stack, integração pagamentos
01Contexto

Mercado de serviços domésticos carioca é fragmentado: clientes buscam diaristas, encanadores, marceneiros via indicação ou apps genéricos que misturam tudo. Fundadores queriam plataforma dedicada, com curadoria de prestadores e UX que respeite ambos os lados.

02Desafio

Construir MVP de plataforma two-sided em 8 semanas, cobrindo cadastro dual (cliente/prestador), matching por geolocalização, pagamento com split, avaliações bidirecionais, e onboarding sem fricção — tudo pronto para piloto com 100 prestadores.

03Abordagem

Arquitetura Supabase-first com Row Level Security para dados sensíveis, Pagar.me para split automático 90/10, Resend para emails transacionais, Next.js 16 no frontend. 5 phases executadas em 40+ commits.

Processo

Como o projeto saiu do papel

  1. 01 · DESCOBERTA

    Mapeamento dos dois lados do mercado

    Conversas com o sócio fundador e dois grupos de prestadores cariocas. O cliente quer confiança e preço justo. O prestador quer agenda cheia e pagamento garantido. Toda decisão de produto teve que servir os dois ao mesmo tempo, sem privilegiar um e abandonar o outro.

  2. 02 · BASE

    Privacidade entre os lados desde o primeiro cadastro

    A plataforma foi montada com separação rígida de dados — o cliente nunca vê documentos do prestador, o prestador nunca vê histórico do cliente em outros profissionais. O pagamento veio com divisão automática entre prestador e plataforma, sem precisar conferir e repassar valores manualmente.

  3. 03 · CONSTRUÇÃO

    Do zero ao serviço pronto em oito semanas

    A construção foi organizada em cinco etapas independentes: cadastro com verificação, busca por proximidade, pagamento com divisão automática, avaliação cruzada e notificações por e-mail. Cada etapa foi entregue completa antes da próxima começar — sem deixar pontas soltas no meio do caminho.

  4. 04 · PILOTO

    Cem prestadores selecionados, antes do mercado aberto

    Em vez de lançar pra todo mundo de uma vez, abrimos com cem prestadores selecionados. Isso permitiu ajustar atrito de cadastro e regras de preço antes de escalar pra público amplo. O cadastro do prestador caiu pra média de quatro minutos durante o piloto.

O que foi construído

01

Cadastro dual verificado

Cliente e prestador com fluxos distintos. Prestadores verificam CPF, comprovante de residência e especialidades antes de aparecer na busca.

02

Matching por geolocalização

Cliente vê apenas prestadores em raio de 15km configurável. Prestadores escolhem áreas que atendem.

03

Split automático 90/10

Cliente paga no app, 90% vai para prestador, 10% retido como fee da plataforma. Zero intermediação manual.

04

Avaliações bidirecionais

Cliente e prestador se avaliam após cada serviço. Qualidade sobe, perfis problemáticos caem na busca organicamente.

05

Autenticação email magic link

Sem senha. Supabase Auth com magic link por Resend. Login em 10 segundos no mobile.

06

Notificações transacionais

Confirmação de agendamento, lembrete, conclusão, recibo — tudo por email rico com branding. Sem depender de push notification.

Decisões de design

Por que escolhemos cada caminho

01 / 03
Login por e-mail sem senha, em vez do par tradicional
Senha forte no celular com teclado pequeno é fricção pura. Login por link recebido no e-mail resolve em dez segundos: digita o e-mail, abre a caixa de entrada, clica. A taxa de cadastros que ficavam no meio do caminho caiu de forma significativa nos testes iniciais.
02 / 03
Comissão percentual em vez de taxa fixa por agendamento
Taxa fixa desencoraja serviços de ticket baixo — uma diária pequena paga proporcionalmente mais do que um trabalho grande. Com comissão percentual, a regra é justa dos dois lados: serviço de R$120 paga R$12, serviço de R$1.200 paga R$120. Sem conciliação manual no meio.
03 / 03
Separação de dados desde a primeira tela, não como ajuste futuro
Em plataforma com dois lados, vazamento de informação entre eles destrói confiança em horas. A separação foi tratada como decisão estrutural, no nível mais baixo do produto, antes da primeira funcionalidade existir. Isso evita reescrita futura e força o time a pensar em quem vê o quê desde o início.

Stack técnico

Next.js 16TypeScriptSupabasePagar.meResendVercel

Resultados

Fase atual
Beta fechado, 100 prestadores
Feedback Eduardo (sócio)
5 phases, 18 tabelas, MVP completo
Tempo de onboarding prestador
4min média

Lições

O que ficou pra próxima

  • Plataforma com dois lados decide pelos dois ao mesmo tempo

    Toda decisão passou pelo teste duplo: serve o cliente E serve o prestador? Quando o teste falhava de um lado, voltávamos pra prancheta. Isso desacelera no começo, mas evita funcionalidades de vitrine que ninguém usa depois.

  • Piloto fechado calibra antes de escalar

    Lançar pra dez mil pessoas é tentador, mas erro de produto contamina reputação rápido. Cem prestadores selecionados deram retorno denso e direto. Ajustes em preço e cadastro saíram desse piloto antes do mercado aberto ver — e isso preservou reputação no momento mais frágil.

  • Pagamento dentro do app retém o app

    Plataforma de serviço que joga o pagamento pra fora do app perde retenção e perde dado. Quando agendamento, pagamento, avaliação e recibo ficam no mesmo lugar, o app vira centro de gravidade do relacionamento — não mais um catálogo onde o cliente entra e sai.

Onde explorar

Quer um resultado assim?

Conte sua ideia. Entregamos proposta concreta em até 24h.

Iniciar conversa