How I Built a Mortgage Calculator That Actually Helps People Save $200K+ (Next.js + Real Math)

Wernerpj Jacob — Sat, 17 Jan 2026 16:04:36 +0000

🎯 The Problem: Financial Calculators That Don't Actually Calculate Anything Useful
Last year, I was trying to figure out if I should pay off my mortgage early. I found dozens of "mortgage calculators" online, but they all had the same problems:

Basic math only (principal × rate × time).

No strategy comparison (what if I invest instead?).

Hidden behind email walls (give us your data first!).

No explanation of the math (black box calculations).

The worst part: They don't account for cash flow efficiency (Velocity Banking).

I'm a developer. I understand compound interest. But even I couldn't find a tool that answered: "Should I use a HELOC, make extra payments, or just invest the difference?"

So I built one. And it accidentally turned into a product that's helped 2,000+ users save an average of $142,000 in projected interest.

In this post, I'll share how I built the Mortgage Killer Kit, the tech stack (Next.js 14 + Supabase), the floating-point math nightmares I faced, and why building fintech tools is harder than it looks.

(Disclaimer: I am the creator of this tool. I built it to solve my own problem, and now I share the logic openly.)

📊 The Math That Most Calculators Get Wrong
Before diving into code, let's understand why 90% of mortgage calculators are useless.

The Compound Interest Trap Most calculators use simple formulas that work for car loans but fail for mortgages because they ignore Amortization Schedules.

A mortgage front-loads interest. A $100 extra payment in Year 1 saves significantly more than a $100 payment in Year 20.

To solve this, I couldn't just use a simple formula. I had to build an Engine that simulates the loan month-by-month, reacting to events like "Lump Sum Payment" or "HELOC Injection".

Visualizing the difference between a standard 30-year loan and an optimized strategy

🏗️ The Tech Stack
I needed something fast, SEO-friendly, and capable of handling heavy math without freezing the browser.

Frontend: Next.js 14 (App Router) + TypeScript

Backend/DB: Supabase (PostgreSQL)

Styling: Tailwind CSS + Shadcn UI

Math: Custom Engine + decimal.js

Frontend: Real-Time Reactivity
I wanted the UI to feel "alive". No "Calculate" buttons. As you type, the graph updates.

TypeScript

// app/calculator/page.tsx (Simplified)
'use client';

import { useState, useEffect } from 'react';
import { useDebounce } from '@/hooks/use-debounce';
import { FinanceEngine } from '@/lib/engine';

export default function Calculator() {
const [loanDetails, setLoanDetails] = useState(DEFAULT_VALUES);
const debouncedDetails = useDebounce(loanDetails, 500);
const [results, setResults] = useState(null);

useEffect(() => {
// We run the simulation whenever inputs change
const engine = new FinanceEngine(debouncedDetails);
const calculation = engine.simulateStrategy('velocity_banking');
setResults(calculation);
}, [debouncedDetails]);

return (

);
}
Backend: Why Supabase?
I track anonymous usage patterns to see which strategies win. I use Supabase Edge Functions for complex scenarios that might be too heavy for the client (like Monte Carlo simulations).

TypeScript

// supabase/functions/analyze-scenario/index.ts
import { serve } from 'https://deno.land/std@0.168.0/http/server.ts'

serve(async (req) => {
const { principal, strategy } = await req.json();

// This runs on the Edge, close to the user
const result = heavyMathCalculation(principal, strategy);

// Log anonymous stats
await supabase.from('analytics').insert({
strategy_type: strategy,
savings_projected: result.totalSavings
});

return new Response(JSON.stringify(result));
});

60% of my users are on mobile, so the UI had to be responsive and touch-friendly

🐛 The Bugs That Almost Killed Me
Building a fintech app isn't just about UI. If the math is off by a cent, you lose trust.

Bug #1: The Floating Point Nightmare
JavaScript is terrible at math. Try typing 0.1 + 0.2 in your console. You get 0.30000000000000004. Now imagine compounding that error over 360 months (30 years). The final balance would be off by hundreds of dollars.

The Fix: I migrated all math to Decimal.js.

JavaScript

// ❌ BAD (Native JS)
const monthlyPayment = principal * (rate / 12);

// ✅ GOOD (Decimal.js)
import { Decimal } from 'decimal.js';

const monthlyPayment = new Decimal(principal).mul(
new Decimal(rate).div(12)
);
Bug #2: The "Daily Interest" Trap
Calculators often assume monthly interest. But HELOCs (Home Equity Lines of Credit) calculate interest Daily. I had to rewrite the engine to support mixed-mode calculations (Monthly for Mortgage, Daily for HELOC) to get accurate results.

📈 The Results (Data from 2,000+ Users)
After launching the Mortgage Killer Kit App, I started seeing interesting patterns in the database.

Here is a simplified query of what users are choosing:

SQL

SELECT
strategy_chosen,
COUNT(*) as popularity,
AVG(potential_savings) as avg_savings
FROM user_calculations
GROUP BY strategy_chosen
ORDER BY popularity DESC;
The Data:

Velocity Banking: 42% of users (Avg Savings: $142k)

Extra Payments: 38% of users (Avg Savings: $89k)

Investing Difference: 20% of users

It turns out, when people see the math visualized, they rarely choose to "do nothing".

💡 Lessons Learned
Trust > Features: Users didn't care about dark mode until I added a "Show the Math" button that expanded the full amortization table. Transparency builds trust.

Visualization Sells: A table of numbers is boring. A chart showing the "Freedom Date" moving from 2055 to 2032 is emotional.

Context Matters: I realized the calculator wasn't enough. Users needed to understand why the math works. I had to link the tool back to my Velocity Banking Strategy Guide to close the knowledge gap.

🚀 Try It Yourself
If you are a developer, I challenge you to build your own calculator—it's a great exercise in state management and precision math.

If you just want to check your own mortgage numbers, you can play with the Live Demo I built:

👉 Try the Mortgage Killer App here

Or, if you want to understand the theory behind the algorithm, check out the Full Strategy Documentation.

💬 Discussion
Question for fellow devs: Some developers argue that financial math should always be done server-side for security. I do it client-side (mostly) for instant reactivity and UX. Where do you draw the line between Security vs. UX in fintech apps?

Let me know in the comments! 👇

Forem: Wernerpj Jacob

How I Built a Mortgage Calculator That Actually Helps People Save $200K+ (Next.js + Real Math)