This document is meant to give our development partner an early window into the decisions that need to be made before we build: the integrations we're depending on, the compliance boundaries that shape the product, and the open questions we need to answer together before the first sprint begins. It's a starting point for conversation. We're excited to get this right and happy to provide anything else that would be helpful as we kick off. Consider this an open invitation to raise risks, ask questions, and push back early. That's exactly what this phase is for.
Linked externally via Google Drive.
For property and mortgage data, we are likely integrating with ATTOM Data to automatically populate property details: estimated home value, property type, lot size, year built, tax assessment, existing loan estimates, etc., the moment a user enters their address.
For credit verification, we are likely integrating with Array for a soft credit pull, which does not affect credit score and is only offered after account creation, never before. We need less information and authorization to do this than a hard credit pull.
Note: When we get to stage 4 and the marketplace, we will likely need a hard credit pull, and lenders require a trimerge pull for underwriting. This can get expensive so we will add this in later, once we know the intent is there from the user.
For national mortgage rate benchmarking, we are integrating with Freddie Mac's Primary Mortgage Market Survey (PMMS) to ensure scenario calculations reflect current market conditions. The PMMS publishes weekly every Thursday at noon ET and covers 30-year fixed, 15-year fixed, and 5/1 ARM national averages, derived from thousands of actual loan applications submitted to Freddie Mac: making it the industry standard benchmark.
One important consideration for development: Freddie Mac does not offer a direct public API for PMMS data. The most reliable programmatic access is through the St. Louis Fed's FRED API, which mirrors PMMS data and is freely available. This needs to be confirmed and contracted during discovery as it affects how we build the rate pipeline and cache strategy.
Also worth noting: PMMS rates reflect conventional conforming purchase loans with 20% down and excellent credit: they are national averages, not personalized quotes. Every scenario card must disclose this clearly. This is both a compliance requirement and a trust signal: users should understand they're seeing a market benchmark, not a rate they've been offered.
This is a standard format for loan files in the mortgage industry. This might be outdated slightly as we have to pay for a membership for a current version, which we will do. This is not a now requirement, but we will need to be able to map to this format for the data when we get to the marketplace (P4). This format for the marketplace would allow us to send a loan file to a lender's Loan Operating System with all of the information in a standard format.
We will obtain this week before Monday.
The philosophy behind this is deliberate and worth understanding as a design principle: we want to bring in as much information about the user and their property as possible while asking them to enter as little as possible. The moment someone types their address, the platform should already know their situation. This is the first and most important trust signal PreFi delivers: value before ask, always.
They should not have to give their name, email, or phone number until they're ready to move forward and save their progress or create a profile.
This directly addresses one of the core pain points we are building against: every existing tool in this space requires a user to hand over their name, email, and phone number before receiving anything in return. The Clarity Engine inverts that entirely. The data infrastructure exists to serve the user, not to qualify them as a lead. Design should reinforce this at every step: the experience of data appearing automatically should feel like the platform is working for you, not gathering information about you.
Most platforms collect data because they can. We collect data because someone deserves better.
There is a person: millions of them: who owns a home, suspects they are overpaying, and has no one in their corner. Every system they encounter asks for their name, their email, their phone number before giving them a single thing in return. They have learned, through repetition, that their information is the product. That clarity is something they have to earn after they have already been qualified and handed to someone with something to sell.
We did not set out to build a better mortgage tool. We set out to change what a person feels the moment they ask a financial question they have been afraid to ask.
That feeling: of being seen and told the truth before being asked for anything: is the product. Everything else is infrastructure. And the data architecture is where that feeling is either protected or betrayed.
Every schema decision, every tagging convention, every field mapping is a values decision first and a technical decision second.
In most financial systems, data flows in one direction. The user gives. The platform takes. The value travels upstream: to lenders, advertisers, lead buyers: while the person who generated it walks away with a follow-up call they didn't ask for.
We reverse that flow entirely.
Every data point this platform collects exists to reflect the user's situation back to them with more clarity than they arrived with. ATTOM tells us about the home. Array tells us about their credit position. Freddie Mac PMMS anchors their scenarios to real market conditions. Not bolted together for coverage: a layered portrait of one person and one address, assembled automatically the moment they arrive.
The moment someone types their address, the platform should already know their situation. Not because we are surveilling them. Because we are serving them.
Value before ask. Always. Without exception.
Most teams treat tagging as a technical requirement. We are asking you to treat it as something more.
Every field that enters this system carries one question: whose interests does this serve? Tag it correctly and the answer is always the same: the homeowner's. The system knows where the data came from, who it belongs to, what it means, and where it goes. It cannot be misused because the structure does not allow it.
Each dimension protects something real:
| Dimension | What It Protects |
|---|---|
| Source | The system always knows what it knows and how much to trust it. Confidence lives in the tag. |
| Owner | Anonymous is a promise, not just a setting. The architecture enforces it. |
| Type | Mixing financial data, behavioral signal, and compliance-adjacent fields is not a schema error. It is a trust violation. |
| MISMO Alignment | The homeowner exploring a refinance today may submit a loan file tomorrow. That bridge is built now or rebuilt from scratch at a cost we cannot justify. |
Tagging is the structural expression of our promise to the user. Get it right and the entire platform inherits it. Get it wrong and nothing downstream compensates.
People don't tell you what they need. They show you.
When a user lingers on a scenario card, something matters to them. When they adjust a slider at midnight, they are trying to understand. When they abandon the flow at a specific moment, trust broke: and they couldn't tell you where.
Behavioral and conversational signal, tagged and structured from day one, is how the platform listens. It is how the Oracle learns: not from what users say, but from what they do. Without it, we are shipping a system designed to earn trust with no way to know whether it is working.
Tag the signal. Protect the loop. Build the Oracle on a foundation that compounds.
Most companies treat compliance as the line they cannot cross. We treat it as a belief.
The education-to-advice boundary exists because a person navigating one of the largest financial decisions of their life deserves to be informed, not influenced. That belief has to live in the schema. Every field touching a regulated data type gets tagged at ingestion: not reviewed at launch, tagged at ingestion: because compliance built into the architecture cannot be forgotten, overridden, or missed in a sprint.
We are not building guardrails because regulators require them. We are building them because the user deserves them.
Great companies are not built at launch. They are built in the decisions that happen before anyone is watching.
The schema designed in this phase will still be load-bearing five years from now. The data this platform generates: homeowner goals, financial profiles, behavioral patterns, outcome signals: is a proprietary asset that cannot be purchased or replicated from outside. It compounds with every interaction. It is one of the deepest moats this business will ever build.
But it compounds only if the foundation is clean.
The person at their kitchen table at 10pm will never know your names. They will never see the schema or read the tagging spec. But they will feel it: in whether the platform already knows their situation, tells them the truth, and makes them feel, for the first time, like someone is actually on their side.
That is the why. Build toward it in everything you touch.
People do not distrust mortgages because of the math. They distrust them because of the experience.
Most mortgage systems treat a person like a file moving through a process. Scripts are read. Boxes are checked. Information is collected. Whether the person understands, trusts, or feels ready rarely matters.
That is the experience we are replacing.
With technology built to read how a person feels in real time, give before it asks, recognize who they are, and build trust the way it is actually earned: one honest exchange at a time. Not a chatbot. Not a calculator. A conversation that changes how a person feels about one of the most important financial decisions of their life.
The conversation logic is where that feeling is either created or lost. It deserves the same precision we bring to every other layer of this platform.
The conversation system has three operating components and four behavioral principles. The three components make the four principles possible.
The Advisor reads how the user is feeling at every exchange and shapes everything the platform says in response: tone, pace, complexity, and when to use their name.
The Oracle is the financial intelligence underneath the conversation: the engine that turns a user's situation into real scenarios, real tradeoffs, and real paths forward.
The Three Exchange Rule is the trust gate that governs both. Before the platform asks for anything meaningful, it must first prove itself useful, then intelligent, then worthy of trust: three times, in that order, without exception.
These are not features. They are the operating principles of a conversation designed to earn trust before it asks for anything.
1. Reciprocity creates the opening: it lowers the wall the user arrived with. 2. Personalization creates the relationship: it signals that the platform sees a person, not a session. 3. Giving to Get builds the arc: it earns each next step with something real delivered first. 4. Emotional Intelligence makes all three land: it ensures the right thing is said to the right person at the right moment.
Remove any one of them and the others weaken. Build all four together and the conversation becomes something no other platform in this space has ever delivered.
Every mortgage tool takes first. Name. Email. Phone number. Before a single thing is returned.
People have learned not to trust that exchange. They arrive already closed.
We go first. Property data before we ask for an account. A financial picture before we ask for their goals. A real scenario before we ask for a decision. Every ask feels smaller because of what came before it.
This is not a writing decision. It is an architecture decision. Build it into the sequence or it does not exist.
Technically:
Personalization is not a name. It is full recognition.
A borrower who served in the military should be greeted with their rank. Sergeant. Captain. Colonel. Not because it is a nice touch: because it says this platform sees you, respects what you have done, and is paying attention in a way no other system ever has.
That is the standard. The data exists to make it possible. The conversation engine must be built to use it.
Being present. Being respectful. Knowing who you are talking to before you speak. That is not a feature. That is the whole point.
Technically:
Every step forward is earned.
Address shared → property picture returned. Goal shared → scenarios returned. Account created → saved profile and plan to return to. Credit authorized → validated path with real numbers.
The ask is always smaller than the give that came before it. That is the conversion engine: not a funnel, but a trust arc built one honest exchange at a time.
Technically:
Every other tool cannot tell the difference between a user who is ready to move forward and one who is about to leave because they are lost and do not know how to say it.
We can. And we respond.
Anxious gets a steadier pace. Confused gets a simpler explanation: not more information on top of what did not land. Frustrated gets acknowledgment before anything moves forward. A breakthrough gets a breath before the next step.
This is not a layer added later. It is the layer that makes everything else work.
Technically:
Trust does not form in a single interaction. It forms across three exchanges where the platform proves it is worth listening to.
Before any meaningful ask: account creation, financial information, credit authorization: the system must complete three value exchanges first.
Exchange One: Establish Usefulness. A property address returns a property intelligence summary. The user sees the system knows something real.
Exchange Two: Establish Insight. The next input returns something that makes the user feel understood. An estimate. A scenario. The system is now intelligent, not just useful.
Exchange Three: Establish Trust. The platform delivers something that feels like guidance. A scenario that reframes their thinking. Competence, usefulness, and respect have all been demonstrated.
Only then does the platform introduce a meaningful ask. It does not feel like lead capture. It feels like the natural next step in a conversation that is already helping.
This rule is what separates an advisor from a funnel.
Technically:
No conversation is perfect. Trust will crack at a moment we did not anticipate.
The platform does not push forward when that happens. It stops. It acknowledges. It offers a different path.
Recovery is not a fallback. It is a feature.
Technically:
Every message passes four checks before it reaches the user:
If it fails any one of them, it does not get sent.
When the conversation gets it right: the platform knows who the user is, honors that from the first word, gives before it asks, and meets them exactly where they are: something shifts.
They stop going through a process. They start making a decision. Confidently. On their own terms. With a platform they trust enough to come back to.
That shift is the entire purpose of the Clarity Engine. Everything else in this platform: the financial models, the integrations, the data architecture: exists to create that moment of clarity and trust.
The conversation is how we deliver it. Build it accordingly.
The education-not-advice line, documented clearly enough that engineers can make copy decisions without escalating.
Picture a homeowner who just spent an hour inside the Clarity Engine. They explored three refinance scenarios. They understood their options for the first time. They felt informed and in control.
Then the platform said: "You should refinance now while rates are low."
In that one sentence the platform stopped being an educational tool and became a financial advisor. It told someone what to do with one of the largest financial decisions of their life: without a license, without full knowledge of their situation, and without their explicit consent to be advised.
That is the line. And crossing it: even once, even in a single piece of copy: creates regulatory exposure and breaks the trust the entire product is built to earn.
The line is not complicated. It just needs to be understood clearly and applied consistently: by every engineer, in every copy decision, without escalating.
The platform informs. It never advises. It shows what is possible. It never tells someone what to do. Urgency, pressure, and steering are sales tools. This platform is not a sales tool.
Education is showing a person what exists, what it means, and what the tradeoffs are. It gives them what they need to make their own decision.
Advice is telling a person what to do. It steers them toward a particular outcome.
The Clarity Engine does the first. It never does the second.
A scenario is a modeled financial outcome based on user inputs and market benchmarks. Scenarios illustrate possibilities. They are not predictions or recommendations. This is why scenario language is always safe: as long as it presents, never prescribes.
Education says "here is what this means." Advice says "here is what you should do."
Before any copy goes into the product, ask three questions:
If all three answers are no, the copy is safe.
When in doubt ask: am I showing them or telling them? Showing is always safe. Telling is never safe.
| Situation | Do Not Use | Use This |
|---|---|---|
| Presenting a refinance scenario | "You should refinance now while rates are low." | "Based on current market rates, here is what a refinance could look like for your situation." |
| Showing a payment comparison | "This option will save you the most money." | "This scenario shows a lower monthly payment. Here are the tradeoffs." |
| Presenting multiple scenarios | "Option 2 is the best choice for you." | "Here are three paths. Each one has different tradeoffs depending on your goals." |
| Discussing credit impact | "You need to improve your credit score before applying." | "A higher credit score typically unlocks better rate options. Here is what that could mean for your scenarios." |
| Describing a loan product | "A 15-year loan is better if you want to build equity faster." | "A 15-year loan typically builds equity faster and carries a lower total interest cost. Here is how that compares to a 30-year in your situation." |
| Responding to a user goal | "To pay off your home faster you should choose this option." | "If paying off your home faster is the goal, here are the scenarios that align with that." |
Education presents. Advice prescribes. The platform always presents.
Every scenario card, every calculation result, and every rate-based output carries a disclosure. This is not optional: it is a trust signal that tells the user exactly what they are looking at.
Standard disclosure for scenario cards:
Scenarios are based on current market benchmarks and estimated inputs. They are for educational purposes only and do not represent a loan offer, rate guarantee, or financial recommendation. Actual terms will vary based on verified financial information and lender approval.
Standard disclosure for rate-based outputs:
Rates shown reflect the Freddie Mac Primary Mortgage Market Survey weekly average. They are national benchmarks, not personalized quotes. Your actual rate will depend on your credit profile, loan type, and lender.
Rules:
These are not permitted anywhere in the product regardless of context:
If any of these appear during development, flag and rewrite before shipping. No exceptions.
When in doubt, reach for these:
Compliance constraints do not limit what the platform can say. They sharpen it.
A platform that educates without steering is a platform the user can trust completely. They know the scenarios are honest. They know the platform is working for them. They know no one is pushing them toward a decision that benefits the platform more than it benefits them.
That trust is the product. Compliance is not what limits it: compliance is what protects it.
Every engineer who writes copy for this platform is not just following rules. They are protecting the relationship between the platform and the person using it.
The education-not-advice line is both a legal boundary and a trust boundary. Every word in this product must stay on the education side of that line.
Primary: David Kawata
Secondary: Sydney Bocik, Ken Bartz
PreFi does not have an existing brand. Purlend has an existing website, but we are likely going to want to change this. We will need to be able to support this brand fork at some point which we can discuss during discovery.
Our technical partner is Everett & Co. We are kicking off as soon as possible which will consist of a 4-week plan. There are items that will overlap with development in their SOW timeline, so we are looking to align design and development early on in the process to avoid overlap.
This is a discussion we want to have on day one of kickoff. At minimum we think it's best to have a shared review cadence, agreed handoff formats from Figma or Lovable including component specs and animation timing, and a clear owner for flagging when a design decision has technical implications that need to be resolved before implementation.
The PRD defines the full build order across P1 through P4. For kickoff, the focus is P1 Core: the anonymous experience: which must work completely on its own before anything else layers on top. During the 4-week discovery phase, design and development will overlap. The intention is to align on the P1 Core architecture and data model during discovery so that when design delivers components, development is ready to receive them without rework. Anything that doesn't depend on a design decision: the math engine, the rate pipeline, the property data integration: can begin in parallel.
Roam (meeting and chat functions), Figma, GitHub, Lovable, Jira, Confluence, Notion. For a document repository, we can set up a Google Drive folder for this project.
Now: Proving the Empowerment Model (P1 & P2)
PreFi and Purlend are building the Clarity Engine together. The first expression of that engine is PreFi's anonymous refinance exploration experience: a homeowner enters their property address, the platform hydrates their situation automatically, an AI conversation understands their goals, and scenario cards show parallel paths with no ranking, no steering, and no lead capture before value is delivered. Just clear benefits and tradeoffs that are hyper personalized.
This is not a prototype. It is a production Alpha product built API-first, as a standalone service, so that every component we ship today can be distributed, white-labeled, and embedded independently tomorrow. The conversation engine, the scenario math, the emotional intelligence layer, the property data hydration: each is its own service.
P2 follows immediately after beta validates the model: PDF reports, shareable scenarios, advanced calculators, and refinement trained on real user data. At this stage, we are not focused on monetization of the end consumer. That will come in P3 or P4.
Next: Extending the Engine (P3 & P4)
P3 extends the Clarity Engine into ongoing homeowner value. PreFi stops being a one-time refinance exploration tool and becomes the homeowner's ongoing advisor: property tax optimization, insurance intelligence, equity strategy, and proactive opportunity alerts. P4 is the marketplace and undefined monetization layer.
The Later: A Fork, Two Brands, One Engine
P3 or P4 is where PreFi and Purlend begin expressing their distinct identities at full scale. PreFi is B2C. Purlend is B2B2C.
The Later+: Purlend: The Digital Lending Highway
Purlend's vision is the Digital Lending Highway: a full-funnel platform, from Search to Settlement, that brings verified affordability and real underwriting intelligence to the very start of the home financing journey. The platform runs on three rails: Structure → Search → Settle.
| Pedro Martins Vieira | Solutions Architect |
| Lucas Menegazzo | Delivery Manager. Primary operational point of contact, owning sprint cadence, weekly reports. |
| Vinicius Afonso Raimundo Ferreira | UX/UI Designer. Responsible for translating the Calm Confidence experience language into something people actually feel. |
| Rian Martins Fonseca | Backend Development |