A researcher spends 30 seconds doing peptide math before every injection. I built a tool that does it instantly. Here’s the surprising thing I learned: for a calculator tool, SSR isn’t about performance — it’s about whether Google even knows your calculator exists.
The Problem I Was Solving
If you’re not familiar with peptide research: researchers reconstitute lyophilized (freeze-dried) peptides by adding bacteriostatic water, then draw specific doses into insulin syringes. The math isn’t hard — it’s just annoying:
- “I have a 10mg vial, added 2ml of water, I need 250mcg per dose — how many units on a 0.3ml syringe?”
- “I’m running BPC-157 and TB-500 together, different vials, different doses — what are my draw volumes?”
Most researchers use Excel or a notepad. Some use existing peptide calculators, but they’re often buried in affiliate-heavy blogs or wrapped in ads. I wanted something clean, fast, and free — so I built bpc157calculator.com.
Why I Didn’t Build a SPA
This is the core architectural decision, and it might be counterintuitive.
A calculator tool looks like the perfect SPA candidate: a few inputs, some math, update the DOM. React state, useEffect, ship it. I explicitly chose not to do that.
Here’s why:
The SSR realization
When someone searches “BPC-157 dosage calculator,” Google doesn’t execute JavaScript before ranking the page. A CSR calculator sends Google an empty
Google does render JavaScript now, but:
- It adds delay — sometimes hours or days
- It’s a second pass, not the primary crawl
- The rendering budget is limited — if your JS bundle is heavy, Google might not fully render it at all
With Next.js SSR, every page delivers fully rendered HTML on first request. The
, the calculator labels, the semantic structure — all present in the raw HTML. Google doesn’t need to run your JavaScript to understand your page.
What this means for a calculator tool specifically
A blog post about peptides can get away with CSR because the article text is in the HTML. But a calculator? The entire value proposition is the interactive widget. If Google can’t see it, Google doesn’t know what to rank you for.
SSR is not a performance optimization here. It’s a content delivery mechanism. The calculator is your content, and SSR delivers it to crawlers the same way it delivers it to users.
The Stack
| Layer | Choice | Why |
|---|---|---|
| Framework | Next.js 14 (App Router) | SSR by default, no config needed |
| Hosting | Cloudflare Pages | Edge deployment, free tier, instant cache invalidation |
| CSS | Tailwind CSS | Utility-first, tiny bundle |
| State | URL search params | Calculator state lives in the URL — shareable, bookmarkable |
| Analytics | GA4 + GSC | Standard. Nothing fancy needed at this stage |
No database. No auth. No API routes. The entire site is static pages + client-side math. The SSR handles the initial HTML; the calculation logic runs in the browser after hydration. Best of both worlds.
Architecture: One Domain, Three Search Intents
The site has threecore pages, each targeting a different search intent:
- bpc157calculator.com — “bpc157 calculator” (brand + generic dosage)
- bpc157calculator.com/reconstitution — “peptide reconstitution calculator”
- bpc157calculator.com/blend — “bpc-157 tb-500 blend dosage calculator”
Semaglutide and other peptides (15+ total) are handled on the homepage via a dropdown selector — no separate routes. This was a deliberate choice: I wanted separate pages only when the search intent was fundamentally different. “Dosage,” “reconstitution,” and “blend dosing” are three distinct intents. “Semaglutide dosage” vs “BPC-157 dosage” is the same intent with a different parameter — that’s what a dropdown is for.
Why separate pages instead of one SPA with tabs?
Because Google ranks pages, not apps.
A single-page app with tabs for “Dosage,” “Reconstitution,” and “Blend” means one URL competing for three very different search intents. Your