Mortega: mortgage calculation for property buyers.
A web platform that turns the arithmetic behind a property purchase into something a buyer can actually reason about. Built with Django, Django REST Framework, Celery, HTML and Sass, it models affordability, repayment and the cost of borrowing against a specific property, so the number a buyer sees is one they can act on rather than a teaser rate.
The challenge.
- Buyers were assembling affordability estimates from calculators that each made different assumptions, then discovering the real number only once a lender was involved.
- The arithmetic behind a mortgage is not hard, but it is fiddly, order-dependent and unforgiving of rounding — small modelling errors compound into misleading advice.
- Scenario comparison mattered more than any single result: buyers needed to see how deposit, term and rate interact rather than receive one figure with no context.
- Calculations had to stay correct as the underlying rules and rate assumptions changed, without every change becoming a code release.
Our approach.
- Modelled the calculation domain explicitly in Django — principal, term, rate, deposit and the derived figures — so the arithmetic lives in one reviewable place rather than being scattered across view logic.
- Exposed the calculation engine through Django REST Framework so the same rules serve the interactive UI and any downstream consumer, and so results cannot drift between surfaces.
- Moved the heavier scenario work onto Celery, keeping the interactive path responsive while longer comparison runs complete in the background.
- Built the front end in HTML and Sass with progressive disclosure: a simple first answer, with the full breakdown of how it was reached one interaction away.
- Treated the calculation logic as the part most worth testing, covering the boundary cases — very short terms, very large deposits, rate changes mid-term — where naive implementations quietly go wrong.
The outcome.
- Buyers get an affordability picture tied to a specific property rather than a generic estimate.
- Scenario comparison is a first-class feature, so the trade-off between deposit, term and monthly cost is visible instead of inferred.
- The calculation rules sit in one audited place, which makes changing an assumption a contained edit rather than a hunt through the codebase.
- The platform gives the same answer everywhere it is asked, because every surface calls the same engine.
Where AI fits in real estate & proptech.
Listing copy and imagery generated from property data, key terms pulled out of leases and contracts, and tenant assistants that log and route maintenance requests.
Explore AI developmentAs well as being exceptional technically, they consistently invest the time to understand the product and suggest how it can be enhanced and improved.
Questions about this build.
Still wondering something? Ask an engineer
The engineering work is almost entirely in the domain model, not the interface. We define the calculation — principal, term, rate, deposit, fees and the figures derived from them — as an explicit, single-source module, then expose it through an API so every surface asks the same engine the same question. The interface is deliberately the thin part, because a calculator that gives two different answers in two places is worse than no calculator at all.
By treating the arithmetic as the highest-risk code in the system and testing it accordingly. Boundary cases get the attention: very short and very long terms, unusually large deposits, rounding at each step, and the order in which fees are applied. We also keep the calculation rules separate from presentation, so a reviewer who understands mortgages but not web development can still read and check the logic.
It should, and designing for that from the start is much cheaper than retrofitting it. We keep the assumptions that change — rates, thresholds, fee structures — as configuration rather than embedded constants, so updating them is a data change with an audit trail rather than a code release. That also means a historical result can be reproduced against the assumptions that were live when it was generated.
This one runs on Django with Django REST Framework and Celery, which suits the shape of the problem well: a strong domain model at the centre, an API so the rules are shared rather than duplicated, and a background worker for the heavier scenario runs. The front end is HTML and Sass. The stack matters less than keeping the calculation logic in one place that can be reviewed on its own.
Let's build from here.
Thirty minutes with an engineer who builds. No sales, no drip campaign. If we're the wrong fit we'll tell you and point you somewhere better.