Stay in the work
Dense queues, inline review, expandable detail, and bulk actions reduce page changes and context loss.
← Selected Work
Live API · Synthetic demonstration data
2025–Present · Product Engineering Case Study
HAVEN
An evidence-first finance operations workspace for property management.
HAVEN connects bills, payments, banking, trust funds, owner distributions, reservations, document evidence, and team review in one operational system, without treating financial controls as an afterthought.
Live API · Synthetic demonstration data
A command center for workload, cash movement, readiness, and exceptions, not a collection of disconnected reports.
18lazy-loaded workspaces
288REST route declarations
143SQLAlchemy table models
30versioned migrations
624Python test functions
Repository snapshot, July 2026. Counts describe implemented source, not production usage.
01 · The Product
One operational layer across a fragmented financial process.
Property accounting rarely lives in one place. Invoices arrive as PDFs or scans. Transactions appear in banking and card portals. Reservation activity originates in property-management platforms. Approval evidence is buried in email, folders, spreadsheets, and memory.
HAVEN was designed as the working layer across those systems. The interface concentrates information where decisions happen; the backend preserves the lineage, permissions, and accounting rules behind every action.
Product questionHow can an operator understand, verify, and move a financial record forward without repeatedly leaving the task at hand?
Evidence travels with the record
Invoices, receipts, proofs, statements, and generated packets remain visible beside the accounting object they support.
Make the next action legible
Status, readiness, exceptions, and permitted actions are explicit at both the row and workflow level.
02 · The Operating Model
From source document to reconciled financial event.
The workbench follows the real lifecycle rather than forcing each department into a separate tool.
- 01IngestUpload, scan, import, or sync
- 02StructureExtract fields and preserve source context
- 03ReviewCode, validate, and resolve exceptions
- 04PostCreate balanced, traceable accounting entries
- 05PayBatch, approve, send, and attach proof
- 06ReconcileMatch the bank and close the loop
Bill Entry Desk
List-first review, with the source document kept in frame.
Payment state, due date, workflow status, evidence, invoice number, amount, and vendor context are visible before a row is opened. Search and high-dimensional filters work across operational fields and lifecycle metadata.
Inline Review
Detail appears in context, not on a disconnected page.
An expanded bill exposes vendor and invoice fields, line coding, readiness checks, related records, next actions, and the original PDF together. The operator can verify the decision before moving the bill forward.
- Independent bill- and line-level validation
- Visible balanced-versus-coded totals
- Related vendor, property, invoice, and amount context
- Persistent source evidence throughout approval
Document Intelligence
Structured suggestions without silent accounting changes.
The current extractor parses text-native invoice documents with deterministic rules, returns field-level confidence, and routes incomplete results into human review. It does not silently post extracted data to the ledger.
Corrections preserve the original value, replacement, actor, reason, and source context. They are audited feedback for that document, not an unreviewed global model retraining loop.
Current boundary
OCR and connected AI providers are planned integration points; the present implementation is rules-based.
03 · Architecture
A canonical financial model between source systems and operator decisions.
External providers can change. Core accounting logic should not have to.
Sources
PDF & scansBank & cardsPMS platformsCSV & APIs
Ingestion & lineage
ValidationExternal IDsExtractionSource evidence
Canonical domain + ledger
BillsPaymentsReservationsTrustJournal entries
Operational workspaces
Review queuesReconciliationOwner statementsReports & packets
A reusable workbench shell
React 19 and TypeScript with Vite, TanStack Query/Table/Virtual, Zustand, Zod, Radix primitives, dnd-kit, and PDF.js.
Explicit service boundaries
FastAPI and SQLAlchemy expose organization-scoped workflows over PostgreSQL, with Pydantic contracts and Alembic-backed evolution.
Evidence and asynchronous work
S3-compatible object storage keeps documents separate from relational state; an outbox worker handles deferred processing without losing intent.
A navigable object graph
Each record exposes its related context, evidence, money trail, and downstream accounting impact instead of hiding them in separate modules.
04 · Financial Controls
Correctness does not depend on the interface being open.
Critical rules live in service and database layers, not only in client-side validation.
Invalid journals cannot post.
Entries must balance, and posted financial records become immutable. Corrections use explicit reversals rather than hidden edits.
Available balance is a hard boundary.
Trust debits are blocked when they would reduce an owner or property subaccount beneath its required reserve.
The creator cannot self-approve.
Independent approval is enforced across bills, payment batches, trust distributions, owner statements, transfers, and reconciliations.
Every decision keeps its proof.
Content-addressed documents link directly to the records and accounting events they support.
Team Work
Exceptions become owned work, not passive warnings.
Every exception, task, approval, and comment lands in one reviewable queue. Saved views, filters, priority, evidence, status, and next action make operational responsibility explicit.
05 · Security & Engineering Quality
A fail-closed production design, paired with an honest prototype boundary.
Identity and tenant isolation
Production configuration requires OIDC, MFA evidence, asymmetric access-token verification, bounded token lifetime, and exact external-identity mapping. Tenant context is applied transaction-locally and protected by PostgreSQL row-level security.
Separated database responsibility
API, worker, migration, and maintenance workloads use distinct restricted principals so ordinary runtime processes do not own the schema or bypass tenant policy.
Defensive document handling
Uploads are size-bounded, signature-checked, restricted by type, protected from active content and CSV injection, and designed to pass through malware scanning. Access URLs are short-lived.
Realistic practice data
Deterministic fictional records exercise real workflow states without presenting scraped or customer data. Synthetic documents remain visibly labeled throughout the demo.
105test modules
624test functions
30schema revisions
Coverage includes authentication, tenant isolation, upload security, maker-checker controls, extraction corrections, financial guardrails, and complete trust-distribution lifecycles.
06 · Reflection
The project is as much about operational clarity as accounting depth.
HAVEN demonstrates how I approach complex product work: begin with the real operating model, design the interface and data model together, put irreversible rules at the lowest reliable layer, and make every abstraction earn its place in the user’s day.
It is an engineering prototype and architecture package, not a claim of banking certification or jurisdiction-specific legal readiness. A production deployment would still require provider certification, independent security review, jurisdictional trust-accounting review, and hardened live integrations.