01 — CONTEXT
The context
A real-estate agency needs much more than a place to publish properties: listings, search, lead capture, sales follow-up, languages, analytics and administration are all part of the same system.
02 — PROBLEM
The problem
Building a separate platform for each agency multiplies the code, the maintenance and every improvement. The alternative was one core: one core, multiple brands, isolated data. A single system that adapts to each business without ever mixing them.
03 — CONSTRAINTS
The constraints
- 01Each agency keeps its identity: its own colours, logo, typography and copy.
- 02Each agency arrives through its own domain or subdomain and only sees its own data.
- 03Isolation between agencies cannot depend on the frontend.
- 04Content in Spanish, English and Portuguese.
04 — SYSTEM
What I decided to build
A single-core, multi-tenant architecture: one Nuxt application that identifies the agency from the request’s domain and loads its configuration, brand, permissions and data.
05 — ARCHITECTURE
System architecture
SOFTWARE
Software
- A public website per agency: listings, property pages, maps, favourites and onboarding.
- An agency panel with a dashboard, leads with statuses, properties, locations and copy.
- Super-admin tools to create and clone agencies and configure their brand.
- Emails to the agency in its language, with the properties each lead has viewed.
DATA
Data
- Supabase on PostgreSQL with Row Level Security: every row belongs to an agency.
- Soft deletes and status-based visibility: archived or draft content never reaches the public website.
- Leads with the properties they viewed and the preferences inferred from their browsing.
- A dashboard with the most viewed properties, leads by source and an activity map.
AI / AUTOMATION
AI and automation
- Natural-language search: «villa with a pool in Marbella up to 500k» becomes filters for type, area, price and features.
- Filters appear as editable chips and results update as you type.
- Proactive capture: when a visitor shows intent, the system asks for their contact details and attaches what they have viewed.
- «Hot» leads flagged in the panel based on their activity.
Search interpretation does not depend on an AI model: it is rule-based, fast and predictable.
06 — DECISIONS
Key decisions, and why
Isolation in the database
Hiding data in the interface is not security. RLS policies stop one agency from reading or writing another agency’s rows, even if a query arrives malformed.
The agency is resolved on the server
Middleware identifies the agency by custom domain, subdomain or registered URL before anything is rendered. The website does not know other agencies exist.
Brand as configuration, not code
Colours, logo, typography and copy live in data. A new agency does not need a new deployment.
Panel routes check too
RLS is the first barrier; on top of it, every panel route validates the session, the agency and the role before querying.
07 — RESULT
Result
- A reusable vertical platform: several agencies on the same core, each with its own brand and data.
- New agencies are created or cloned from the super-admin panel, without building a new product.
- Pending, and documented as such: custom-domain management from the panel, and billing.
No invented business figures: what is shown exists and is documented.
08 — STACK
Tech stack
- Nuxt 4
- Vue 3
- TypeScript
- Supabase
- PostgreSQL
- RLS
- Tailwind CSS
- i18n
- Leaflet
09 — SIMILAR PROBLEMS
Similar problems I can solve
- →Several brands, branches, franchises or clients need the same system with separate data.
- →You maintain near-identical versions of the same website or application, one per client.
- →Each client must only see their own data, and that cannot depend on the interface.
This project is an example of custom software and data intelligence.
