AI Product Engineering
100+ people replaced Word and PowerPoint with one dashboard, cutting document time ~80%
The wealth-management operations team that used to retype legal documents into Word and PowerPoint by hand now works inside one dashboard — reviewing what the AI extracted, editing it inline, and exporting a finished book with one click.
Stack
- React
- TypeScript
- Supabase
- PostgreSQL
- Node.js
100+
active users
replacing a manual Word/PowerPoint workflow
~80%
less time per document
against the manual process it replaced
4
user roles
role-based access across the analytics dashboard
The product
Overview
The Heritage AI Platform is a document-intelligence system for a US wealth-management firm’s operations team — built solo over seven months, from architecture through to a production platform 100+ people use daily.
The team’s old process was manual: read a legal document, retype its contents into Word, assemble the result into a PowerPoint deck by hand. The platform replaces that with one dashboard — a document arrives already extracted and classified, a reviewer validates or corrects it inline, and a finished "Heritage Book" exports as a single-click PDF.
The interface
What the dashboard actually does
Read- and update-heavy by design — 150+ React components and 48 custom hooks, built for a team that spends its day reviewing extracted data, not entering it from scratch.
Role-based access, 4 roles — Each of the operations team’s roles sees and edits only what its job requires — built alongside the ops leads themselves, not guessed at.
Inline validation and rich-text editing — A reviewer corrects what the AI extracted directly in place, against the confidence-scored fields the sibling pipeline study produces — never a separate re-entry workflow.
Heritage Books, one click — The finished deliverable — what used to be a hand-assembled Word document plus a PowerPoint deck — now exports as a single-click PDF.
Why the dashboard edits confidence-scored data, not raw text
The AI extraction pipeline (the sibling study) already produces structured data. Why does the dashboard need its own validation layer on top of that, rather than just displaying the result?
The pipeline flags every field validated, not_validated, or missing — and the dashboard is built to surface exactly that distinction to a reviewer, not to hide it behind a clean-looking form.
A reviewer’s attention is the platform’s scarcest resource; showing which fields the AI is confident about and which it isn’t means that attention goes to the fields that actually need a human, not to re-checking everything uniformly.
The alternative
Present every extracted field the same way and let a reviewer check all of them equally.
What it cost
Surfacing confidence honestly means the interface sometimes shows its own uncertainty — a harder sell than a dashboard that looks uniformly finished, but a more honest one.
Outcome
Selected results
100+
active users
in production, replacing manual Word/PPT assembly
~80%
less time per document
against the manual process it replaced
150+
React components
48 custom hooks
4
user roles
RBAC built alongside the ops leads
Retrospective
What I would take to the next build
Build the review surface around what the model actually knows — Surfacing confidence tiers, rather than a flat "done" state, is what let this dashboard reduce review time instead of just moving the same manual work into a browser.
RBAC validated with the people who use it — The 4-role permission model shipped correctly the first time because it was built alongside the ops leads who actually use each role, not designed in isolation and adjusted after complaints.
Built as sole engineer on the product and platform layer over seven months, with RBAC validation screens shipped alongside the operations team who use them daily. Client and infrastructure identifiers omitted.