Flat Fee MLS Platform
A no-nonsense solution allowing homeowners to list directly on the MLS for a flat fee. I built this to remove the barrier to entry and provide a genuine tool for self-sellers, replacing "lead gen" tactics with an easy to use, no-BS approach. This is a showcase of a few of the technical problems I faced, and how I tackled them.
Layer 01
The UX Challenge
The Volume Problem
Just the listing contract form alone has over 750 possible fields and checkboxes, not all of which are relevant or required. If the whole point of this product is to be no-BS and simple for the users, we definitely can't ask them 18 pages worth of questions. Part of the challenge was filtering out which questions were necessary (not just from a legal standpoint, but to give the user the best chance at a successful listing), and part of the challenge was making the whole experience of filling out a form as pleasant as possible.
Conditional Complexity
The intake form isn't static. It's a state machine that adapts to user input, showing/hiding fields based on previous answers. Redundant questions are cumbersome for the user, and irrelevant questions are a waste of time, so I built smart javascript logic to make sure to keep the users on track.
// Example Logic Rule
if (property.type === 'CONDO') {
requirements.add('HOA_CONTACT');
pages.show('STRATA_DOCS');
}
Layer 02
Data Normalization
Normalization Engine
User input is messy. I integrated with the Google Maps API to validate addresses in real-time and built a parsing algorithm. This ensures that "123 Main St" and "123 Main Street" resolve to the same canonical entity in the database and the pieces of the address are stored in their respective stable keys.
Warning: NEXT_PUBLIC_GOOGLE_MAPS_API_KEY not found.
Layer 03
Stable Key Architecture
The "Rosetta Stone" Architecture
The biggest challenge was bridging the gap between a modern, flexible database schema and the rigid, legacy field names of PDF forms (Acroforms). I created a "Stable Key" system to map user input to the correct database fields.
Layer 04
PDF Assembly
Listing Agreement
The PDF Assembler
The stakes are high - selling a home is a big deal, and it's often the largest financial decision that a person will make in their lifetime, so it's important to get this right. These are legally binding documents, and I have to make sure that the system is robust enough to handle all cases. Once the data structure is in place and the data is captured, we have to make sure that it is properly printed on the document. The RMLS and uploading team require these contracts to be filled out, and our system allows for this to happen in a more user-friendly manner.
I manually created acroform fields on the blank contract template, mapped each stable key to the correct acroform field, and created a script to generate a coordinate mapping of all of the different acroform fields. The system queries the database, pulls the correct data that corresponds to each stable key, and prints it according to the generated coordinate system using 'pdf-lib'.
Try typing to see the PDF update instantly.
Layer 05
Infrastructure
Full Stack Infrastructure
I built the system on a robust, serverless architecture. Next.js handles the frontend and API orchestration, while Supabase provides the relational database and authentication. I integrated external services like Stripe and DocuSign via secure webhooks to complete the functionality.