Em resumo
Função. Founding Designer. Investigação, marca, UX, frontend, backend, lançamento e campanhas. Dois fundadores trouxeram a ideia e gerem o negócio no dia a dia: recrutam profissionais e validam os pagamentos.
Período. De fevereiro a setembro de 2026. Da ideia à produção em menos de seis meses.
Stack. Next.js 16, Supabase (Postgres com row-level security), Vercel, Resend, Sentry, GitHub Actions, Playwright, Vitest.
Estado. Online em buscoservicio.com.ar. Mais de 230 perfis profissionais. O registo de clientes abriu a 8 de setembro de 2026.
O problema
Na Argentina, contratar um canalizador, um eletricista ou alguém para limpar a casa depende de grupos de WhatsApp, da recomendação de um vizinho ou de quem responder primeiro. Não há um sítio único onde ver quem está disponível, quanto cobra ou se os clientes anteriores ficaram satisfeitos. Paga-se em dinheiro ou por transferência e fica-se à espera de que corra bem.
Dois fundadores vieram ter comigo com uma ideia nascida da vaga de desemprego no país: uma plataforma onde quem tem um ofício pudesse ganhar dinheiro por conta própria com os seus serviços, na linha das novas aplicações que estavam a surgir na Argentina nessa altura. O primeiro mercado é a Grande Buenos Aires (AMBA).
No fundo, o problema de design era a confiança. Um desconhecido vai entrar em casa de alguém. O dinheiro muda de mãos antes de o trabalho ser feito. Nenhuma das partes tem provas de nada. Cada fluxo do produto foi pensado para conquistar essa confiança, um passo de cada vez.
Restrições
Uma só pessoa no produto. Design, frontend, backend, base de dados, deploy, conteúdo e marketing de lançamento passaram todos por mim, enquanto os fundadores geriam o negócio. É por isso que a documentação é tão detalhada: escrevi os fluxos de cliente, profissional e admin como documentos com diagramas de estados antes de os desenvolver, porque a minha única colega de equipa eram as minhas próprias notas de há um mês.
Sem gateway de pagamento, por opção. Os fundadores escolheram as transferências bancárias manuais em vez do Mercado Pago ou da Stripe, para não pagarem comissões de gateway. O cliente transfere para a conta da plataforma, marca "Ya transferí" e um admin confere o extrato bancário e confirma manualmente. Dessa decisão nasceu toda uma fila de reconciliação no painel de admin. Há uma integração com o Mercado Pago já desenhada e pronta, caso os fundadores mudem de ideias.
Lei argentina de proteção de dados. Os utilizadores têm direito a que os seus dados pessoais sejam apagados. Concebi um fluxo de eliminação de conta que anonimiza os dados pessoais mas preserva o histórico de transações de que a outra parte depende.
Utilizadores que vivem no telemóvel. Profissionais com ofício e clientes à procura de uma solução rápida usam o telemóvel. Uma janela de diálogo que não cabe num ecrã pequeno, ou um formulário que perde o que foi preenchido ao atualizar a página, não é um pormenor de acabamento. É uma reserva abandonada.
Processo
Antes de escrever uma única linha de código, estudei marketplaces de serviços na Argentina e no estrangeiro, montei um moodboard e publiquei uma landing page independente para começar a captar profissionais interessados enquanto o produto ainda estava a ser planeado. Depois o âmbito cresceu, de um MVP pequeno para uma plataforma completa (painel de admin, perfis de profissional e de cliente, chat interno, reservas e pagamentos), à medida que os fundadores e eu íamos percebendo do que o negócio precisava.
Tratei a documentação como mais uma peça de design. Cada fluxo foi escrito primeiro como um documento com um diagrama de todas as transições de estado: como uma reserva passa de pagamento pendente a validação pendente, depois a confirmada e por fim a concluída, quem desencadeia cada passo, que email é enviado em cada momento. Esses diagramas foram a especificação a partir da qual desenvolvi.
Trabalhei com um pull request por funcionalidade: 151 PRs integrados em cinco meses, cada um limitado a uma única alteração. Essa disciplina permitiu-me confiar no meu próprio trabalho anterior sem ter mais ninguém a rever o código.
O que teve mais peso foi uma revisão sistemática de UX do produto em produção, em junho de 2026, feita com agentes de IA no Claude Code. Seis agentes mapearam os subsistemas do código, oito procuraram problemas de UX, e cada problema encontrado passou por um verificador independente cuja função era tentar refutá-lo lendo o código. O resultado: 121 problemas detetados, 119 únicos, 80 submetidos a essa contraprova, 79 confirmados e 1 refutado. Os 25 mais graves, agrupados em quatro temas (um fluxo de pagamento com falhas, estados de autenticação sem saída, profissionais a trabalhar às cegas e janelas de diálogo que ficavam partidas no telemóvel), passaram de problema detetado a correção publicada em questão de dias.
Prefiro dizê-lo com clareza: isto foi feito com ajuda de IA. O valor não esteve em a IA encontrar bugs, mas num processo em que cada problema tinha de resistir a uma tentativa de o refutar antes de eu fazer alguma coisa.
Solução
Pesquisa e reserva com horários de 1 hora
O cliente pesquisa por categoria ou por texto livre, filtra por zona, modalidade e classificação, abre um perfil público e depois escolhe um horário de 1 hora num calendário, onde vê o preço antes de confirmar.
Decisão-chave
Os horários têm sempre uma hora. Os trabalhos reais não duram todos o mesmo, mas com um horário fixo o fluxo manteve-se exequível para uma só pessoa construir e fácil de gerir para cada profissional.
Contrapartida
Durante muito tempo, o calendário não bloqueava o horário enquanto o pagamento decorria: um cliente podia vê-lo livre, transferir o dinheiro e perdê-lo porque outra pessoa o reservava entretanto. Assinalei isto na revisão de junho e resolvi-o bloqueando o horário durante o pagamento e cancelando as reservas por pagar ao fim de 24 horas.
Computador
Telemóvel
Pagamento por transferência bancária com validação do admin
O cliente vê os dados bancários da plataforma, transfere o preço mais uma comissão de 4% e marca "Ya transferí". Um admin confere a transferência com o extrato bancário e confirma-a ou rejeita-a. É no momento da confirmação que os dados de contacto do profissional são libertados. Quando o trabalho termina, o profissional introduz um código de 6 dígitos que o cliente recebeu por email. Com isso, a reserva fica concluída e é gerada a liquidação: o preço menos a comissão.
Decisão-chave
A gestão do dinheiro é simples. A plataforma recebe tudo, não há pagamentos divididos nem contas ligadas, e depois o admin transfere o valor líquido para o profissional.
O que mudei
No início, um cliente podia transferir antes de existir qualquer registo da reserva, pelo que outra pessoa podia ficar com um horário já pago. Resolvi isso com o bloqueio do horário e fechei os becos sem saída à volta: uma reserva presa em pagamento pendente sem nenhum ecrã a mostrar os dados bancários, e um email de pagamento rejeitado que prometia um reembolso que o sistema não previa.
Verificação de identidade opcional e o selo "Verificado"
Um profissional pode enviar o documento de identificação e um certificado de registo criminal para obter o selo "Verificado". Sem eles, pode na mesma publicar serviços e receber reservas: basta uma descrição e um serviço ativo.
O que mudei
A verificação começou por ser obrigatória: sem documentos, o perfil não ficava visível. Mudei isso em agosto de 2026, depois de ver como a campanha de ativação corria na prática: 27 dos primeiros 30 profissionais que começaram o registo desistiram no passo de carregar os documentos. Tornei a verificação opcional e transformei-a num selo que se conquista. A ideia: um marketplace com oferta serve melhor os clientes do que um vazio atrás de uma barreira que ninguém consegue passar. A migração que aplicou a mudança deixa registada a decisão e o motivo no próprio código.
Contrapartida
Agora o selo significa "optou por se verificar", não "profissional avaliado". O resto da confiança fica a cargo das avaliações e da moderação.
Computador
Telemóvel
Painel de admin com registo de atividade, fila de pagamentos e moderação
Um único painel com sete secções: resumo, pagamentos, liquidações, profissionais, clientes, avaliações e admins. Cada ação passa por uma função de servidor que volta a confirmar o papel de admin, valida os dados e escreve num registo de auditoria que não pode ser alterado. As avaliações entram por aprovar e precisam de moderação manual antes de serem publicadas.
Decisão-chave
Criei o registo de auditoria desde o primeiro dia, porque o painel ia sempre ficar nas mãos de pessoas que não escreveram o código. Cada ação tinha de deixar um rasto que se percebesse mais tarde.
Contrapartida
Este painel é a única interface operacional da plataforma, e cada pagamento, aprovação e avaliação passa manualmente pelos fundadores. A partir de um certo volume, isso não escala. Foi a decisão certa para sair depressa com um produto a funcionar, e é a primeira coisa a mudar quando o volume crescer.
Ativação e comunicação
Os novos profissionais registam-se com um assistente passo a passo, veem um ecrã de espera enquanto o perfil é revisto e recebem 28 emails transacionais que cobrem cada mudança de estado: aprovação, rejeição, pagamento confirmado, código enviado, liquidação gerada. Antes do lançamento, pré-carreguei 214 perfis a partir das listas de contactos dos fundadores, em três lotes, para que o primeiro cliente não chegasse a um site vazio. Seguiram-se três campanhas de ativação: oito envios de email para os 214 no final de julho; um email e uma mensagem de WhatsApp em meados de agosto, quando a verificação passou a ser opcional (186 de 198 mensagens de WhatsApp entregues); e uma campanha segmentada no final de agosto com três grupos: profissionais que nunca tinham iniciado sessão (172), os que entraram mas deixaram o perfil incompleto (23) e os que tinham o perfil e os serviços completos (19). Gravei também 20 tutoriais em vídeo para o YouTube, para profissionais e para clientes, e produzi dois reels curtos com um fluxo de geração por IA, a um custo quase nulo.
Decisão-chave
Gravei os tutoriais a executar os testes end-to-end sobre a aplicação real enquanto capturava o ecrã. A mesma automação que verifica os fluxos produz também as imagens.
Um perfil pré-carregado não é um registo, e eu meço a diferença. Dos 237 profissionais de hoje, 70 já iniciaram sessão pelo menos uma vez: 47 que ativaram uma conta pré-carregada e 23 que se registaram por iniciativa própria. 34 carregaram um serviço ativo, que é o que conta de facto para poder receber reservas, e 15 têm o selo de verificado. As campanhas fizeram subir o número, de 30 perfis ativados depois dos primeiros envios para 70, mas, sendo honesta, uma lista de nomes não é um marketplace. É nisso que estou agora: conseguir que os outros 167 entrem, ou substituí-los por pessoas que queiram mesmo estar cá.
Computador
Telemóvel
Sistema de design e marca
Escrevi um manual de marca completo (logótipo, paleta violeta e âmbar, modo escuro, tipografia, iconografia, componentes e espaçamento) e publiquei-o dentro do próprio produto. A aplicação usa Tailwind 4 e um conjunto de componentes ao estilo shadcn: os mesmos cartões, janelas de diálogo e padrões de formulário são reutilizados nas áreas de cliente, profissional e admin.
Em julho de 2026 redesenhei em quatro etapas a página inicial e a landing para recrutar profissionais: contadores com dados reais da base de dados em vez de estatísticas inventadas, perguntas frequentes que respondem às dúvidas reais do registo e um botão de ação fixo no telemóvel.
Computador
Telemóvel
Notas técnicas
Next.js 16 na Vercel, e Supabase para a base de dados e a autenticação. O esquema cresceu ao longo de 59 migrações, cada uma testada localmente antes de tocar em produção. A segurança ao nível da linha (row-level security) é a base do modelo de privacidade: um cliente não consegue ver o telefone nem a morada de um profissional até a própria base de dados os libertar, o que só acontece quando um admin confirma o pagamento. A regra mantém-se mesmo que um bug no frontend tente mostrar esses dados antes do tempo.
As transições de estado das reservas são controladas por triggers do Postgres, pelo que uma reserva não pode saltar de pendente para concluída sem o papel certo. O Resend trata do email e o Sentry da monitorização, incluindo os cron jobs diários, para que nenhuma falha silenciosa passe despercebida. Os deploys para produção saem do branch main através do GitHub Actions. Os testes dividem-se entre o Playwright, para os fluxos end-to-end, e o Vitest, para os testes unitários.
A decisão mais difícil
A certa altura o produto estava em boa forma e eu queria continuar a melhorá-lo: mais correções, mais acabamentos, mais funcionalidades. Mas a plataforma quase não tinha clientes e havia poucos profissionais a receber reservas. Não precisava de mais trabalho de produto. Precisava de marketing: dar a conhecer a plataforma, trazer clientes e profissionais, pô-la a gerar receita.
Disse-o diretamente aos fundadores: vamos parar de investir no produto durante uns tempos e pôr esse dinheiro e esse tempo em marketing. Não é fácil dizê-lo quando o que se quer é continuar a construir. Mas um marketplace sem ninguém de nenhum dos lados não tem um problema de produto, tem um problema de procura, e isso não se resolve com mais acabamentos. Concordaram, e foi por isso que passei as semanas seguintes em campanhas, tutoriais e reels, em vez de em mais uma funcionalidade.
Impacto
A 25 de setembro de 2026: 237 perfis profissionais, 234 visíveis ao público, 70 ativados pelos próprios titulares, 34 com um serviço ativo e 15 com o selo "Verificado". 76 serviços em 16 categorias. Sem aquisição paga: cada número veio da pré-carga inicial, de três campanhas por email e WhatsApp, e do passa-palavra.
O registo de clientes esteve atrás de um ecrã de "brevemente" até 8 de setembro de 2026. No momento em que escrevo, ainda não há reservas concluídas. Todas as transações de teste foram apagadas da produção a 24 de julho, como limpeza antes do lançamento, pelo que o zero de hoje é um ponto de partida limpo, não um produto avariado. A tração real, hoje, está na oferta e no sistema de ativação. A procura está só a começar, e vou atualizar esta página à medida que for avançando.
Quanto ao processo: 151 pull requests integrados, 214 commits, 59 migrações, 28 emails transacionais, 20 tutoriais, 2 reels e uma só pessoa.
O que faria de outra forma
Tornar a verificação opcional desde o primeiro dia. O requisito obrigatório custou registos reais até eu o mudar. Parecia a opção responsável para serviços prestados dentro de casa, mas os dados da campanha mostraram que uma barreira rígida, sem um marketplace visível por trás, trava o registo em vez de criar confiança.
Levantar mais cedo a questão da validação manual de pagamentos. Mesmo respeitando a decisão dos fundadores de não usar gateway, teria levantado o problema da escala antes de abrir o registo de clientes, e não depois. O plano com o Mercado Pago está pronto para quando o quiserem usar.
Pré-carregar menos, ativar mais. Pré-carregar 214 perfis fez o site parecer cheio no primeiro dia, mas 167 dessas pessoas nunca iniciaram sessão. Uma lista mais curta de profissionais com vontade real de lá estar, ativados um a um, teria sido uma base mais sólida do que uma lista longa de nomes.
Separar desde o início os dados de teste da utilização real. Ter de escrever um script de auditoria e limpeza mesmo antes do lançamento, para confirmar que todas as linhas transacionais em produção eram de teste, mostrou-me que devia ter separado os dois ambientes desde o primeiro dia.
Equipa
Eu, como Founding Designer, responsável pelo produto do início ao fim: investigação, marca, UX, frontend, backend, lançamento e campanhas. Dois fundadores que gerem a operação, recrutam profissionais e validam os pagamentos.
