Housi - Trocar um app de construtor por produto próprio
Aplicativo e site de moradia por assinatura, com mapa, busca e reserva, construídos para substituir um aplicativo montado em ferramenta no-code.
Moradia por assinatura precisa de produto próprio
A Housi criou um modelo de morar sem burocracia de contrato longo: o apartamento é assinado como serviço. Um produto assim vive ou morre na experiência de encontrar o imóvel, entender o que está incluído e fechar.
O aplicativo que existia tinha sido montado em uma ferramenta de construção sem código. Funcionava como vitrine, mas não comportava o produto que a empresa queria oferecer.
O desafio
- Substituir sem perder identidade. O aplicativo novo tinha que assumir o mesmo nome nas lojas, o que exige coordenar a transição de titularidade e de identificador com o produto antigo ainda publicado. Construir antes da API existir. No início não havia interface de dados própria. O desenvolvimento começou consumindo um feed legado, e a API da Housi só ficou pronta meses depois do início do projeto. Mapa como interface principal. Buscar imóvel por lista é uma coisa; buscar por mapa, com preço no pino e filtro por região, é outra bem diferente.
Começar pela pesquisa, não pela tela
Antes de desenhar qualquer coisa, o trabalho começou olhando para o que já existia: análise heurística do aplicativo em uso e comparação com referências do setor, no Brasil e fora.
Depois veio a parte que costuma ser pulada: pesquisa de usabilidade com pessoas reais sobre o protótipo, com roteiro definido, sessões gravadas, tabulação das observações, relatório e uma matriz de percepções para priorizar o que mudar.
Isso muda decisão de produto de forma concreta. Ajuste de interface deixou de ser opinião e passou a ter observação por trás, incluindo mudanças em elementos que pareciam claros no desenho e não eram no uso.
Em cima disso saiu o design de alta fidelidade das três frentes: aplicativo, site e painel administrativo.
O que foi construído
Aplicativo iOS e Android, a partir de uma base única. Cadastro e acesso, redefinição de senha, edição de perfil, onboarding de quatro telas com ilustrações próprias, busca de imóveis, filtros, favoritos, detalhe da propriedade, ajuda e configurações.
O mapa. Propriedades exibidas como pinos, cada um mostrando o valor do aluguel, com filtragem conforme o nível de aproximação. O campo de busca completa o endereço enquanto a pessoa digita.
Site web, em React, reaproveitando a camada de controle de dados que já tinha sido escrita para o aplicativo. Menos código duplicado e mesmo comportamento nas duas pontas.
Painel administrativo, para a operação gerenciar o conteúdo.
As entregas foram para a mão do cliente em builds sucessivos desde as primeiras semanas, e não numa entrega única no fim.
Integrar com dado que ainda está nascendo
Boa parte do esforço técnico foi em algo que não aparece na tela: fazer o produto funcionar enquanto a fonte de dados ainda estava sendo construída do outro lado.
O caminho foi consumir primeiro o feed legado do site e, quando a API própria ficou pronta, migrar para ela. Isso permitiu que o aplicativo evoluísse em paralelo, em vez de ficar parado esperando.
Quando a API chegou, vieram as diferenças de formato que sempre aparecem em integração: coordenadas de geolocalização com separador decimal diferente do esperado, datas fora do padrão de fuso e valores monetários em formato divergente. Cada uma foi negociada item a item com o time do cliente, e a decisão foi acertar na origem sempre que possível, em vez de acumular conversão no aplicativo.
Um detalhe pequeno que custa tempo em todo projeto assim: o feed só respondia com um cabeçalho específico na requisição, informação que não estava documentada em lugar nenhum.
Stack e práticas
- React Native com Expo, uma base para iOS e Android. React no site web, reaproveitando o controle de dados do aplicativo. Google Maps para o mapa de propriedades, com marcadores, valor no pino e filtro por aproximação, e busca com autocompletar de endereço. Firebase para hospedagem do ambiente de homologação e armazenamento das imagens dinâmicas. API REST do cliente, com etapa anterior consumindo o feed legado. Pesquisa de usabilidade com sessões gravadas, relatório e matriz de percepções. Sprints com impedimento registrado e cobrado diariamente até a resolução, inclusive os que dependiam do cliente.
Seu produto está preso em uma ferramenta no-code?
Construtor sem código resolve bem a fase de validar a ideia. O limite aparece quando o produto precisa de uma experiência própria, de integração com os seus dados e de performance na tela principal. A X-Apps faz essa transição, com pesquisa antes de desenhar e entrega em builds desde as primeiras semanas.