Rent vs. Buy Is a Net-Worth Race, and the Model Runs It Openly

The monthly-payment comparison flatters renting. The pride-of-ownership framing flatters buying. The defensible comparison is net worth against net worth, year by year, under assumptions the user can see.

Rent-versus-buy tools mostly fail in one of two directions: they compare a rent check to a mortgage payment (ignoring the equity inside the mortgage payment), or they compare a rent check to nothing (ignoring what a disciplined renter does with the money a down payment did not consume). The Worthune rent-vs-buy model runs the comparison the way an accountant would: two people with identical resources take different paths, and the model tracks both balance sheets to the horizon.

The race, as the spec defines it

The buyer puts the down payment into the house, pays the mortgage, and pays ownership costs — property tax and maintenance, each computed as a rate against the home's appreciating value. The buyer's net worth in any year is the home's current value minus the remaining loan balance.

The renter keeps the down payment invested at the caller's investment return, pays rent that escalates at the caller's rent-growth rate, and — this is the part naive comparisons skip — invests the difference whenever the buyer's annual outlay exceeds the renter's, and withdraws it in years when renting is dearer. The renter's net worth is the portfolio.

The break-even year is the first year the buyer's net worth strictly exceeds the renter's. If that never happens inside the caller's horizon, the field is null — not a sentinel number, just an honest empty.

buy_net_worth = home_value × (1 + appreciation)^years − remaining_loan_balance;  rent_net_worth = portfolio grown at investment_return, seeded with the down payment, fed each year with (buyer_outlay − renter_outlay);  break_even_year = first year buy_net_worth > rent_net_worth (null if never)

What the model excludes, and which way each exclusion leans

The spec's exclusions are not fine print — several of them lean the race in a knowable direction, and an embedder should say so next to the answer.

No selling costs. The buyer's net worth is gross of the six-to-ten percent a real sale consumes in commissions and transfer costs. This exclusion favors buying, and it favors buying most at short horizons — exactly where the decision is closest. A UI that surfaces the break-even year should say the year assumes the buyer never pays a realtor.

No tax modeling. No mortgage-interest deduction (which would favor buying for the minority of households that itemize), no capital-gains treatment on either the house or the portfolio. No purchase closing costs and no PMI, even below twenty percent down — both would charge the buy side. The exclusions run in both directions; the spec's exclusion list names the load-bearing ones rather than netting them silently, and the input list makes the rest visible.

• ✓Selling costs excluded — favors the buy side, most at short horizons.
• ✓Mortgage-interest deduction excluded — favors the rent side for itemizers.
• ✓Purchase closing costs and PMI excluded — favors the buy side.
• ✓Portfolio taxes excluded — favors the rent side.
• ✓Insurance and HOA dues absent from the input list — favors the buy side.
• ✓The renter's portfolio floors at zero — a documented issue that slightly favors renting in extreme cost gaps.

The last item is the kind of disclosure a spec exists for: when the drawdown years run deep enough to exhaust the renter's portfolio, the balance floors at zero rather than going negative — a renter deep underwater stops losing — and the spec's known-issues section records the asymmetry instead of leaving it for a curious integrator to discover.

Domains are opinions, stated

The appreciation input accepts zero to ten percent annually. A caller cannot ask the model about a housing crash — depreciation scenarios are out of domain, and the request is rejected with a structured error rather than silently clamped to zero. That is a scoping decision, stated in the machine-readable contract: the model prices the ordinary range of outcomes, and a stress-test UI should be built as a stress-test UI, not by feeding tail scenarios into a model that documents a different domain.

Since version 1.1.0 the mortgage rate domain starts at zero — promotional and assumed-loan edge cases compute cleanly through the shared zero-rate amortization guard — and years past the mortgage payoff correctly stop charging the mortgage payment while the ownership costs continue.

Reading the response

A call returns the buyer's and renter's net worth at the horizon, the break-even year or null, and the year-by-year comparison series, plus the spec version, an assumptions array naming that version, an empty facts array (the model consumes no tax-year constants), and a record.sha256 over model, spec version, inputs, and outputs. The response's specUrl points at the published spec, where the exclusions above appear under assumptions — one link from any rendered answer to the full contract.

A worked shape, not a verdict

On typical mid-2020s inputs — high price-to-rent markets, mortgage rates above five percent — the race usually opens with years of renter lead, because the buyer's outlay is front-loaded with interest while the renter's portfolio compounds the untouched down payment. Whether the buyer's equity line crosses inside ten years is decided mostly by three inputs: appreciation, rent growth, and investment return. The model's job is not to referee those beliefs. It is to make the beliefs explicit inputs, run both books under them, and return a race the user can re-run under different beliefs in one call each.