StolenMule
A multi-tenant practice-management platform built around the daily work of Illinois real-estate law firms.
Contributing to a law-firm operating system where tenant isolation, reviewable AI actions, and reliable financial and document workflows are product requirements.
- Role
- Full-stack Collaborator
- Team size
- Small team
- Updated
- 2026-08-03

Overview
What the project is and why it mattered.
StolenMule is a practice-management platform for Illinois real-estate law firms. It connects the work surrounding a matter: contacts, tasks, calendars, statutory deadlines, closings, time and billing, trust/IOLTA accounting, documents, public intake, invoice access, email workflows, and AI-assisted data capture. The interface is intentionally dense and operational, helping a firm move work forward without scattering sensitive information across disconnected tools.
Product scope
Matters, closings, billing, trust, documents, email, and intake
Tenant model
Schema-per-firm Postgres isolation
AI safety
Read access plus human-confirmed staged writes
Problem
Real-estate legal work combines deadline pressure, sensitive client data, document-heavy collaboration, billing, and regulated trust accounting. A useful platform has to make that work faster without weakening tenant isolation, obscuring money movement, or allowing automation to act beyond human review.
Role
I build StolenMule alongside a small team as a full-stack collaborator. My work follows the shared Go, React, and Postgres architecture while helping translate domain-heavy legal workflows into maintainable product features, clear interfaces, and changes that can be verified without putting client or firm data at risk.
Build details
Stack, constraints, and decisions.
Stack
Constraints
- Each firm needs a hard tenant boundary, with tenant data isolated by Postgres schema and role rather than application filters alone.
- Trust/IOLTA accounting and money movement require explicit authorization, append-only history, and careful audit behavior.
- Documents, email bodies, intake data, and AI-ingested content may contain sensitive or untrusted information and cannot be allowed to drive actions on their own.
- The product must support dense, fast legal workflows without hiding validation failures or overwhelming users with decorative interface layers.
- Slow external services such as document rendering, email, and AI providers cannot hold request-scoped database transactions open.
Decisions made
Isolate every firm at the database role level
Tenant traffic re-enters through a scoped transaction that sets the tenant role, schema search path, and UTC timezone. User input never selects a tenant schema directly.
Make AI propose instead of apply
Tony, the embedded AI co-counsel, can read approved context and stage proposed changes, but a human must confirm writes. Money movement, role changes, destructive bulk actions, and similar high-risk operations stay hard-denied.
Keep legal operations dense and scan-friendly
The React interface favors familiar tables, tabs, modals, and operational status over oversized marketing patterns, so attorneys and staff can find the next action quickly.
Treat ledgers and audits as permanent records
Financial history and audit trails are designed as append-only records, preventing broad update or delete access from rewriting what happened.
Run expensive AI work as durable jobs
Long-running AI tasks use persisted jobs with server-computed progress, cancellation, orphan recovery, and cost accounting instead of fragile browser-held requests.
Outcome
What came out of it.
Outcome
- Established a cohesive product architecture spanning matter management, legal operations, billing, trust accounting, documents, public workflows, email, and AI assistance.
- Built around schema-per-tenant Postgres isolation with separate tenant and administrative control planes.
- Defined a human-confirmed AI workflow that can assist with data capture without receiving unrestricted write authority.
- Connected the main React application, Go API, document renderer, Outlook task pane, and deployment topology as distinct but coordinated services.
Lessons
- Security boundaries are easier to preserve when they are architectural defaults instead of checks repeated ad hoc in every feature.
- Legal software needs explicit review states because convenience cannot come at the cost of traceability or professional judgment.
- A small team moves faster when source-of-truth rules, verification commands, and ownership boundaries are written down clearly.
Next
- Continue closing the gap between broad practice-management coverage and polished daily workflows.
- Expand verification around tenant isolation, financial invariants, documents, email, and AI-staged actions.
- Keep refining the interface around speed, clarity, and error recovery for real legal work.
Keep browsing
Keep moving through the archive or reach out if you want to talk through similar work.