nderoga
construindo a plataforma imobiliária moderna do paraguai.
- // ano
- 2025
- // função
- founder e engenheiro
- // cliente
- projeto próprio
- // stack
- next.jsfastapipythontailwindpostgrespagoparci/cdarchitecture
nderoga é uma plataforma gratuita de listings imobiliários construída para o mercado paraguaio. proprietários e agências podem publicar listings ilimitados, enquanto compradores navegam casas, apartamentos e terrenos pelo país inteiro através de uma interface rápida e moderna.
construí end-to-end como solo founder — cada decisão, da estratégia de produto ao deploy — colaborando com um designer na identidade visual.
depois de um ano live, a plataforma tem 95 listings ativos e cresce organicamente por seo sem nenhum gasto de marketing.
o mercado imobiliário paraguaio é grande mas digitalmente subatendido. as plataformas que existem compartilham os mesmos problemas: cargas lentas, design visual datado, paywalls intrusivos para listings básicos e experiências mobile que parecem ter sido pensadas depois. para um país onde mobile é a forma principal pela qual a maioria acessa a internet, essa lacuna é significativa.
quando minha família passou pelo processo de procurar uma propriedade, a fricção foi óbvia. a busca parecia desajeitada, as fotos eram de baixa resolução e não havia uma forma clara para pequenas agências ou proprietários individuais publicarem sem pagar antes. eu seguia pensando a mesma coisa: isso poderia ser muito melhor com tooling moderno.
então decidi construir.
defini três estrelas-guia desde o começo:
- publicar grátis.baixar a barreira de entrada para que proprietários individuais e pequenas agências possam competir com os players estabelecidos.
- mobile-first e rápido.otimizar para o dispositivo e a conexão que a maioria dos paraguaios realmente usa.
- moderno mas familiar.que pareça atual para qualquer pessoa acostumada com airbnb ou zillow, mas falando a língua local — literal e culturalmente.
o nome nderoga vem do guarani. a frase nde róga significa "sua casa." eu queria um nome enraizado na identidade local em vez de outro nome anglicizado de startup despejado no mercado. é curto, memorável e carrega peso cultural.
para a identidade visual trabalhei com um designer que traduziu o brief em um sistema completo: logo, escala tipográfica, paleta de cores e estados de componentes. gerenciar essa colaboração foi um desafio próprio — comunicar a intenção do produto com clareza, dar feedback estruturado em cada iteração, definir quando algo estava "pronto o suficiente" para avançar e adaptar o design system ao código sem perder fidelidade. traduzir um arquivo do figma para um theme vivo do tailwind envolve dezenas de pequenos juízos que o designer nunca vê, e acertar isso é parte do trabalho de founder.
uma decisão deliberada à qual chegamos juntos: toda a ui suporta light e dark theme nativamente. transmite modernidade sem dizer uma palavra.
fui por uma separação limpa entre frontend e backend — dois serviços, um contrato compartilhado.
- app router com react server components para cargas iniciais rápidas e páginas de listing otimizadas para seo.
- o novo engine do tailwind v4 para design tokens e theme variables, o que tornou o sistema light/dark trivial de manter.
- typescript end-to-end com types compartilhados gerados a partir do schema openapi do fastapi.
- otimização de imagens com next.js image e um object storage com cdn para as fotos das propriedades.
- fastapi para a camada de api, combinando a produtividade do python com type hints e docs openapi auto-geradas que o frontend consome direto.
- postgresql como source of truth, com extensões postgis reservadas para futuras buscas geoespaciais.
- sqlalchemy e alembic para orm e migrations.
- auth jwt com controle de acesso por papéis para o modelo multi-tenant de agências (owner, editor, advertiser).
considerei um único app next.js com api routes, mas queria que o backend fosse portável e a api reutilizável para um futuro app mobile. separar logo de cara custou alguns dias extras de setup mas comprou flexibilidade de longo prazo. fastapi especificamente porque python me deixa prototipar lógica de dados e de busca rápido, e a auto-geração de openapi elimina toda uma categoria de drift de types entre frontend e backend.
a maioria dos concorrentes limita o volume de listings atrás de planos pagos. apostei que a monetização deveria vir de visibilidade premium (listings em destaque, placement promovido) e não do acesso básico. se uma pequena agência nem consegue entrar na plataforma, ela vai pra outro lugar — e o marketplace morre antes de começar.
o setor imobiliário no paraguai é dominado por pequenas agências com um punhado de agentes cada. construí organizações com permissões por função (owner, editor, advertiser) cedo — mesmo adicionando complexidade — porque adicionar multi-tenancy depois é brutal.
deliberadamente entreguei uma busca filtrada forte (cidade, tipo de propriedade, preço, tipo de operação) antes de investir em mapas interativos. mapas são caros de fazer bem e a maioria dos usuários começa por filtros de texto de qualquer forma.
seo foi uma prioridade de primeira classe desde o primeiro commit, não algo plugado depois. o resultado: um score de 90 no google pagespeed insights e crescimento orgânico que carregou a plataforma o primeiro ano inteiro sem marketing pago.
algumas coisas que fizeram a diferença:
- páginas de listing renderizadas no servidor com metadata completa, headings estruturados e html semântico limpo.
- urls baseadas em slug em todo lugar. cada propriedade, cidade e agência recebe uma url legível e otimizada para seo tipo /propiedad/casa-en-asuncion-3-dormitorios-… — crítica para a descoberta orgânica num mercado onde a maior parte do tráfego acaba vindo do google.
- structured data e rich previews. cada listing emite json-ld de schema.org realestatelisting e uma og image gerada dinamicamente. compartilhar um listing no whatsapp — o canal dominante por aqui — produz um rich preview, o que melhora bastante o click-through.
- image pipeline. as fotos das propriedades passam por um passo de transcodificação no upload que produz múltiplas variantes webp. o frontend serve o menor tamanho viável de acordo com viewport e device pixel ratio.
- preparado para internacionalização. mesmo publicando só em espanhol por enquanto, todos os strings visíveis ao usuário ficam em arquivos de tradução. adicionar guarani ou português depois é mudança de config, não refactor.
me recusei a lançar sem um pipeline de deploy real, mesmo como solo founder. o custo inicial é pequeno. o custo de não ter aparece da primeira vez que você quebra produção à meia-noite.
- github actions para os dois repos. todo pr roda lint, typecheck, unit tests e um build.
- frontend deploya na vercel ao mergear na main. preview deployments em todo pr para review visual.
- backend containerizado com docker, deployado numa plataforma de containers gerenciada com rollbacks automáticos. as migrations rodam como step gated separado antes da nova imagem entrar em produção.
- paridade de ambientes. o dev local roda contra a mesma versão de postgresql que produção via docker compose, o que me salvou de bugs "funciona na minha máquina" mais de uma vez.
depois de um ano no ar, nderoga está em 95 listings ativos e subindo, crescendo inteiramente por busca orgânica. sem ads, sem paid acquisition, sem growth hacks. só um produto rápido e bem indexado que as pessoas encontram quando buscam.
sigo iterando. trabalho recente e próximo:
- busca geoespacial com vista de mapa.
- buscas salvas com alertas por email.
- um app mobile nativo reutilizando o mesmo backend de fastapi.
- um tier premium para placements em destaque — a primeira camada de monetização.
construir nderoga me lembrou que entregar é a habilidade mais difícil. escolher a stack foi fácil. desenhar o schema foi satisfatório. o grind foi o último 20% — empty states, error handling, edge cases de auth, o footer de compliance fiscal, o cookie banner. o trabalho do qual ninguém fala em tutoriais mas que separa um side project de um produto de verdade.
também aprendi quanta alavanca o tooling moderno dá a um único founder. tailwind v4, o app router do next.js, os auto docs do fastapi, github actions — juntos eles permitem a uma pessoa entregar algo que cinco anos atrás teria exigido um time pequeno.
a maior lição é a mais simples: existe um abismo enorme entre reconhecer um problema e construir a coisa que o resolve. fechar esse abismo, e mantê-lo fechado semana após semana, é a única parte que conta.