How I Built a Peptide Dosage Calculator with Next.js — and Why SSR Matters More Than You Think

Jamin — Sun, 26 Jul 2026 02:47:42 +0000

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 <div id="root"> and a JS bundle. The actual calculator UI — the inputs, the labels, the headings that tell Google "this page calculates peptide dosages" — all of that is invisible to the crawler until JavaScript executes.

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 <h1>, 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 <title> can only be one thing. Your <h1> can only be one thing. Google will rank you for one of those intents and ignore the others.

Separate pages let each route have:

Its own <title> matching the exact search query
Its own <h1> reinforcing the topic
Its own meta description
Internal links between them passing relevance signals both ways

Internal linking structure

Homepage
├── Links to Reconstitution Calculator
│ ("Need to reconstitute first? Use our reconstitution calculator")
├── Links to Blend Calculator
│ ("Running a stack? Try the blend calculator")

bpc157calculator.com/reconstitution
├── Links back to Homepage
│ ("Calculated your volume? Now calculate your dose")
└── Links to Blend Calculator

bpc157calculator.com/blend
├── Links back to Homepage
└── Links to Reconstitution Calculator

Every page links to at least two others, forming a tight cluster. Google sees this as a coherent topical group, not isolated pages.

The SEO Decisions That Actually Mattered

1. Semantic HTML over `<div>` soup

Every calculator page uses <section>, <fieldset>, <legend>, <label> — not just for accessibility, but because these elements tell Google about the structure of your page. A <fieldset> with a <legend> that says "Peptide Dosage Calculator" is a much stronger signal than a <div class="calculator-wrapper">.

2. Title tags that mirror search queries

I didn't get clever with branding. The homepage title is exactly what people search:
BPC-157 Dosage Calculator — Free Peptide Reconstitution Tool

Not "BPC157Calculator — The Best Peptide Tool for Researchers." Nobody searches that.

3. URL search params for shareable state

Calculator state (peptide selected, vial size, water volume, dose) lives in URL search params. This means:

Users can share exact calculations via URL
Every state variant is technically a unique URL (though I canonicalize to the base route)
Someone sharing bpc157calculator.com?peptide=tb500&vial=5mg on a forum is creating a de facto backlink with context

4. What I didn't obsess over

Core Web Vitals at launch: Yes, performance matters. But a 95 vs 98 Lighthouse score won't make or break a new site. Ship first, optimize later.
Schema markup for calculators: I added basic WebApplication schema, but it's unclear how much Google actually uses calculator-specific schema. Not worth spending days on.
Blog/content section: I deliberately didn't add one. A calculator tool doesn't need a blog to rank for calculator keywords. Adding thin content pages right now would dilute topical focus. I'll add educational content later, once the core pages are ranking.

Results So Far (Honest Version)

The site has been live for a few days. Here's the unvarnished data from Google Search Console:

8 pages indexed — which is expected. Next.js SSR + a clean sitemap.xml + no JS required for content = Google indexes you fast. This is not impressive; it's just what happens when you don't make Google work hard.
~15-20 impressions/day across ~10 query variations — all variations of "bpc-157 dosage calculator," "peptide reconstitution calculator," etc. Positions ranging from 40-90 (pages 5-9). Zero clicks, which at those positions is mathematically expected.
Queries are dead-on relevant — Google is showing my pages for exactly the terms I targeted. No random "dog food" queries. The intent matching is working.

The honest takeaway: Getting indexed fast is easy if you use SSR. Getting ranked is the hard part, and it takes time and backlinks. I'm in the "Google is testing my pages at position 60-80" phase right now. Here's what I'm doing to move up:

Building backlink signals — submitting to developer directories (Dev.to, Alternatives.to), sharing on Twitter/LinkedIn, engaging in peptide research communities
Not touching the pages — every title/content change resets Google's evaluation. I'm keeping everything frozen for at least 2-3 weeks
Monitoring, not obsessing — checking GSC every 3 days, not every 3 hours

What I'd Do Differently

Pre-launch backlink groundwork. I shipped the site, then started thinking about backlinks. If I'd spent the week before launch preparing guest posts, directory submissions, and community introductions, the backlink signals would have arrived in Google's first crawl, not days later.
More unique copy on calculator pages. The /reconstitution, /blend, and /semaglutide pages share some boilerplate. Google might see them as thin or partially duplicate. Each page should have 200-300 words of unique introductory text explaining the specific use case.
Consider an EMD alternative. BPC157Calculator.com is an exact-match domain for the BPC-157 niche, but it might limit how Google treats my Semaglutide and other peptide pages. A broader name like "PeptideCalc" or "ResearchCalc" would have been more flexible. Tradeoff: EMD gives a ranking boost for the exact phrase; broader name gives room to expand.
GA4 setup before launch. I set up GA4 after the site was already live, missing the first few hours of data. Not critical, but annoying.

Key Takeaways for Other Indie Builders

SSR is not just for blogs and e-commerce. Calculator tools, generators, converters — anything where the UI is the content — benefit enormously from server-rendered HTML.
Separate pages for separate intents. One SPA = one ranking opportunity. Multiple SSR pages = multiple ranking opportunities. The overhead of maintaining a few extra route files is trivial compared to the SEO upside.
Ship, then wait. The hardest part after launching a new site is resisting the urge to tweak everything based on 48 hours of GSC data. Google needs weeks, not days, to evaluate a new domain.
The boring stuff works. Semantic HTML, matching title tags to search queries, clean internal linking — none of it is exciting, but collectively it's what moves the needle more than any "SEO hack."

You can try the calculator at bpc157calculator.com. If you're working on something similar or have feedback on the architecture, I'd love to hear it in the comments.

DEV Community: Jamin