LegalTech data platform
Seventy-plus PostgreSQL tables of legal records — and screens that had to make them usable, not just visible.
- Data
- 70+ PostgreSQL tables
- Scope
- Majority of the frontend
- Role
- Frontend + the SQL behind it
The problem
A legal platform ran on a heavily normalized schema — over seventy tables of interlinked legal records. Every screen needed joined, aggregated, filtered views of that data, and generic table components collapsed under the complexity.
When the data model is the product, the frontend can't treat it as someone else's problem.
What I did
The work ran from the components down into the queries:
Reusable data-table components
Designed table components that handle what legal records actually need — nested relations, dense filtering, sorting across joined fields — once, instead of rebuilding them per screen.
A fast AI chat interface
Built the UI for the platform's AI assistant: streaming responses, and an interface that stays responsive while long answers render.
The SQL behind the screens
Wrote the multi-table joins, aggregations and filtered reports the views needed — so the queries fit the screens they serve, instead of the screens bending around the queries.
The majority of the frontend
Built most of the platform's frontend and set the component conventions the codebase still follows.
The outcome
The test of a data-heavy UI is whether non-experts can use it:
- Complex legal records became browsable and filterable by people who don't know what a join is.
- The AI chat holds up in daily use — fast enough that people actually use it.
- Screens and queries were designed together, so new views don't fight the schema.
Stack
React and TypeScript on the front, PostgreSQL underneath — and the deciding skill was SQL, because on a platform like this the frontend is only as good as the queries feeding it.
Does this sound like your app?
Every engagement here started the same way: an app already live, and a problem someone decided to stop living with. The audit is the low-risk way to start — read-only access, a written report, a prioritized fix list.