Why I never built a backend for a site with 290+ calculators I run calculate.at , a free site with 290+ online calculators — mortgage payments, BMI, unit conversions, percentages, that kind of thing. No account system, no analytics pixels chasing you around, no backend at all. Every calculation runs entirely in the browser, computed with plain JavaScript on the same page you're looking at. That sounds like an obvious choice for a site that's "just math," but it wasn't the default I started with, and a couple of the decisions that came out of it turned out to matter more than I expected — one for engineering, one for SEO. The case against a backend The first instinct for a "calculator platform" is to reach for an API: POST /api/calculate , validate the inputs server-side, return a JSON result. It's the pattern everyone knows, and for something like a mortgage amortization schedule it even sounds reasonable — there's real math involved. But walking through what that actually buys you for a site like this: Nothing to validate that matters. The worst outcome of bad input to principal * rate / 12 is a wrong number on the user's own screen. There's no shared state to corrupt, no other user affected, no data to protect. No latency wins. A network round-trip to compute bill * (tip / 100) is strictly slower than just computing it. The server can't do the math faster than the browser that already has both operands. No privacy story to worry about. If I never receive the numbers, I never have to think about what happens to them. A backend calculator design usually ends up needing a "we don't log your inputs" line in a privacy policy; here there's nothing to write because there's no server-side code path that could log them. The infrastructure would exist purely to add latency and a failure mode. A calculator that depends on an API call now has an outage mode. A calculator that's a