Prefer to talk it over? So do we — and it's obviously no strings attached!
A question or need more information? Don't hesitate to contact us.
Platane has joined the France Num initiative to support small and medium-sized enterprises in their digital transformation: diagnostics, training and financial aid.
Why call on a digital expert referenced by France Num? →
Certified web quality expertise for high-performing and accessible websites
Innovation Tax Credit approved
13/04/2026
real estate
supabase
saas
11 minutes
Industry sources estimate that over 10 % of French real estate transactions now happen off-market, and the share rises sharply on premium assets and deals between professional flippers. Yet most of the networks that handle this deal flow still run on WhatsApp groups, shared Google Sheets, and patched-up CRMs. When a founder decides to turn that activity into a real off-market real estate platform, the hard part isn't design or inventory. It's reconciling layered confidentiality, useful matching, and a recurring revenue model inside one coherent product.
The same challenge hits private investor clubs, deal sourcing networks, broker collectives, and buy-side advisors. The business need converges, the architecture even more so. Here is how we build a sound MVP, which decisions shape the first six months, and where the traps that derail projects at 80 % completion are hiding.
A site like Zillow, Rightmove, or SeLoger optimizes for public discovery: SEO, open filters, Google indexing, hi-res photos. The opposite of off-market. On a real off-market real estate platform, value comes from the network and the scarcity. The most coveted asset must never be indexed, never appear in a public URL, never show up to non-members.
That inversion changes everything:
On the UX side, you are not optimizing the conversion of an anonymous visitor. You are optimizing the quality of the feed for an authenticated member who is already engaged. It feels closer to a vertical Slack than to a real estate site.
:::our-take The success metric of an off-market platform is not the number of listed assets. It is the share of listed assets that lead to a qualified introduction. An MVP shipping 5 closed introductions beats an MVP shipping 500 dormant cards every single time. :::
We have applied this kind of pattern with Astory, the private platform we built for renting fine art between galleries and collectors: strict authentication, no public indexing, custom contracts. Three years later, Astory has crossed €800,000 in annual revenue. The patterns described below come from that kind of feedback.
Next.js + Supabase + Stripe is a strong default stack for this product type. Not because it is trendy, but because (RLS) pushes confidentiality enforcement down to the Postgres layer instead of leaving it in the application code. Concretely: even if a developer forgets a check inside an API route, the database refuses the query.
The base pattern for a multi-level feed looks like this:
alter table public.posts enable row level security;
-- Level 1: members-only public posts (any authenticated account)
create policy "members_can_read_public_posts"
on public.posts for select
using (
visibility = 'public_members'
and auth.uid() is not null
);
-- Level 2: gated posts (explicit grant required)
create policy "members_with_grant_can_read"
on public.posts for select
using (
visibility in ('controlled', 'nda')
and exists (
select 1 from public.post_access_grants g
where g.post_id = posts.id
and g.user_id = auth.uid()
and g.status = 'granted'
)
);
-- Level 3: private posts (author only)
create policy "owner_can_read_private"
on public.posts for select
using (
visibility = 'private'
and author_id = auth.uid()
);
Three things matter here:
post_access_grants table that records who got access to what, when, and after which action (plain request, signed NDA, manual approval). It is your native audit log.:::warning
A slow RLS policy will throttle the whole product. If your policies do complex JOIN operations or call non-immutable Postgres functions on every row, you will pay for it in latency. Index the columns referenced in policies (visibility, author_id, post_id on grants), and prefer (select auth.uid()) over auth.uid() directly inside conditions: Postgres caches the subquery result for the entire query.
:::
The Platane agency (https://platane.io) applies exactly this pattern on Jef.chat, the AI assistant we built for the Brussels Bar. Each lawyer has a private workspace, and tenant isolation is enforced by RLS at the database level. Even system administrators have no visibility into individual content. That is the right bar for transactional off-market data.
The brief on this kind of project always includes the line: "configurable AI matching engine". The temptation to start with vector embeddings and an LLM is strong. It is almost always a mistake in V1.
The reason is simple. A learning engine needs feedback signals to learn (clicks, saves, access requests, closed deals). Until those signals exist in your data, any ML model will produce noise. The right sequence: a heuristic scoring that works, then 6 to 12 months of feedback collected in production, then a supervised re-training.
A heuristic scoring for professional real estate fits in 50 lines of TypeScript:
type SearchProfile = {
zones: string[]; // postal codes or census tracts
assetTypes: string[]; // 'residential' | 'commercial' | 'hospitality'
budgetMax: number;
yieldMin?: number; // expected yield in %
strategy?: 'core' | 'value-add' | 'flip';
};
type Opportunity = {
zone: string;
assetType: string;
price: number;
estimatedYield?: number;
strategy?: string;
};
const WEIGHTS = {
zone: 0.35,
assetType: 0.25,
budget: 0.20,
yield: 0.15,
strategy: 0.05,
};
export function scoreOpportunity(p: SearchProfile, o: Opportunity): number {
let score = 0;
if (p.zones.includes(o.zone)) score += WEIGHTS.zone;
if (p.assetTypes.includes(o.assetType)) score += WEIGHTS.assetType;
if (o.price <= p.budgetMax) {
const fit = 1 - (o.price / p.budgetMax);
score += WEIGHTS.budget * Math.max(0.3, fit);
}
if (p.yieldMin && o.estimatedYield && o.estimatedYield >= p.yieldMin) {
score += WEIGHTS.yield;
}
if (p.strategy && o.strategy === p.strategy) score += WEIGHTS.strategy;
return Number(score.toFixed(3));
}
A few principles that make the difference:
:::tip Before writing a single line of matching code, ask 3 target users to manually score 20 opportunities according to their own criteria. Compare with your algorithm. If you agree on 70 % or more, you have a workable MVP. Below that, your weights need to be revised. :::
The 7th feature in the typical brief is always "simple NDA and data room system". The trap: aiming for a fully bulletproof eSignature workflow in V1. That is 2 to 3 months of work for something users will not exercise until they have actual deal flow.
The MVP pattern that covers 90 % of cases:
user_id, post_id, accepted_at, ip_address, user_agent, nda_version_hash.document_access_log table.This approach mirrors the "One-Click NDA" architecture documented by specialized vendors like Digify. For an MVP, it is plenty. The day a real dispute forces you to upgrade to qualified eSignature, you wire up DocuSign or PandaDoc on the API side in a few days, and you replace step 2.
:::gotcha The NDA version hash is critical. If you change the terms in V2, users who accepted V1 keep their V1 acceptance. Without a version hash, you can no longer prove which version each acceptance maps to. Store the full NDA text accepted in Supabase Storage, hashed in SHA-256, never just a revision number. :::
The Stripe integration is the most documented and least technically risky part. The real questions are strategic.
The classic Free / Trial / Pro setup works well on this kind of platform, on three conditions:
On the code side, the Next.js + Stripe pattern is canonical: a /api/stripe/checkout endpoint that creates the Checkout Session, a /api/stripe/webhook listening for checkout.session.completed, customer.subscription.updated and customer.subscription.deleted, and a subscriptions table in Supabase that acts as the application source of truth. The official Stripe Billing documentation covers 80 % of what you need.
Two gotchas that cost engineers their evenings:
active accounts in your app for subscriptions canceled in Stripe. By the time a user complains, you owe them a refund.The architecture we set up for Easop, the startup that simplified international stock-options management, follows exactly this logic. It held up over 2 years of growth until the Remote.com acquisition. The same rigor on billing applies to an off-market platform aiming at hundreds of paying members.
The brief almost always includes "option: browser extension to import listings from external sites". Tempting: it lets a member capture a deal spotted on LinkedIn or an agency site without retyping. In practice, it is almost always a V2 deferral. Three reasons:
The MVP alternative that works: a paste-based import. The user copies the listing text, pastes it into a form, and an LLM call (GPT-4o, Claude, Mistral via Scaleway) extracts the structured fields (price, surface area, zone, asset type). It works on 100 % of sources, it never breaks, it costs €0.005 per import. Structuring sometimes misses on atypical listings, but the user corrects before publishing. It is an honest workflow.
The extension makes sense again in V2, on 1 or 2 target sites only, when volume justifies the cost and the user base is large enough to amortize maintenance.
Out of the 12 features typically requested, 6 form the real MVP:
The other 6 slip to V2:
With a team of 2 full-stack engineers, that MVP scope fits a 14 to 16 week schedule, which translates to a budget between €60k and €90k excl. tax depending on design polish. That is the realistic order of magnitude for a product professionals will accept to pay €80 to €150 per month for.
On infrastructure: Supabase Pro at $25/month for the first 100 users, Vercel Pro at $20/month, Stripe with no fixed fees, plus an S3 bucket for attachments via Supabase Storage. You stay under €200 per month in fixed costs up to several hundred active members. That is the strength of this stack: unit economics are healthy from the first euro you collect.
For the 6-feature MVP scope described above, plan for 14 to 16 weeks with a team of 2 full-stack engineers, which translates to €60k to €90k excl. tax. An extended scope with browser extension, multichannel alerts, and qualified eSignature pushes the timeline to 22-26 weeks.
Supabase is built on Postgres, which natively supports Row Level Security and the complex SQL queries needed for matching scoring. Firebase Firestore offers no native RLS and no joins, which makes multi-level confidentiality rules far harder to enforce at the database layer.
For an MVP starting with fewer than 100 members, terms of access with timestamp, IP, and version hash are enough. Upgrading to a qualified NDA via DocuSign or PandaDoc happens in V2, when transaction volume justifies it and the first potential disputes appear.
Less than €200 per month on average, combining Supabase Pro, Vercel Pro, Stripe (commission only), and S3 storage via Supabase Storage. That cost structure delivers more than 90 % gross margin once you cross 30 paying subscribers at €100/month.
The three most common ones: chasing an AI matching engine in V1 with no user feedback to train on, underestimating RLS complexity and concentrating security in application code, and investing too early in features like the browser extension or full data room before the product has proven its network value.
Building an off-market real estate platform is not just stacking Next.js, Supabase, and Stripe. The real engineering lives in the trade-offs: which confidentiality levels you enforce in V1, how much simplicity you accept on matching scoring, when you let the data room slide to V2. Those choices drive your time-to-market, your maintenance cost, and the trust your first members will grant the product.
If you carry that kind of project and want to challenge your target architecture, your MVP scope, or your stack before signing with a technical partner, reach out to Platane. Our combined dev and product strategy practice lets us frame a project in a few sparring sessions, and lay foundations that hold across the 2 or 3 years of growth that follow launch.
