MeuTerreiro — app multi-tenant para casas religiosas

O MeuTerreiro é um produto meu, do conceito à publicação nas lojas. É um aplicativo de gestão para casas religiosas — avisos, giras e eventos, materiais de estudo, mensalidades e lojinha — construído em React Native com Expo e TypeScript, sobre Firebase e Cloud Functions. Cada casa recebe o próprio app, com a identidade dela, e os dados de uma casa não se misturam com os de outra. Nasceu de uma necessidade real de casa, e a primeira versão foi feita para um terreiro de verdade.

• React Native
• Expo
• TypeScript
• Firebase
• Cloud Functions
• Push notifications
• Offline-first
• App Store · Google Play

A administração de uma casa religiosa acontece espalhada entre grupo de WhatsApp, caderno e planilha. O aviso afunda no grupo e ninguém sabe quem leu; a presença fica na memória do dirigente; a mensalidade é cobrada uma a uma no privado; a apostila é reenviada toda vez que alguém pede. E, num grupo, todo mundo vê tudo — inclusive o que a hierarquia da casa não permitiria.

• Comunicação sem rastreabilidade: nenhum registro de quem leu ou confirmou ciência de um aviso.
• Material de estudo com restrição por grau de desenvolvimento circulando em canal aberto, sem controle de acesso.
• Mensalidade, presença e caixa da lojinha em registros manuais, sem histórico consultável.
• Salão com sinal ruim — qualquer solução que dependa de conexão permanente não sobrevive ao uso real.
• Frequência religiosa é dado sensível pela LGPD, o que exige tratamento específico desde o início.

1. 01

   Produto construído a partir de uso real, não de pesquisa de mercado

   A primeira versão foi feita para um terreiro de verdade, a partir do que a casa precisava resolver. O vocabulário do domínio — gira, corrente, cambono, desenvolvimento — está modelado no produto, não traduzido de um sistema feito para outra realidade.

2. 02

   React Native + Expo com TypeScript

   Aplicativo único para iOS e Android em React Native com Expo e TypeScript. A base compartilhada é o que torna viável manter um produto multi-tenant publicado nas duas lojas sem duplicar time nem código.

3. 03

   Arquitetura multi-tenant com isolamento de dados

   Cada casa recebe um app com nome, logo e cores próprios, publicado sob a identidade dela. Os dados de uma casa não alcançam os de outra: o isolamento é premissa da modelagem, não uma verificação aplicada depois na interface.

4. 04

   Permissões desenhadas sobre a hierarquia da casa

   As funções são criadas com os nomes que cada casa usa, e o acesso segue a hierarquia real — quem está em desenvolvimento não alcança material restrito a confirmados. Conteúdo sigiloso abre apenas dentro do app, sem download, impressão ou captura de tela.

5. 05

   Offline-first porque o salão não tem sinal

   O app abre completo sem conexão e sincroniza sozinho quando o sinal volta. Materiais restritos ficam disponíveis offline mantendo as mesmas restrições de acesso. Essa foi uma exigência do uso real, não uma otimização.

6. 06

   Firebase e Cloud Functions no backend

   Autenticação, base de dados e notificações push sobre Firebase, com Cloud Functions para as regras que não podem viver no cliente — geração das mensalidades do mês, confirmação de pagamento e o que depende de execução confiável fora do dispositivo.

7. 07

   Módulos ativados por casa

   Avisos com confirmação de ciência, giras e eventos com chamada de presença, materiais e apostilas em pastas com acesso por função, estudo da corrente em quiz e flashcards, mensalidades e lojinha com estoque e caixa. Cada casa ativa só o que usa.

8. 08

   Publicação nas lojas e treinamento

   Conduzo o ciclo completo por casa: montagem da identidade, build, submissão à App Store e ao Google Play, acompanhamento da revisão e treinamento de quem vai administrar. Suporte direto comigo, sem atendimento terceirizado.

• 01

  Multi-tenant com app próprio por casa, em vez de um app único

  Um app genérico com login seria mais simples de publicar, mas a casa perderia a identidade e o médium teria que procurar uma marca que não é a dele. A escolha foi por app próprio por casa — custa um ciclo de publicação a mais por cliente e obriga a disciplina de propagar cada mudança para todos os tenants, e é isso que faz o produto ser da casa.

• 02

  Offline-first como premissa de arquitetura

  Tratar o offline como caso de exceção teria sido mais barato, mas o produto é usado justamente onde o sinal falha. A leitura funciona a partir do estado local e a sincronização acontece quando a conexão volta — o que muda a modelagem de dados inteira, não só a camada de rede.

• 03

  Restrição de conteúdo respeitando o fundamento da casa

  Material restrito abre só dentro do app, sem download, impressão ou print. Não é DRM comercial: é o equivalente digital de uma regra que a casa já aplica no material impresso. A decisão foi acompanhar a regra existente em vez de propor um modelo de acesso novo.

• 04

  LGPD tratada desde a modelagem

  Frequência religiosa é dado sensível. Consentimento no cadastro, CPF e RG criptografados, direito de exclusão a pedido do médium e exportação completa dos dados se a casa decidir parar. Tratado no desenho inicial, porque retroagir isso numa base já em uso é caro.

• 05

  Regras financeiras em Cloud Functions, não no cliente

  Geração de mensalidade e confirmação de pagamento ficam no servidor. O app reporta, o dirigente confirma, e o registro que vale é o do backend — o dispositivo não é fonte de verdade para nada que envolva dinheiro.

Indicadores de escopo e arquitetura do produto. O número de casas em produção não é divulgado.

Minha atuação

Produto, desenvolvimento e publicação — ponta a ponta

Plataformas

iOS e Android · App Store e Google Play

Arquitetura

Multi-tenant — um app por casa, dados isolados

Stack

React Native · Expo · TypeScript · Firebase · Cloud Functions

Módulos em produção

Avisos · Eventos · Materiais · Estudo · Mensalidades · Lojinha

Disponibilidade

Abre completo offline, sincroniza ao reconectar

Dados sensíveis

CPF e RG criptografados · LGPD

• Construir para um domínio que eu conheço por dentro mudou a qualidade das decisões: modelar hierarquia e sigilo corretamente exigiu entender a regra da casa, não só o requisito funcional.
• Multi-tenant com app publicado por cliente cobra disciplina de release: toda mudança de backend ou de loja precisa ser propagada para todos os tenants, e isso tem que estar no processo desde o começo.
• Offline-first decidido no início é arquitetura; decidido depois é reescrita. A escolha atravessa modelagem de dados, estado e sincronização.
• Levar um produto próprio até a publicação nas lojas ensinou a parte que projeto de cliente raramente mostra: submissão, revisão, rejeição, correção e o suporte que vem depois.

Produto em produção, publicado na App Store e no Google Play, com um app por casa sob a identidade de cada uma. Cobre comunicação, eventos e presença, materiais com acesso por função, estudo, mensalidades e lojinha, funcionando offline e sincronizando ao reconectar. Segue em evolução contínua, com novas casas entrando e módulos sendo ativados conforme a necessidade de cada uma.