Property & Investment CRM Platform

One internal system that models all four routes as they actually run, captures website enquiries into the same record set that staff work from, and enforces who may see and do what in a way the interface cannot talk its way around.

A CRM built on row-level database security rather than application checks alone. The signed-in member of staff is carried into the database connection, and the database itself decides which rows they may read and write — 92 policies across 38 tables. The application layer holds the session and a catalogue of 49 permissions across 6 roles; navigation is filtered on the server, so a link to an area someone cannot open is never sent to their browser, and the destination page checks again anyway.

The four investment routes are modelled as separate pipelines rather than as one pipeline with branches: 10 pipelines and 61 stages, seeded once and then read from the database at runtime. Moving an opportunity forward is one stage at a time; moving it backwards always requires a recorded reason and a permission most staff do not hold. Skipping a stage was deliberately not seeded — if the business wants it, that is a configuration change, not a release.

Public enquiries reach the database through a single function with elevated rights that can touch exactly one table, with rate limiting counted in the database rather than in a process that does not outlive the request. Staff triage them into contacts under the permissions they already hold, and the consent captured on the website travels with the record.

The platform is in active development. Contacts, opportunities, enquiry intake and triage, administration and the audit trail are built and covered by tests; delivery, compliance, agreements and finance exist in the schema and are not yet built, and are not described here as though they were.

One Next.js application serves both halves — the public marketing site and the protected CRM — against one managed PostgreSQL database. They share a deployment because they share a domain model: an enquiry submitted on the public site is the same row the CRM triages.

Authorisation lives in the database. The application connects as a role with neither SUPERUSER nor BYPASSRLS, sets the signed-in user on the connection, and every policy resolves through one has_permission function against the seeded permission matrix. The permission codes are declared once in TypeScript, seeded as data, and named by the SQL policies, so the application and the database cannot drift apart without the seed run failing.

Public form submissions are the one path with no identity behind them. They reach the database through a single function with elevated rights and can touch nothing else.

The audit log is append-only in three independent ways — grants, policies, and triggers that refuse the change even when the database owner attempts it.

The platform is in active development. This case study documents the CRM and operational foundation built so far — enquiry intake and triage, contacts, opportunities, the four stage pipelines, administration and the audit trail — with further modules to be added as the product progresses.

No usage figures are given because there are none to give: the environment holds no live records yet, which is also why the screens in this case study show their empty states rather than invented data. What can be stated is behaviour the test suite holds in place — that an opportunity cannot move backwards without a reason and a permission, that a stage gate cannot be bypassed by editing the record instead of moving it, that an audit event cannot be altered after it is written, and that an anonymous submission can reach exactly one table and nothing else.