Real-Estate Transaction Platform
Founder & Full-Stack Engineer
This product has not launched yet, so this page covers how it is built rather than what it does. It is a full-stack TypeScript application I designed and built from the ground up: prerendered marketing pages, secure accounts, Stripe checkout, e-signatures that can be verified after the fact, generated PDF documents, and transactional email, with every important state change handled by a serverless edge function.
How is the platform structured?
The front end is React, TypeScript, and Tailwind CSS on Vite, statically generated so every public page ships as real HTML for search engines and link previews. The back end is Supabase: Postgres with row-level security, authentication, storage, and a set of Deno edge functions that own every write that matters, from starting an order and creating a checkout session to handling the Stripe webhook, recording signatures, and running admin actions. Forms validate their input with Zod, and email goes out through Resend.
The whole stack runs in Docker, including a local Supabase instance, so migrations, policies, and edge functions are exercised locally against a copy of production before they ship.
How does one fact stay consistent across pages, payments, and documents?
Every business fact has exactly one home. Shared modules hold prices, terms, and document text, and the browser bundle, the Deno edge functions, and the Node build scripts all import them, which means they have to stay dependency-free. The same module feeds the pricing page, that page's structured data, the checkout function, and the generated documents, so none of them can disagree with another.
Prices are computed on the server. The browser never sends an amount: the checkout function prices the order itself before it creates the Stripe session.
How can an e-signature be verified after the fact?
When someone signs, the server rebuilds the exact document text from its source and hashes it, and the signature is accepted only if that hash matches the hash of the text the signer was shown. The typed name, IP address, and timestamp are recorded with each signature. Invitations for additional signers use tokens that are stored only as SHA-256 hashes, so even a leaked database would not contain a working link.
How are the PDF documents generated?
Documents are produced with pdf-lib inside the edge functions. Some are drawn from scratch; others fill fixed-layout forms, where a script generates the position of every field from a single source, and a check fails whenever the generated files are out of date. Completed documents are stored when they are signed and re-rendered when the final signature is added, so the stored copy always matches what every party signed.
What enforces database permissions when row-level security is not enough?
Row-level security decides which rows a user can touch, but not which columns. So a user may update only one data column on their own record, and only while that record is in an editable state, which a Postgres trigger enforces. Every status change goes through an edge function running with the service role, or through an admin whose role is read from the signed token's app metadata. The policies have their own SQL test suite.
Industry rules the product has to follow are enforced in the code paths that could break them, not left to the copywriting.