DEV Community: Farbod F.

I ship 135 free tools that never upload your file — as a static site

Farbod F. — Fri, 30 Oct 2026 20:21:30 +0000

I build ToolsByUs, a suite of 135 free browser tools for JSON, PDF, images, video, audio, and text. There is no account, and no server endpoint waiting to receive your file. That last part is the whole design decision — and it shapes everything else about how the site is built.

The rule is narrow, on purpose: your file's contents never leave the browser. The tool runs in your tab, on your machine. That is different from the usual promise of "we delete your files after processing." There is nothing to delete, because the contents were never sent.

A worked example, with a tool you can try in seconds: the JSON Formatter. Paste this on one line:

{"zip":90210,"name":"Ada","active":true,"tools":["json","pdf"]}

Format it with 2-space indent and key sorting, and you get readable, deterministic output — same input, same output, no round-trip:

{
  "active": true,
  "name": "Ada",
  "tools": [
    "json",
    "pdf"
  ],
  "zip": 90210
}

Nothing about that example is special, and that is the point. The formatter, the JSON Schema Generator (it infers Draft 2020-12 schemas from a sample payload), the regex tester, and the JWT decoder all work the same way: paste, process locally, copy the result.

The surprising part is not the formatter. It is the Background Remover. It runs a neural network locally in the browser, via ONNX inference, and returns a transparent PNG — again without uploading the image. A model running in a tab feels like it should need a server. It does not; the cost is paid once, on your machine, when the model loads.

Why a static site? Because a static export cannot quietly gain an upload endpoint later without someone noticing the architecture changed. The site ships in six locales (English, Spanish, German, French, Portuguese, Japanese), with 12 guides and a public changelog, from the same static build. The count breaks down honestly: 113 standard tools plus 22 creator tools, for 135 in total.

Honest caveats — because "private by architecture" still has edges:

Client-side does not mean "no network at all." Your browser still fetches the page itself, and the site notes analytics is configured separately. The guarantee is about file contents, not about every byte your browser exchanges.
Heavy work is bounded by your machine. A very large PDF or image will be slower, and can hit browser memory limits, where a server would just throw more hardware at it.
The background-removal model has to load first. The first run is slower than later runs.
No account means no sync and no saved history. That is a trade-off, not just a feature.
I am not claiming this is open source, and I am not promising "free forever." The site says all tools are free today; that is the claim I can stand behind.

If you work with contracts, payslips, or medical records — the exact cases the Merge PDF page names — the question is not whether you trust a vendor's deletion policy. It is whether your file ever needed to leave your browser at all.

You can try the full suite at ToolsByUs: https://toolsbyus.com — 135 free tools, no signup, file contents processed in your browser.

I priced my side project's LLM bill in 20 lines of JavaScript — here's the token math

Farbod F. — Fri, 30 Oct 2026 19:24:15 +0000

I priced my side project's LLM bill in 20 lines of JavaScript — here's the token math

Adding an AI summary feature to a side project cost me $156 a month at a volume I would have guessed was "basically free." The formula behind that bill fits in one function. The part I got wrong was not the formula — it was which tokens I was counting.

Every LLM API bills the same way: dollars per million tokens, with input and output priced separately. Output costs several times more than input, because generating text is the expensive operation and reading your prompt is cheap by comparison. That much is on every pricing page. What the pricing page does not show you is how fast the "cheap" side adds up when a fixed block of text rides along on every single request.

The billing function

function monthlyCost({ requests, inputTokens, outputTokens, inputPrice, outputPrice }) {
  const inputMillions = (requests * inputTokens) / 1_000_000;
  const outputMillions = (requests * outputTokens) / 1_000_000;
  return {
    input: inputMillions * inputPrice,
    output: outputMillions * outputPrice,
    total: inputMillions * inputPrice + outputMillions * outputPrice,
  };
}

Two counters, two prices. The engineering work is not this function — it is getting honest numbers for inputTokens and outputTokens before you ship, instead of discovering them on the invoice. A rough token estimate for English prose is characters divided by 4; code and JSON tokenize denser, so measure with your provider's tokenizer on real payloads rather than trusting the heuristic for production estimates.

Worked example: 20,000 summaries a month

Say a small app adds an AI summary button. Each summary sends a document plus instructions and gets a short summary back:

20,000 requests a month
2,500 input tokens per request → 50,000,000 input tokens
350 output tokens per request → 7,000,000 output tokens
Illustrative prices: $2.00 per million input tokens, $8.00 per million output tokens

Input cost: 50 × $2.00 = $100.00
Output cost: 7 × $8.00 = $56.00
Total: $156.00 a month — $0.0078 per summary

Less than a cent per summary sounds trivial until you multiply it: at 200,000 summaries the same feature is $1,560 a month, and at that point the line item has a manager. The per-unit cost is the number to design around, not the first month's total.

The figure that surprised me: the system prompt is 20% of the bill

Here is the breakdown I did not expect. Of those 2,500 input tokens per request, 800 are the system prompt — the fixed instructions, formatting rules, and few-shot examples prepended to every call. They never change, they are never the user's content, and they cost:

800 tokens × 20,000 requests = 16,000,000 tokens
At $2.00 per million: $32.00 a month — 20.5% of the entire bill — for text I wrote once

That fixed block is the cheapest money in the whole system to save. Most providers now offer prompt caching: repeated prefix tokens are billed at a fraction of the full input price, commonly around 10%. At 10%:

Cached system prompt: 16 × $0.20 = $3.20 instead of $32.00
Saving: $28.80 a month
New monthly total: $127.20 — an 18.5% cut from one configuration change, no model swap, no quality trade-off

The general rule: any token you send on every request deserves scrutiny proportional to your request count, not its size. A 2,000-token instruction block at 1,000 requests a month is 2 million tokens of pure overhead. The prompt you treat as free because you wrote it once is the most expensive text in your system per word.

Two other multipliers worth modeling before you ship:

Regenerations. Every "try again" is a full new request at full price. If 15% of summaries get regenerated once, that adds 0.15 × $156.00 = $23.40 a month — a 15% surcharge for a button users barely notice.
History growth. Chat-style features resend prior turns with each new message, so input tokens per request grow with conversation length. A feature that looks cheap in a one-turn demo can cost several times more in a real twenty-turn session. If your feature keeps history, model the long session, not the demo.

Honest caveats

Prices move. Model prices drop, tiers change, and cached-input pricing differs by provider. Treat every dollar figure here as an illustrative snapshot, not a quote — plug in your provider's current prices.
Token counts are estimates until measured. The characters-divided-by-4 heuristic is fine for a first pass; real payloads through the real tokenizer are the only honest input to a budget.
The calculator estimates; the dashboard decides. Your provider's usage page is ground truth. Reconcile your estimate against it monthly, and investigate when they diverge — a divergence usually means a prompt grew or a retry loop appeared.
Small volumes, small stakes. At $156 a month, none of this is a crisis. The point is that the structure scales: the same ratios at 100× volume are a budget line, and the fixes (caching, trimming fixed prompts, modeling regenerations) are cheapest to build in before volume arrives.

Run your own numbers

Plug in your request count, your real per-request token counts, and your model's current per-million prices:

AI API cost calculator — free, no signup, runs entirely in your browser.

Count the tokens you send on every request first. They are the ones that compound.

Amortization math in 40 lines of JavaScript: building a mortgage calculator with zero backend

Farbod F. — Mon, 26 Oct 2026 19:29:03 +0000

A mortgage calculator is one formula, a loop, and a rounding decision. The formula is the easy part. The rounding decision is the one your users will actually notice.

I built a mortgage calculator as a static page — no backend, everything in the browser. The core question it answers sounds trivial: given a loan amount, a rate, and a term, what fixed monthly payment brings the balance to exactly zero? The formula is closed-form, the code fits in under 40 lines, and yet the first version I shipped disagreed with every bank statement I tested it against — by cents. Cents, it turns out, are where calculator credibility lives.

The one formula

The payment that amortizes a loan is the present value of an annuity, solved for the payment:

M = P × r(1 + r)ⁿ / ((1 + r)ⁿ − 1)

P is the loan amount, r is the monthly rate (annual ÷ 12), n is the number of payments. In JavaScript, that is one function:

function monthlyPayment(P, annualRate, years) {
  const r = annualRate / 12;
  const n = years * 12;
  return P * r * Math.pow(1 + r, n) / (Math.pow(1 + r, n) - 1);
}

The schedule — what each payment actually does — is a loop around it:

function schedule(P, annualRate, years, extra = 0) {
  const r = annualRate / 12;
  const pay = monthlyPayment(P, annualRate, years) + extra;
  let balance = P, month = 0, interestPaid = 0;
  const yearly = [];
  while (balance > 0 && month < 1200) {
    const interest = balance * r;
    const principal = Math.min(pay - interest, balance);
    balance -= principal;
    interestPaid += interest;
    month++;
    if (month % 12 === 0 || balance === 0) {
      yearly.push({ year: Math.ceil(month / 12), balance: Math.round(balance * 100) / 100 });
    }
  }
  return { months: month, interestPaid: Math.round(interestPaid * 100) / 100, yearly };
}

That is the whole engine: payment, interest-on-remaining-balance, principal as the remainder, repeat until zero. No backend, no library, no state beyond a balance variable.

Worked example: $300,000 at 6.5% for 30 years

Inputs: P = $300,000, r = 0.065/12, n = 360.

Monthly payment: $1,896.20
Total paid over 30 years: $682,633.47
Total interest: $382,633.47 — more than the loan itself

The first payment breaks down as $1,625.00 in interest and only $271.20 in principal — 85.7% interest. That is not a bank trick; it is what "interest on the remaining balance" means when the balance starts at $300,000. One month's interest on the full amount is $1,625, whatever you do. Each payment shrinks the balance slightly, so next month's interest charge is slightly smaller, and slightly more of the payment reaches principal. The ratio flips slowly, then all at once in the final years.

The figure that surprises everyone

Five years in, you have made 60 payments totalling $113,772.25. Guess the remaining balance: $280,832.93. You have repaid only $19,167.07 of principal — 6.4% of the loan — while paying $94,605.18 in interest. A sixth of the way through the loan in time, and the balance has barely moved.

That front-loading is also why extra payments are so powerful early. Add just $200 a month to the same loan:

Payoff in 277 months (23 years 1 month) instead of 360 — about 6 years 11 months early
Total interest falls to $279,184.67
Interest saved: $103,448.80

Two hundred dollars a month — roughly a 10.5% bump on the payment — erases more than a quarter of the total interest. The same $200 in year 25 mostly replaces payments you would make anyway. Extra principal attacks the balance when the interest charge is largest, which is exactly when the balance is largest: at the start.

(Shortening the term does the same thing from the other direction: the same $300,000 at 6.5% over 15 years costs $2,613.32 a month — only 1.38× the 30-year payment — but total interest collapses from $382,633.47 to $170,397.98.)

The cents problem

So why did my first version disagree with bank statements? Because a bank rounds every month's balance to cents, and my loop did not. Run the loop in raw float64 and the final balance lands a few cents from zero; a statement, rounding monthly, lands exactly on zero with a slightly different interest total. Neither is "wrong" — they are different rounding policies — but a user comparing your calculator to their statement will trust the statement.

The rules I shipped with:

Round the displayed balance to cents every month, exactly like a ledger does. Do not round intermediate interest to cents and then feed it back into a second calculation — pick one policy and document it.
Clamp the final payment. Math.min(pay - interest, balance) is the line that keeps the last payment from overshooting and the balance from going negative by $0.03. Without it, your schedule ends with a phantom final month.
Never compare the balance to zero with ===. After 360 float operations, balance === 0 is a coin flip. Loop while balance > 0.005 (half a cent) or, better, do the whole schedule in integer cents.
Round once at display, or in cents throughout — never both inconsistently. Mixing a cents-rounded balance with a float-rounded interest total is how you get a schedule whose column sums disagree with its own total by a dollar.

Honest caveats

This is principal and interest only. A real monthly housing payment adds property tax, homeowner's insurance, and possibly PMI — often 25–40% on top of the P&I figure.
Rates here are illustrative. Your rate, down payment, and term change every figure above. The shape — interest-heavy early, principal-heavy late — never changes for a fixed-rate loan.
Extra payments are not always optimal. If your rate is below what you would earn investing, or you lack an emergency fund, extra principal may not be the best use of the money. This article shows what the math does, not what you should do.
Adjustable-rate loans differ. Everything here assumes a fixed rate. ARMs reset, and the schedule has to be rebuilt at each reset.

Run your own numbers

Plug in your price, down payment, rate, and term, and see exactly where every dollar of every payment goes:

Mortgage calculator — free, no signup, runs entirely in your browser.

The bank already ran these numbers. Now you have the loop too.

Floating-point money math: getting compound interest right in the browser

Farbod F. — Thu, 22 Oct 2026 19:35:33 +0000

A compound-interest calculator is one formula and about forty lines of JavaScript. The formula isn't the hard part. The hard part is that money has cents, and your floats don't.

I built a compound-interest calculator as a static page — no backend, everything in the browser. The core is a single line of math. But shipping it meant answering a question I hadn't expected to care about: how do you keep 360 months of floating-point arithmetic from lying about somebody's retirement?

The one line

Future value of a monthly contribution is the standard annuity formula:

FV = PMT × (((1 + r)ⁿ − 1) / r)

PMT is the monthly payment, r is the monthly rate (annual ÷ 12), n is the number of months. That's it. The calculator takes $500/month, 7% annual, 30 years, and evaluates this in the browser. Simple — until you check the cents.

Worked example: $500 a month for 30 years

Inputs: PMT = $500, r = 0.07/12 ≈ 0.0058333, n = 360.

Future value: $609,985.50
Total contributed: $180,000
Interest earned: $429,985.50 — more than double what was put in

Now the figure that surprises everyone: run the same calculation for 20 years instead of 30. Future value: $260,463.33. So waiting ten years to start — contributing $120,000 instead of $180,000 — costs $349,522 of the final balance. The extra decade runs on only $60,000 of additional contributions and produces $349,522 of additional value. Compounding doesn't reward starting big. It rewards starting early, and the reward curve is steeper than intuition allows.

(Also worth knowing: 7% "nominal" compounded monthly is actually 7.229% effective annual — (1 + 0.07/12)¹² − 1. If a product quotes you a nominal rate, this conversion is where the small print lives.)

The float traps I actually hit

Trap 1: display. Every JS developer knows 0.1 + 0.2 === 0.30000000000000004. In a calculator, this surfaces as $28.999999999999996 where a user expects $29.00. The fix is old: compute in integer cents, or round exactly once at display time. Never show a raw float as money.

Trap 2: toFixed rounds in ways that surprise people. Try these in your console:

(0.615).toFixed(2) // "0.61" — not "0.62"
(1.005).toFixed(2) // "1.00" — not "1.01"
(2.675).toFixed(2) // "2.67"

This isn't a bug in toFixed. 0.615 in binary floating point is actually 0.61499999999999999111…, so rounding "down" is correct for the number you really have. The bug is in the programmer's mental model: the decimal you typed is not the number you're holding. If your calculator rounds intermediate values with toFixed and feeds the results back into more math, you're compounding representation error on top of interest.

Trap 3: the one I expected to be terrible, and wasn't. I assumed that accumulating month by month in float64 for 360 iterations would drift meaningfully from the closed-form answer. I tested it: the loop bal = bal * (1 + r) + 500 ends at 609985.4978879701; the exact value is 609985.4978879664…. The drift is less than a millionth of a cent. float64 accumulation over a human lifetime is essentially exact. The enemy was never the loop — it's display rounding and naive equality checks (balance === target after 360 float operations is a coin flip; compare with a tolerance, or better, in cents).

Trap 4: your calculator and the bank can both be right and disagree. A bank ledger rounds every transaction to cents. If you model that — round the balance to integer cents each month — the 30-year result is $609,985.57, seven cents above the continuous formula's $609,985.50. Seven cents on six hundred thousand dollars: irrelevant to the user, but if your test suite asserts exact equality against a spreadsheet, this is the kind of thing that makes a test red at 2 a.m. Decide what your source of truth is (I used the closed form, rounded once for display) and document it.

The rules I shipped with

Do money math in integer cents. Multiply inputs by 100 at the boundary, divide by 100 at display. All intermediate arithmetic stays exact for any realistic amount.
Round once, at the edge. Intermediate rounding compounds; display rounding doesn't.
Never compare floats for equality. If you must compare, use an epsilon — or compare integer cents.
Don't trust toFixed for financial rounding unless you've verified the exact binary values involved. For display it's fine; for logic, cents are fine-er.

Honest caveats

7% is illustrative, not a promise. Historical market averages are not a forecast; inflation, taxes, and fees all take their cut, and this calculator models none of them.
Nominal vs. effective matters. Always check which one a product quotes; the 7% → 7.229% conversion above is free money for whoever does the quoting.
The formula assumes clockwork. Real contributions are irregular, rates vary, life happens. The closed form is a planning tool, not a prophecy.

Run your own numbers

Change the contribution, the rate, the timeline — and watch how violently the "start ten years earlier" column moves compared to everything else:

Compound interest calculator — free, no signup, runs entirely in your browser.

Your floats are fine. It's your rounding you should be afraid of.

Pricing freelance dev work: the math behind rate calculators

Farbod F. — Sun, 18 Oct 2026 23:22:55 +0000

Pricing freelance dev work: the math behind rate calculators

Your freelance rate isn't a guess, a vibe, or what the last client offered. It's four inputs and one division. Run them honestly and most devs discover they've been undercharging by a third.

Every freelance developer I know set their first rate the same way: they heard what someone else charged, rounded it, and hoped. It feels like a confidence problem. It's actually an arithmetic problem — one with a formula simple enough to fit in a tweet, and consequences big enough to cost you tens of thousands a year.

The algorithm

A freelance hourly rate has exactly four inputs:

Target annual take-home — what you need to live on, not what sounds nice
Tax rate — you pay both halves now; gross up for it
Annual business expenses — tooling, hardware, accounting, insurance, coworking
Billable hours per year — not 40×52. Nobody bills that.

gross_needed  = target / (1 − tax_rate) + expenses
billable_hrs  = billable_hrs_per_week × working_weeks
hourly_rate   = gross_needed / billable_hrs

That's the whole calculator. The interesting part is what happens when you plug in honest numbers instead of aspirational ones.

Worked example: $95,000 take-home

Say you're a developer who needs $95,000 a year to live on, in a ~30% effective tax situation, spending $8,000/year on the business (laptop amortized, IDE/services, accountant, a health plan you now buy yourself). And you're realistic about utilization: 22 billable hours a week across 46 weeks (the other 6 are admin, pitching, learning, and the gaps between contracts).

Gross needed: $95,000 / (1 − 0.30) + $8,000 = $143,714
Billable hours: 22 × 46 = 1,012
Rate: $143,714 / 1,012 = $142.01 → call it $142/hour

Now compare: $95,000 as a salary is $45.67/hour (÷ 2,080). The freelance equivalent is 3.11× that. That multiplier isn't greed — it's the entire freelance cost structure made visible: no paid leave, no employer insurance match, unpaid sales work, and income volatility you have to pre-fund yourself.

The rule of thumb that costs you 33%

The folk wisdom says "take your salary and divide by 1,000." For a $95k target that gives $95/hour. The real calculation says $142. The rule of thumb underestimates by a third — because it silently assumes ~1,000 billable hours at zero tax gross-up and zero expenses, which describes nobody.

Rules of thumb are fine for a sanity check. As a pricing method, this one donates ~$47 of every hour you work.

The lever nobody talks about: utilization

Here's the surprising part. Watch what happens to the rate when only the utilization input moves:

22 h/week × 46 weeks = 1,012 h → $142/hour
30 h/week × 48 weeks = 1,440 h → $99.80/hour

A realistic increase in billable hours cuts the required rate by $42.21/hour — nearly 30%. Utilization is by far the biggest lever in the formula: bigger than cutting expenses (halving $8k of expenses moves the rate by ~$4/hour) and bigger than most people expect from "working a bit more."

Which is exactly why the honest calculation matters: when a client pushes back on $142, you shouldn't just cave — you should know which input you're changing. Accepting $100/hour without changing anything else means you've implicitly committed to 30 billable hours a week, 48 weeks a year. Say that out loud before you agree to it.

Honest caveats

Taxes are personal. 30% is illustrative; yours depends on jurisdiction, deductions, and structure. The formula doesn't care — plug in your real number.
This prices your time, not your value. For specialized work with measurable client ROI, value-based pricing can (and should) exceed this floor. Treat the calculation as the minimum, not the target.
It ignores acquisition cost. Landing clients costs time and sometimes money; if 20% of your working hours go to business development, that's already inside the 22-hour billable assumption — make sure it is.
Rates are sticky. Raising rates on existing clients is harder than setting them right at the start. Run this before the next proposal, not after the next invoice.

Run your own numbers

Four inputs, one division — but your inputs are yours. Plug in your real target, your real tax situation, your real expenses, and your honest billable hours:

Freelance rate calculator — free, no signup, runs entirely in your browser.

Undercharging isn't humility. It's a math error — and math errors are fixable.

I Ship 61 Calculators as a Static Site in 12 Languages — Here's How

Farbod F. — Wed, 14 Oct 2026 18:16:34 +0000

I Ship 61 Calculators as a Static Site in 12 Languages — Here's How

We're a small team of software engineers, and we run youcancalc.com — a free collection of 61 calculators, localized into 12 languages. No accounts, no backend, no paywall, no tracking pixels. Every calculation happens in your browser. This is a notes-from-the-trenches post about the architecture choices that make that possible, and the ones we'd make again.

The whole thing is static

The site is a statically-exported site: every page is pre-rendered to plain HTML at build time and served as files. There is no application server, no database, no API to keep warm. A calculator page is a document with a script attached, not an app with a backend.

This sounds limiting until you realize what a calculator actually needs: inputs, arithmetic, and formatted output. None of that requires a server round-trip. The result is pages that answer instantly — no spinners, no "computing..." states — and hosting that is boring in the best way.

All computation is client-side

Each calculator page follows the same contract:

Inputs — the user types numbers, picks options.
Instant result — recomputed on every keystroke, locally.
How it works — the formula is printed next to the answer, not hidden.
Worked examples — concrete numbers walked through step by step.
FAQ — the questions people actually ask about this calculation.
Related calculators — the natural next questions.

Because everything runs client-side, there's a privacy property we get for free and take seriously: your inputs never leave your browser. There's nothing to leak because there's nowhere for the data to go. We don't have your numbers; we never did. In an era where every form field seems to phone home, "the architecture makes surveillance impossible" is a stronger guarantee than any privacy policy paragraph.

i18n without a translation department

Twelve locales: English, Spanish, French, German, Italian, Portuguese, Arabic, Dutch, Polish, Chinese, Japanese, Korean. A few things we learned doing this as a tiny team:

Locale-prefixed routes. Every language lives under its own path prefix (/es/, /de/, …), so each locale is a fully crawlable, shareable site — not a JavaScript-swapped afterthought.

Localize everything, including the math. Formulas, worked examples, and FAQs are content, not chrome — they all go through the i18n layer. A French user should read the explanation of compound interest in French, not just the buttons.

Numbers are not universal. This is the bug class that keeps us humble. Intl.NumberFormat exists for a reason: 1,234.56 in English is 1.234,56 in German. Decimal separators, digit grouping, and even digit shapes differ. Every numeric input and output goes through locale-aware formatting and parsing — parse with the locale, never with parseFloat on raw user input.

RTL is a layout commitment. Arabic means right-to-left, and that affects more than text direction: form layouts, example tables, and the visual order of "inputs → result" all need to mirror correctly. We test it; it's the kind of thing that's either right or embarrassing.

What we deliberately don't do

Constraints are features. We don't do accounts (nothing to personalize), we don't do paywalls (the calculators are the product, and they're free), and we don't do tracking (see above: nothing to track with). We also don't have a blog — each calculator page carries its own explanation, examples, and FAQ, so the content lives where the question is asked instead of in a separate content silo.

This keeps the operational surface tiny: no user data to protect, no sessions to manage, no email infrastructure, no A/B testing apparatus watching your mouse. The site is, by construction, a very boring thing to operate. We like boring.

The honest trade-offs

Static has costs and we won't pretend otherwise:

Build time grows with locales × pages. 61 calculators × 12 languages is hundreds of pages per build. It's fine on modern hardware, but it's the thing we watch.
No personalization. We can't remember your last calculation across devices, because we don't know who you are. We consider this acceptable — arguably it's the point.
Client-side means client constraints. Very old browsers and very slow devices get a degraded but functional experience; we keep the client-side script lean and avoid heavy client libraries rather than assuming a flagship phone.
Translation quality is an ongoing process. Machine-assisted translation gets you 90% of the way; the last 10% — idioms in FAQs, culturally specific examples — needs human eyes, and with 12 locales it's never "done."

Why this architecture fits calculators specifically

A calculator is a pure function with a nice UI: same inputs, same outputs, every time. There's no shared state, no feed, no real-time collaboration. The moment you notice your product is embarrassingly parallel and stateless, the correct architecture is usually "files on a CDN." We just took that seriously and stopped there instead of adding a backend out of habit.

If you're building something similar — reference tools, converters, small utilities — our sincere recommendation: start static, compute locally, and only add a server when you can name the specific thing it does that the browser can't. You might be surprised how rarely that day comes.

We're the team behind youcancalc — 61 free calculators, 12 languages, zero tracking. If you build tiny tools on the web, we'd genuinely like to hear how you architect them.