VG Real Estate — a listings platform and the CRM behind it
A two-part real-estate product: a public listings site and an agent-facing CRM over a single Postgres schema, with the landing page scoring 95 on mobile.
The problem
Toronto realtors run their listings on one platform, their leads on another and their follow-ups in a notebook. Nothing reconciles, so leads go cold in the gaps between systems — and the gaps are where the commission is.
What it does
Two applications over a single Postgres schema: the landing site that buyers see, and the CRM that agents work in. One source of truth for a listing means a change made by an agent is the change a buyer sees, with no export step in between.
How it was built
Next.js App Router and TypeScript for both applications, Supabase Postgres for data, with the CRM's Prisma schema acting as the source of truth for the database. Sharing the schema rather than syncing two databases is the decision the whole architecture rests on — it is also the decision that is expensive to reverse, which is why it was made first and deliberately.
The public landing page measures 95 for performance on mobile, with largest contentful paint at 2.6 seconds and no layout shift at all.
Where it stands
The listings site is live. The CRM is built but not yet deployed — stated plainly here rather than implied otherwise, because a portfolio that rounds "built" up to "running" is not worth reading.
What this demonstrates
Multi-application architecture over shared data, with the modelling done once and correctly — the kind of work that goes wrong quietly when it is rushed, and is expensive to unpick a year later.
Related services: Web apps · Business automation
FAQ
No. The listings site is public; the agent CRM is a private application and is not yet deployed.
Because a listing edited by an agent has to be the listing a buyer sees. Two databases means a sync step, and a sync step means the two disagree on the day it fails.