RepairOrReplace

RepairOrReplace is a Next.js web app that answers a deceptively hard household question: when a major appliance breaks, is it economically rational to pay for the repair, or to replace the unit? Instead of the usual folk heuristics ("if the repair costs more than half of a new one, replace it"), it runs a transparent financial model — a Weibull reliability estimate of remaining useful life, a risk-adjusted expected repair cost, a localized energy sub-model, and an equivalent-service Net Present Cost comparison — then returns a plain-English verdict with every number sourced and shown. It refuses to fake precision: vague inputs lower a confidence score, and predatory quotes suppress the verdict entirely in favor of "get a second opinion."

Canonical origin: https://www.repair-or-replace.net, defined once in lib/site.ts.

---

The problem it solves

Appliance repair-or-replace advice is dominated by rules of thumb that ignore the factors that actually decide the math:

• Age and failure risk. A single "average lifespan" number is misleading. An aging machine's other components are just as old, so the real cost of a repair includes the elevated odds of a second failure soon after.
• Regional cost variation. A repair that is fairly priced in Miami can look like gouging in Minneapolis, because retail service prices track the local field-labor market.
• Energy and efficiency. In high-utility-cost states, the operating savings of a modern efficient unit can flip the decision toward replacement — a factor generic advice columns omit.
• The time value of money. Repair and replacement have different service lives, so comparing them fairly requires discounting cash flows over a common horizon, not summing sticker prices.
• Safety and trust. Gas, high-voltage, and refrigerant work carries real physical risk, and inflated quotes are common. Good advice has to hard-stop on hazards and flag predatory pricing rather than confidently mislead.

RepairOrReplace models all of these and presents the result with full provenance, so a homeowner (and, later, a landlord or a technician) can make the call with evidence rather than a guess.

---

Features

• Evidence-based verdict — repair, replace, or uncertain, with a headline, a plain-English explanation, and a 0–100 gauge position.
• Weibull remaining-useful-life model — conditional survival at 12/24/36 months and a median-remaining-life estimate, fit per (category, brand tier).
• Risk-adjusted repair cost — the entered quote plus the modeled cost of a likely near-term second failure, both driven by the same reliability curve.
• Equivalent-service Net Present Cost — replace-now vs. repair-and-run over a shared horizon, with monthly discounting, a mid-horizon replacement outlay, a terminal residual credit, and a break-even month.
• Localized labor and energy — metro / ZIP / state resolution of BLS labor multipliers and EIA energy rates, with graceful national fallbacks.
• Safety hard-stops — automatic suppression of DIY parts links and tutorials for gas, high-voltage, and refrigerant work; microwaves are always treated as high-voltage.
• Predatory-quote detection — quotes far outside the regional norm suppress a definitive verdict and surface a warning.
• Federal recall lookup — optional CPSC SaferProducts.gov lookup by UPC, fetched live per request with a 5-second timeout; never blocks the economic result.
• Neutral monetization — affiliate and lead-gen placements are computed after and separately from the verdict, and always carry an FTC disclosure.
• Full provenance — every user-facing figure is labeled with its source (NAHB, InterNACHI, BLS, EIA, CPSC).
• Statically generated editorial surface — appliance cost guides and metro cost pages are prerendered from the same engine data the calculator uses, so the published numbers cannot drift from the model.

---

Tech stack

Layer	Choice
Framework	Next.js 16, App Router
UI	React 19, Server Components by default
Styling	Tailwind CSS 4 (CSS-first config, design tokens in app/globals.css)
Language	TypeScript 5.7, strict
API	Next.js Route Handlers under app/api/
Data	In-code TypeScript modules under src/data/ — no database
Tests	Vitest (node environment)
Runtime	Node.js ≥ 22

The calculation core in src/core/ is plain, portable TypeScript with no framework, DOM, or platform dependencies. The same functions run in Vitest and in the Route Handlers, so a passing test is a real guarantee about the API.

There is no database

Every reference figure — lifespans, labor multipliers, energy rates, component cost bands, ancillary costs — is read from a TypeScript module in src/data/ that is compiled into the bundle. There is no SQL, no key-value cache, and no object store in the request path. The only network call the app makes is the optional CPSC recall lookup, and that is best-effort.

Nothing is written to disk, and no request payload, result, or identifier is retained. The one piece of per-client state anywhere in the app is the in-memory rate-limit counter in POST /api/calculate — an IP string and the timestamps of its last few requests, held in a module-level Map inside a single server instance, dropped once those timestamps age out of the 60-second window, and only recorded at all when the deployment sets TRUST_PROXY_HEADER=1. See Guards below.

以上为 README 的开头部分。其余内容请阅读原文。 查看完整 README ↗