Studio 1003

Problem

Mortgage teams run their pipeline across five or more disconnected tools: CRM for leads, LOS for loans, a separate doc portal, texting apps, and spreadsheets for tracking. Every handoff between systems creates data gaps, compliance exposure, and lost deals. The industry standard is fragmentation.

The compliance cost of this fragmentation is real. TRID violations, RESPA issues, and audit failures often trace back to data that lived in one system but not another. Teams spend more time managing their tools than managing their pipeline.

Why I built this

I spent years originating loans at Rocket Mortgage, JFQ Lending, and my own brokerage (PHX Lending). I lived inside these broken workflows daily. At PHX Lending, I redesigned our internal systems and cut average close time from 28 days to 12. Studio 1003 takes that operational knowledge and productizes it.

Most mortgage software is built by engineers who’ve never closed a loan. I’ve closed hundreds. That difference shapes every design decision.

Constraints

• Must meet real compliance requirements: TRID, RESPA, state licensing
• Audit trail is non-negotiable. Every state change must be immutable and traceable
• Loan officers are not technical. The UX has to feel as simple as a CRM
• MISMO export compatibility required for LOS integration
• Must handle sensitive PII (Social Security numbers, financial data) with appropriate security

Tech Stack

• Next.js + React for the application layer. Server components handle data fetching securely, keeping sensitive loan data off the client. The App Router provides clean separation between the borrower-facing and LO-facing experiences.
• TypeScript for end-to-end type safety. Mortgage data has dozens of interconnected fields. Type safety prevents the subtle data integrity bugs that cause compliance failures.
• PostgreSQL as the primary database. Relational modeling is the natural fit for mortgage data, where a loan connects to a borrower, property, documents, events, and compliance checkpoints. Foreign keys and constraints enforce data integrity at the database level.
• Supabase for auth, real-time subscriptions, and managed PostgreSQL hosting. Supabase’s auth system handles session management, and real-time subscriptions push pipeline updates to LOs without polling.
• Row-Level Security (RLS) enforced at the database level. Loan officers only see their own pipeline. Branch managers see their team. Admins see everything. Access control isn’t application logic that can be bypassed; it’s a database constraint.
• MISMO (Mortgage Industry Standards Maintenance Organization) data format for export compatibility. Standardized export to any LOS or pricing engine prevents vendor lock-in.
• Tailwind CSS for a clean, professional interface that loan officers can navigate without training.
• Vercel for deployment with preview environments for testing compliance-critical changes before they hit production.

Architecture

• Lead to Loan promotion: Leads only convert to loans when the 1003 application is complete and validated. Every transition is logged with an immutable event. This mirrors the real regulatory boundary between marketing contact and loan application.
• Audit-ready by default: Key actions (updates, promotions, exports) generate timestamped events that satisfy compliance requirements without manual tracking. The audit log is append-only and cannot be modified or deleted.
• Row-Level Security: Access control is a database constraint, not application middleware. Even if the application code has a bug, the database won’t return data the user shouldn’t see.
• MISMO export: Standardized data export to any LOS or pricing engine, preventing vendor lock-in. Loan data stays portable.

Key decisions

• Single system over best-of-breed integration. Consolidation eliminates the data sync problems that cause most compliance failures. One source of truth means one place to audit.
• Event sourcing for audit. Instead of retroactively generating audit logs, every action is an event by default. This makes compliance a natural byproduct of using the system, not extra work.
• Supabase + RLS over custom auth. Leveraging Supabase’s auth and row-level security accelerated development without sacrificing access control rigor. Building custom auth for a compliance-sensitive application as a solo developer would have been reckless.
• LO-first UX. The interface was designed around how loan officers actually work: pipeline view, quick status updates, one-click actions. No training manual needed.

Outcome

Studio 1003 is live at 1003.io, providing mortgage teams a single source of truth for their entire pipeline, from lead to close, with compliance built into the architecture rather than bolted on after the fact. The 28-to-12 day close time improvement from PHX Lending is baked into the product’s workflow design.

Lessons learned

• Compliance is a design problem, not a feature. If you have to remind users to be compliant, the system is already failing. The architecture should make non-compliance harder than compliance.
• Domain expertise is an unfair advantage. Most of the best decisions in Studio 1003 came from my experience as a loan officer, not as an engineer. Knowing that LOs check their pipeline 20+ times a day shaped everything from load time optimization to the default view.
• RLS is worth the upfront investment. Setting up row-level security policies takes more time than application-level checks, but the peace of mind is worth it. Security bugs in application code are common. Security bugs in database constraints are rare.