Gepard Finance: Building a Real-Time Mortgage Comparison Platform
How we built Gepard Finance: the product decisions, live banking data challenges, and UX choices that shaped a real-time mortgage comparison tool.

The Problem Was Not Technology. It Was Time.
A homebuyer in 2024 had one job before signing anything: compare mortgage rates. Simple in theory. In practice, it meant calling six different banks, waiting on hold, speaking to six different loan officers who each quoted rates using slightly different assumptions, and then trying to reconcile all of that information on a spreadsheet before any of the numbers expired.
By the time a buyer finished that process, the rates had changed. The window had closed. They were starting over.
That is the problem Gepard Finance was built to solve. Not a marginal improvement on the existing process. A replacement for it.
What We Were Actually Building
On the surface, Gepard Finance is a mortgage comparison platform. A buyer enters their details once and sees live rates from multiple lenders, side by side, in real time.
Under the surface, it is a data orchestration problem wrapped in a trust and clarity problem.
Pulling live rate data from financial institutions is not like calling an API that returns a clean JSON object. Lenders expose data in different formats, on different schedules, with different rate structures depending on loan type, credit tier, and down payment percentage. Some of it is genuinely real-time. Some of it is refreshed every four hours and presented as live. Building a system that accurately represents what is current, without misleading a buyer, required decisions that were more editorial than technical.
We had to decide: when data is 90 minutes old, do we show it? Do we flag it? Do we suppress it entirely? There is no universally correct answer. We chose to display the data with a visible timestamp and a clear indicator of when it was last verified, and we built a background refresh cycle that prioritized the lenders buyers interacted with most.
The Technical Decisions That Shaped the Product
The architecture had to handle three things simultaneously: high-frequency data ingestion from multiple sources, a responsive front-end that updated without full page reloads, and enough stability that a buyer could walk away for ten minutes and come back to a state that still made sense.
We built the data layer with a service that normalized incoming lender data into a consistent internal schema. Every lender's rate came in with different field names, different date formats, different assumptions baked into the APR calculation. The normalization layer stripped all of that and converted it into a structure the front-end could consume without needing to know anything about the source.
For the front-end, we used real-time updates scoped to the specific loan parameters a buyer had entered. A buyer looking at a 30-year fixed on a $420,000 home with 10% down did not need to receive updates for products that did not match their scenario. Scoped subscriptions kept the interface responsive and kept the noise out.
The part we rebuilt twice was the rate comparison card itself. The first version displayed every available data point: APR, monthly payment, origination fee, points, lender name, rate lock period. It was accurate. It was also impossible to read. Buyers told us they felt more confused after seeing the comparison than before.
We stripped it back. The second version led with monthly payment and total interest paid over the loan term. Everything else moved to an expandable detail view. Completion rates on the comparison flow went up significantly after that change. Accuracy did not suffer. Clarity did the work that information volume could not.
What the Final Experience Looks Like
A buyer lands on Gepard Finance, enters their target purchase price, down payment, credit score range, and loan type. That is the full intake. No account creation required to see rates.
Within seconds, they see a ranked list of offers from participating lenders, sorted by monthly payment by default with the option to re-sort by APR or total cost. Each card shows the lender name, rate, monthly payment, and a last-verified timestamp. Tapping any card expands the full breakdown.
Buyers can adjust their parameters without re-entering everything. Changing the down payment from 10% to 15% updates the comparison in real time. That single interaction, watching the monthly payment drop as the down payment increases, teaches a buyer something about their own financial position that six phone calls and a spreadsheet never could.
For buyers who want to move forward with a lender, the platform surfaces a direct contact path without pushing them into an opaque referral funnel. The lender relationship stays visible throughout.
What We Learned Building This
Data freshness is a product decision, not an infrastructure problem. How you communicate data age to a user matters more than how fast you can refresh it. Buyers forgave a 90-minute-old rate when we told them clearly. They lost trust when we implied it was live and it was not.
Simplicity in financial interfaces is earned, not assumed. Every piece of information we removed required a reason and a test. Some things we removed came back after buyer feedback. The process was iterative and uncomfortable in the right ways.
Trust in fintech is built through transparency, not through polish. A clean interface that hides how rates are sourced does not convert. An interface that explains its data sources, shows timestamps, and gives buyers control converts better.
The Practical Takeaway
If you are building anything in fintech or real estate tech right now, start with the moment of highest anxiety in your user's journey. For homebuyers, that moment is the comparison. For your product, it may be something else entirely.
Find that moment. Build for the feeling, not just the function. Then test whether your design reduces anxiety or just rearranges it.
That is where Gepard Finance started. That is where every financial product worth building should start.


