MeuTerreiro — multi-tenant app for religious houses

MeuTerreiro is my own product, from concept to store release. It's a management app for Afro-Brazilian religious houses — announcements, ceremonies and events, study materials, monthly fees and a small shop — built in React Native with Expo and TypeScript on top of Firebase and Cloud Functions. Each house gets its own app, under its own identity, and no house's data reaches another's. It came out of a real house's need, and the first version was built for an actual terreiro.

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

Running a religious house happens scattered across a WhatsApp group, a notebook and a spreadsheet. Announcements sink into the group and nobody knows who read them; attendance lives in the director's memory; monthly fees are chased one by one in private messages; study material gets resent every time someone asks. And in a group chat everyone sees everything — including what the house's hierarchy wouldn't allow.

• Communication with no traceability: no record of who read or acknowledged an announcement.
• Study material restricted by initiation level circulating in an open channel, with no access control.
• Fees, attendance and shop takings kept in manual records, with no searchable history.
• Poor signal in the hall — anything that depends on a permanent connection doesn't survive real use.
• Religious attendance is sensitive data under the LGPD, which requires specific handling from the start.

1. 01

   Built from real use, not from market research

   The first version was built for an actual house, around what that house needed to solve. The domain vocabulary is modelled into the product rather than translated from a system designed for a different reality.

2. 02

   React Native + Expo with TypeScript

   A single app for iOS and Android in React Native with Expo and TypeScript. That shared base is what makes a multi-tenant product published to both stores viable without duplicating team or code.

3. 03

   Multi-tenant architecture with data isolation

   Each house gets an app with its own name, logo and colours, published under its own identity. One house's data never reaches another's: isolation is a premise of the data model, not a check bolted on at the interface.

4. 04

   Permissions designed around the house's hierarchy

   Roles are created with the names each house actually uses, and access follows the real hierarchy — someone still in development can't reach material restricted to confirmed members. Restricted content opens only inside the app, with no download, printing or screenshots.

5. 05

   Offline-first because the hall has no signal

   The app opens fully with no connection and syncs on its own when the signal returns. Restricted materials stay available offline while keeping the same access restrictions. This came from real use, not from an optimisation pass.

6. 06

   Firebase and Cloud Functions on the backend

   Authentication, database and push notifications on Firebase, with Cloud Functions for the rules that can't live on the client — generating the month's fees, confirming payment, and anything that needs reliable execution off the device.

7. 07

   Modules enabled per house

   Announcements with read acknowledgement, events with attendance roll call, materials in folders with role-based access, group study as quizzes and flashcards, monthly fees, and a shop with inventory and cash. Each house enables only what it uses.

8. 08

   Store releases and training

   I run the full cycle per house: assembling the identity, building, submitting to the App Store and Google Play, following the review, and training whoever will administer it. Support comes directly from me, not from an outsourced desk.

• 01

  Multi-tenant with a dedicated app per house, instead of one shared app

  A generic app with a login would have been simpler to publish, but the house would lose its identity and members would have to search for a brand that isn't theirs. I went with one app per house — it costs an extra release cycle per client and forces the discipline of propagating every change to all tenants, and that's what makes the product belong to the house.

• 02

  Offline-first as an architectural premise

  Treating offline as an edge case would have been cheaper, but the product is used precisely where the signal fails. Reads work from local state and sync happens when the connection returns — which changes the whole data model, not just the network layer.

• 03

  Content restriction that follows the house's own rules

  Restricted material opens only inside the app, with no download, printing or screenshots. This isn't commercial DRM: it's the digital equivalent of a rule the house already applies to printed material. The call was to follow the existing rule rather than propose a new access model.

• 04

  LGPD handled from the data model onward

  Religious attendance is sensitive data. Consent at sign-up, encrypted national ID numbers, deletion on a member's request, and a full data export if the house decides to stop. Handled in the initial design, because retrofitting it onto a live database is expensive.

• 05

  Financial rules in Cloud Functions, not on the client

  Fee generation and payment confirmation live on the server. The member reports, the director confirms, and the record that counts is the backend's — the device is never the source of truth for anything involving money.

Scope and architecture indicators for the product. The number of houses in production isn't disclosed.

What I did

Product, development and store releases — end to end

Platforms

iOS and Android · App Store and Google Play

Architecture

Multi-tenant — one app per house, isolated data

Stack

React Native · Expo · TypeScript · Firebase · Cloud Functions

Modules in production

Announcements · Events · Materials · Study · Fees · Shop

Availability

Opens fully offline, syncs on reconnect

Sensitive data

National ID numbers encrypted · LGPD

• Building for a domain I know from the inside changed the quality of the decisions: modelling hierarchy and confidentiality correctly required understanding the house's rule, not just the functional requirement.
• Multi-tenant with a published app per client demands release discipline: every backend or store change has to be propagated to all tenants, and that has to be in the process from day one.
• Offline-first decided up front is architecture; decided later it's a rewrite. The choice cuts across data modelling, state and synchronisation.
• Taking my own product all the way to the stores taught me the part client projects rarely show: submission, review, rejection, fixing, and the support that comes afterwards.

A product running in production, published on the App Store and Google Play, with one app per house under each house's own identity. It covers communication, events and attendance, materials with role-based access, study, monthly fees and the shop, working offline and syncing on reconnect. It keeps evolving, with new houses coming in and modules enabled according to what each one needs.