The whole platform on one map — what the offering is, how it's designed, and how a change becomes something a client can use.
Platmetrix is a commercial real-estate intelligence and operations platform. It does two distinct jobs for two kinds of customer, on one shared foundation.
The consulting side answers the question in front of an investor: should we commit capital to this site? Platmetrix runs a structured path — scope the question, gather and verify, analyze and pressure-test, recommend and hand off — and delivers the result as a protected report a client reads and downloads. Offerings span market analysis, site intelligence, ordinance review, third-party proposal management, financial analysis, lender packages, and investment reports. The live product surface is the Market Intelligence Portal, sold per market and unlocked in stages as the client pays.
The operations side is a suite of apps for property companies: PropIQ (property management — maintenance, leasing, banking), AssetIQ (asset & portfolio performance), LoanIQ (loan & debt tracking), and the Resident Portal (payments, requests, documents for tenants). A Design Studio (Unit Studio, Site Planner, Facade Studio) supports the development side.
Platmetrix helps people decide where to put capital, then gives operators the tools to run it — market intelligence on one side, operating software on the other, one login and one permission model across both.
Built for the people who have to commit capital, and the people who run the result.
| Audience | What they get | Where they live in the product |
|---|---|---|
| Developers & investors | Scoped due diligence to chase fewer, better sites and underwrite with a second set of eyes. | Market Intelligence Portal — reports in viewer.html. |
| Property operators | Software to run properties, portfolios and debt. | PropIQ, AssetIQ, LoanIQ. |
| Regional & property managers | Delegated control of their own staff and properties. | The Operational Platform Admin + PropIQ. |
| On-site staff | Task-scoped access — tickets, calendars, leasing. | PropIQ, scoped by capability. |
| Residents | Pay, request maintenance, read documents. | Resident Portal, one unit. |
| Platmetrix admins | Run the whole platform — accounts, access, paywalls, content. | Admin Console + Operational Platform Admin. |
Three layers. People use a front end hosted on Netlify; every page reads and writes through Supabase, which enforces who-can-see-what; a handful of Edge Functions reach outside services for money, messaging and rates.
People use the Netlify front end; every page reads and writes through Supabase, where Row-Level Security decides what each account may see; Edge Functions reach the outside services.
The front end holds no secrets and makes no access decisions. It asks Supabase, and Supabase's Row-Level Security answers based on the signed-in account. That's why access can change instantly with no redeploy — the rules live with the data, not in the page.
One permission model spans both business lines. Each role has its own handbook; this overview is the map that ties them together.
| Role | Assigns others? | Its handbook |
|---|---|---|
| Master & Platform admin | Yes — master grants assignability | Platform Admin Console |
| Sales admin | No | (Quote Builder) |
| Enterprise owner | Yes (its users) | Market Intelligence |
| Regional manager | Yes (managers & staff) | PropIQ / AssetIQ / LoanIQ |
| Property manager | Yes (its staff) | PropIQ |
| On-site staff | No | PropIQ (role-scoped) |
| Resident | No | Resident Portal |
Assignability flows down a tree: master → platform → regional → property manager → staff. Everyone sees only their own branch, enforced by Supabase — the same scoping whether you're granting a market or a maintenance capability.
Before the specific journeys, the rule that governs all of them: on Platmetrix, access and content are data, not code. Almost every change an admin or manager makes is a write to a Supabase table that takes effect on the next page load. The only thing that needs a Netlify redeploy is a change to the page files themselves.
| Change | What actually happens | Redeploy? |
|---|---|---|
| Unlock a paid report | Raise page_access.tier | No |
| Grant a tool | Insert a project_access row | No |
| Change a staffer's rights | Edit project_access.capabilities | No |
| Add a market report | New pages row + file in Storage | No |
| Reset a password | Supabase recovery (email) / OTP (phone) | No |
| Edit a page's layout or code | New file in the deploy bundle | Yes |
The clearest way to understand Platmetrix is to follow a change from the moment someone makes it to the moment someone else can use the result. Three journeys, each from trigger to output.
An admin builds the market in market-editor, stores the report file, and prices it in the Quote Builder.
Client pays the deposit (Stripe) or invoice (QuickBooks); the admin raises page_access.tier.
Supabase serves the study or full file only at the client's tier — the gate is server-side.
Client signs in at index.html, sees the unlocked card in home.html, opens viewer.html.
A resident submits a request in the Resident Portal — it writes a work-order row.
A maintenance tech sees it in PropIQ (their rights: view & close-to-supervisor), does the work, closes & routes up.
The supervisor closes & routes to property management (their rights: schedule, assign, close-to-PM).
A notify Edge Function confirms back to the resident.
A Regional PM opens the admin console, drills to a property, expands a staffer, and toggles a capability.
The toggle upserts that person's project_access.capabilities for that tool and property.
RLS confirms the RPM is in the same subtree and may assign; the write commits — no redeploy.
On the staffer's next load, PropIQ shows or hides that action.
Two systems run everything. Netlify serves the front end; Supabase holds identity, data, access rules, files and the small server functions.
Static hosting for every page. A manual deploy replaces the whole site, so pages ship as one bundle with config.js (the Supabase URL and publishable key). No page contains a secret.
Auth (sign-in, sessions, is_admin); Postgres with Row-Level Security (the profiles, page_access, project_access, properties tables that decide access); Storage (private buckets for reports and resident documents); and Edge Functions (billing/reconciliation, password reset, work-order notifications, the FRED rates feed) — the only place third-party secrets live.
The publishable key in config.js is public by design; RLS is what protects the data. Every secret — Stripe, Twilio, service-role — lives only in Edge Function config, never in a page. If a secret ever appears in a file, rotate it.
This overview is the map. Each surface has its own step-by-step handbook for the person who works in it day to day.
| Handbook | For | Covers |
|---|---|---|
| Platform Admin Console | Master & platform admins | Accounts, tools, paywalls, access levels, account lifecycle, Netlify/Supabase operations. |
| PropIQ | Regional / property managers, staff | Maintenance, leasing, banking; client admins, properties, per-user rights. |
| AssetIQ / LoanIQ | Asset & debt managers | Portfolio performance; amortization, DSCR, lender packages. |
| Resident Portal | Residents | Payments, requests, documents. |
| Market Intelligence | Enterprise owners & clients | Reading and sharing market reports. |
Read this overview to see how the whole platform fits and how a change becomes a usable output. Then open the handbook for the surface you work in for the click-by-click detail.