Forem: Akash Singh

One Jinja2 template, 147 calculator pages — here's the architecture

Akash Singh — Thu, 19 Mar 2026 06:53:58 +0000

Last month someone on Dev.to asked how many templates I use for my calculator pages. When I said "one" they thought I was joking.

I'm not. One Jinja2 template renders 147 different calculator pages. BMI calculators, unit converters, loan estimators, percentage tools — all the same HTML file. Here's the pattern that makes it work.

The problem with 147 separate files

Imagine this: you want to change the layout of your calculator result section. With 147 separate template files, that's 147 edits. Miss one and now your kilometers-to-miles converter has a different layout than everything else. And good luck catching that in code review.

I learned this the painful way. My first 20 calculators each had their own template. By calculator 21, I was copy-pasting so much that I introduced 3 different bugs from stale HTML. Something had to change.

The architecture (4 layers)

The whole pattern comes down to four layers:

URL request → Route handler → Data config → Universal template → Page

Let me walk through each one.

Layer 1: The route handler

One FastAPI route catches every calculator URL:

@router.get("/{category_slug}/{calc_slug}", response_class=HTMLResponse)
async def calc_tool(request: Request, category_slug: str, calc_slug: str):
    calc = CALCULATORS.get(calc_slug)
    if not calc or calc["category"] != category_slug:
        raise HTTPException(status_code=404, detail="Calculator not found")

    cat = CALC_CATEGORIES.get(category_slug, {})
    related = get_related_calculators(calc_slug)

    return templates.TemplateResponse("calc_tool.html", {
        "request": request,
        "slug": calc_slug,
        "calc": calc,
        "category_slug": category_slug,
        "category": cat,
        "related": related,
    })

That's it. /calc/length/cm-to-inches, /calc/health/bmi-calculator, /calc/finance/percentage-calculator — they all hit this same function. The URL tells it which data to pull, and the template handles the rest.

Layer 2: The data configuration

This is where the magic actually lives. Every calculator is a Python dictionary:

CALCULATORS["bmi-calculator"] = {
    "category": "health",
    "type": "multi_input",
    "title": "BMI Calculator",
    "h1": "BMI Calculator — Body Mass Index",
    "inputs": [
        {"id": "weight", "label": "Weight", "unit": "kg",
         "placeholder": "70", "type": "number"},
        {"id": "height", "label": "Height", "unit": "cm",
         "placeholder": "175", "type": "number"},
    ],
    "formula_js": "weight / Math.pow(height / 100, 2)",
    "result_label": "Your BMI",
    "result_unit": "kg/m²",
    "ranges": [
        {"max": 18.5, "label": "Underweight", "color": "#38bdf8"},
        {"max": 24.9, "label": "Normal weight", "color": "#22c55e"},
    ],
    "faq": [
        {"q": "What is BMI?", "a": "BMI is a measure..."},
    ],
}

Notice the formula_js field — that's a JavaScript expression stored in Python config. The template injects it into a <script> tag on the page. The browser does the actual math. My server never touches user data.

Layer 3: Auto-generating converters

Manually writing 147 of those dictionaries would defeat the purpose. So I wrote helper functions that generate converter pairs automatically:

def _pair(cat, from_name, from_abbr, from_slug,
          to_name, to_abbr, to_slug, factor):
    """Generate BOTH directions of a converter."""
    s1, d1 = _conv(cat, from_name, from_abbr, from_slug,
                   to_name, to_abbr, to_slug, factor)
    s2, d2 = _conv(cat, to_name, to_abbr, to_slug,
                   from_name, from_abbr, from_slug, 1.0 / factor)
    return [(s1, d1), (s2, d2)]

One line of code creates two calculators. "cm to inches" and "inches to cm" from a single _pair() call. 12 pairs give me 24 length converters. Do that across length, weight, temperature, volume, area, speed, data, and time — and you get most of those 147 pages from maybe 80 lines of config.

Layer 4: The universal template

The Jinja2 template branches on calc.type:

{% if calc.type in ['converter', 'temperature'] %}
    <input type="number" id="calc-input" placeholder="Enter value">
    <div id="calc-result-value">—</div>

    {% if calc.quick_table %}
    <table class="calc-ref-table">
        {% for val in calc.quick_table %}
        <tr><td>{{ val }}</td><td>—</td></tr>
        {% endfor %}
    </table>
    {% endif %}

{% elif calc.type == 'multi_input' %}
    {% for inp in calc.inputs %}
    <label>{{ inp.label }} ({{ inp.unit }})</label>
    <input type="number" id="calc-{{ inp.id }}"
           data-var="{{ inp.id }}"
           placeholder="{{ inp.placeholder }}">
    {% endfor %}

{% elif calc.type == 'percentage' %}
    {% for mode in calc.modes %}
    <button class="calc-mode-tab"
            data-formula="{{ mode.formula_js }}">
        {{ mode.label }}
    </button>
    {% endfor %}

{% elif calc.type == 'date' %}
    <input type="date" id="calc-date-input">
{% endif %}

Converters get a single input field with a reference table. Multi-input calculators (BMI, EMI) get dynamic input fields generated from the config. Percentage calculators get tabbed modes. Date tools get date pickers.

One file. Every layout variation handled by {% if calc.type %}.

What's good about this pattern

Adding a calculator takes 30 seconds. I open calculator_data.py, add a dictionary or a _pair() call, and it's live. No new template, no new route, no new JavaScript file.

Consistency is automatic. Change the FAQ layout? One edit, 147 pages update. Change the color scheme? Same. Every calculator looks and works identically because they all render from the same template.

SEO with zero extra work. Each dictionary has meta_desc, h1, and title fields. 147 pages with unique meta descriptions — all generated from the config. Google sees unique content on every page because the FAQs, formulas, and reference tables are all different.

What breaks

I won't pretend this is perfect.

Edge cases get messy. Temperature conversion isn't a simple multiply-by-factor operation (Celsius to Fahrenheit needs (C × 9/5) + 32). I had to add a temperature type separate from converter. Every exception adds another {% elif %} to the template.

The template got long. It started at 80 lines. It's now over 200. Those conditional blocks accumulate. At some point you start wondering if maybe you should split into 3-4 sub-templates.

Debugging sucks sometimes. When a calculator page renders wrong, you have to check: is it the data config? The template branch? The JavaScript formula? The CSS? Four layers means four places bugs can hide.

When should you use this pattern?

If you're building 5 pages that share a layout — probably don't bother. Copy-paste is fine for 5 pages.

If you're building 20+ and they follow predictable variations? Data-driven templating saves you from drowning in maintenance. The rule I follow: when you catch yourself copy-pasting a template for the third time, stop and extract the config.

The calculators hub runs 147 pages on this pattern. Adding number 148 would take me about 30 seconds. That's DRY taken to its logical extreme — and honestly, it's one of the better architectural decisions I've stumbled into.

What's the most DRY thing you've ever built? I'm curious whether anyone else has pushed this kind of template reuse further than they expected.

I built a regex tester that tells you what your pattern actually does

Akash Singh — Thu, 19 Mar 2026 02:54:26 +0000

TL;DR: Regex is powerful and unreadable. I built a tool that takes any regex pattern and breaks it into plain English, piece by piece. Below is how the explanation engine works, plus the three patterns every dev should actually understand.

I wrote this regex last year:

^(?=.*[A-Z])(?=.*[0-9])(?=.*[!@#$%^&*])[A-Za-z0-9!@#$%^&*]{8,}$

Four months later I came back to that codebase. Read the pattern. Had absolutely no memory of what it does or why I wrote it that way.

And I wrote it.

This is the universal regex experience. You understand it for about 20 minutes after writing it, then it becomes ancient hieroglyphics permanently.

So I built a regex tester that doesn't just tell you "match" or "no match" — it explains every piece of the pattern in actual human words. You paste a regex, it tells you what each part does.

Here's how.

How the explanation engine works

Collectively, the regex syntax boils down to maybe 15-20 token types. Anchors, character classes, quantifiers, groups, lookaheads. The engine walks the pattern character by character and classifies each segment.

The core idea is a tokenizer that knows regex grammar:

function tokenize(pattern) {
  const tokens = [];
  let i = 0;

  while (i < pattern.length) {
    if (pattern[i] === "^") {
      tokens.push({ type: "anchor", value: "^", explain: "Start of string" });
      i++;
    } else if (pattern[i] === "$") {
      tokens.push({ type: "anchor", value: "$", explain: "End of string" });
      i++;
    } else if (pattern[i] === "[") {
      const end = pattern.indexOf("]", i);
      const charClass = pattern.slice(i, end + 1);
      tokens.push({
        type: "charClass",
        value: charClass,
        explain: describeCharClass(charClass),
      });
      i = end + 1;
    } else if (
      pattern[i] === "(" &&
      pattern[i + 1] === "?" &&
      pattern[i + 2] === "="
    ) {
      const end = findGroupEnd(pattern, i);
      const lookahead = pattern.slice(i, end + 1);
      tokens.push({
        type: "lookahead",
        value: lookahead,
        explain: `Must contain: ${describeLookahead(lookahead)}`,
      });
      i = end + 1;
    }
    // ... quantifiers, groups, escaped chars, etc.
  }
  return tokens;
}

The describeCharClass function is where it gets interesting. [A-Z] becomes "any uppercase letter." [0-9] becomes "any digit." [A-Za-z0-9] becomes "any letter or digit." It knows common ranges and translates them.

The quantifiers are simpler: {8,} becomes "8 or more times," * becomes "zero or more," + becomes "one or more."

Chain the descriptions together and you get human-readable output.

Let's break down 3 common patterns

Pattern 1: Email (simplified)

^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$

The explanation engine outputs:

^ → Start of string
[a-zA-Z0-9._%+-]+ → One or more: letter, digit, dot, underscore, percent, plus, or hyphen
@ → Literal "@" character
[a-zA-Z0-9.-]+ → One or more: letter, digit, dot, or hyphen
\. → Literal dot
[a-zA-Z]{2,} → Two or more letters
$ → End of string

In plain English: "A string that starts with alphanumeric/special chars, followed by @, followed by a domain name, followed by a dot and at least two letters."

This won't catch every valid email — the actual email RFC is a nightmare that would need a regex the size of a paragraph. But for form validation? This handles 99% of real-world inputs.

Pattern 2: Phone number (US)

^\(?\d{3}\)?[-.\s]?\d{3}[-.\s]?\d{4}$

Explanation engine output:

^ → Start of string
\(? → Optional opening parenthesis
\d{3} → Exactly 3 digits
\)? → Optional closing parenthesis
[-.\s]? → Optional separator (dash, dot, or space)
\d{3} → Exactly 3 digits
[-.\s]? → Optional separator
\d{4} → Exactly 4 digits
$ → End of string

Matches: (555) 123-4567, 555.123.4567, 555-123-4567, 5551234567

The key insight: ? after each separator and parenthesis makes them optional. That one character handles four different phone formats.

Pattern 3: URL

https?:\/\/[\w.-]+\.[a-zA-Z]{2,}(\/[\w./-]*)*

Explanation engine output:

https? → "http" followed by optional "s"
:\/\/ → Literal "://"
[\w.-]+ → One or more: word character, dot, or hyphen (the domain)
\. → Literal dot
[a-zA-Z]{2,} → Two or more letters (TLD)
(\/[\w./-]*)* → Zero or more path segments

The s? at the start is doing the heavy lifting — it matches both http:// and https:// without needing to write the whole thing twice.

The part that surprised me: cron patterns

While building the regex explainer, I realized the same concept works for cron expressions. 0 9 * * 1-5 is equally unreadable for most people.

So I built a cron expression builder that works the same way — paste a cron string, get a human explanation back. "At 9:00 AM, Monday through Friday."

nexuslabs.website/tools/cron-builder — same idea, different syntax.

Why regex explanations matter more than regex skills

I used to think the goal was to get good enough at regex that I could read patterns fluently. After years of writing them, my honest conclusion: nobody reads regex fluently. People who claim they do are either lying or writing only basic patterns.

The practical skill isn't writing complex regex from memory. It's being able to break down any pattern you encounter — in legacy code, in Stack Overflow answers, in config files — and understand what it's trying to match.

That's the gap the tool fills. Not "learn regex" but "understand THIS regex right now."

Try it: nexuslabs.website/tools/regex-tester

Paste any pattern. It breaks it down piece by piece. Runs in your browser — no server, no signup.

What regex pattern took you the longest to debug? I once spent 45 minutes on a pattern that didn't work because of a single backslash. The kind of debugging where the fix is one character but finding it takes your entire afternoon.

I cancelled $25/month in dev tool subscriptions. Here's what I use for free now.

Akash Singh — Sat, 14 Mar 2026 13:53:05 +0000

TL;DR: I was paying for a JSON formatter ($8/mo), JWT decoder ($12/mo), and an API dashboard I forgot to cancel ($5/mo). Built browser-based replacements in a weekend. Zero cost. Data never leaves your machine. Links below.

$300 a year.

That's what I was spending on three dev tools that basically rearrange text.

I sat down one weekend and actually looked at what the $8/month JSON formatter does when I click "Format." It runs JSON.parse() and then JSON.stringify() with indentation.

That's the whole product. Three lines of JavaScript behind a paywall.

So I cancelled everything and built my own. Let me walk you through what I actually use now.

🔧 JSON Formatter — the one I use daily

nexuslabs.website/tools/json-formatter

Before: API response comes back as one massive minified line. Copy it, go to paid formatter site, wait for it to load, dismiss the newsletter popup, paste, format, copy the output.

Now: Paste, format, done. Browser-only. No server involved.

Here's the core logic. Seriously, this is it:

try {
  const parsed = JSON.parse(input);
  output = JSON.stringify(parsed, null, 2);
} catch (e) {
  showError(e.message);
}

Three lines doing the actual work. The rest is syntax highlighting and a copy button.

Why this matters beyond saving $8: Your JSON never hits a server. No "we may use anonymized inputs to improve our service." Everything stays in your browser tab.

🔑 JWT Decoder — because pasting tokens into random sites is sketchy

nexuslabs.website/tools/jwt-decoder

Think about this for a second. Auth tokens contain user IDs, roles, permissions, expiration data. Actual sensitive production data.

And the most common workflow is... paste that into a third-party website?

My decoder splits header/payload/signature, shows expiration as a human-readable date, and flags expired tokens. In the browser. No network call. Under 5 seconds from paste to answer.

I know jwt.io exists and it's fine. But it loads slow and the UI has a lot going on when all I need is: "is this token expired, and what's in the payload?"

📊 CSV to JSON — the one I didn't expect to need

nexuslabs.website/tools/csv-json

Client sends a spreadsheet. Backend expects JSON. Doing this by hand for 200 rows at 4pm on a Friday is the kind of task that slowly erodes your will to keep programming.

This converter handles headers-as-keys mapping, quoted fields, escaped commas — the weird edge cases that break naive parsers. Used it three times last week.

The actual cost breakdown

	Before	After
JSON formatter	$8/mo	$0
JWT decoder	$12/mo	$0
API dashboard	$5/mo	$0
Total/year	$300	$0
Time to build	—	1 weekend

Where I draw the line

I'm not going to pretend free replaces everything. Paid tools earn their price when they provide:

Real infrastructure — monitoring, CI/CD, hosted databases
Team collaboration — actual multiplayer features, not "collaboration" as a checkbox
Complex stateful workflows — Postman with environments and variables for teams

My rule: if the tool transforms data locally with zero server logic, you probably don't need to pay for it. If it manages infrastructure or requires persistent storage, the subscription might be justified.

Quick sanity check for your own subscriptions

Look at your credit card statement. Find the dev tool charges. For each one, ask:

Does this tool need a server, or is it computing everything in my browser?
Am I sending sensitive data to a third party for no reason?
Could I build a basic version of this in an afternoon?

If the answers are "no server needed," "yes," and "yes" — you might be overpaying.

What dev tool subscription are you paying for that you suspect is overpriced? Or the opposite — what paid tool is genuinely worth every cent?

I've been thinking about this a lot since cancelling mine, and I'm curious what other people's lists look like.

I built 500+ free tools in 10 days — here's what actually happened

Akash Singh — Tue, 10 Mar 2026 06:02:23 +0000

It started with a JSON formatter.

I was sitting at my desk at 11 PM, pasting some messy API response into one of those "free online JSON tools" — and the page had 14 ads, two newsletter popups, and a cookie banner bigger than the actual text area. The JSON formatted fine. But I felt gross using it.

So I closed the tab, opened VS Code, and started writing a JSON formatter. No plan. No Notion doc. Just annoyance and caffeine.

How 1 tool became 500

I finished the formatter in maybe 2 hours. And then I thought — okay, I already have this FastAPI route and this Jinja2 template... what if I just add a JSON validator too? Same skeleton, different logic.

That's how it starts. You build one thing and suddenly you're going "well I need a YAML converter anyway for work" and "Base64 encoder would take like 20 minutes" and before you know it you've got 50 of these things.

I hit 100 and genuinely lost count for a few days.

The setup is dead simple. Python route, Jinja2 template, vanilla JS doing the actual work in the browser. Your data never hits my server — not because I had some grand privacy philosophy, but because processing stuff client-side meant I didn't have to worry about server load or storage. Lazy architecture choices that accidentally became a feature.

The parts that sucked

Okay so Google basically pretends my site doesn't exist. 500+ pages, fresh domain, zero backlinks — I submitted my sitemap and... nothing. Like 7 pages indexed out of 500+. That's not a rounding error, that's Google telling you to go away.

Also some of my tools are rough. I'm not gonna pretend otherwise. The percentage calculator works but it looks like something from 2009. I went wide instead of deep and some pages show it.

The thing nobody tells you about building 500 pages? The META DESCRIPTIONS. And OG tags. And making sure nothing breaks on mobile. I spent more time on that nonsense than actually writing code. Building tools = fun. SEO housekeeping = slow death.

Oh and I'm on Render's free tier so the first person who visits after the site goes idle gets a 15-second cold start. They probably think the site is broken. It's not. It's just cheap.

Stuff I did NOT see coming

The kids math games page? Gets more traffic than my JSON formatter. I did not expect that at all. Apparently parents searching "free multiplication practice for kids" is a way bigger audience than devs looking for a regex tester. Who knew.

Also — I have 147 calculators. From ONE template. BMI, loan payments, tip calculator, compound interest, all of them. Same engine under the hood, just different config. The DRY principle taken to its logical extreme.

And the hash generators and encoding tools that I threw in because I needed to fill out the tools page? Those are getting actual usage. The filler content became the main content. I still don't fully understand why.

The stack (for the curious)

Backend: Python + FastAPI
Templates: Jinja2 (server-rendered HTML in 2026, yeah I know)
Frontend: Vanilla JS, bit of Alpine.js where I needed reactivity
Hosting: Render free tier
Database: SQLite for the couple things that need state
Cost: $0. Literally zero.

No React. No Next.js. No Vercel. A Python server spitting out HTML. Old school and it works fine.

Why I'm writing this now

I've been building in silence for a while and honestly? Nobody knows this thing exists. Google doesn't index it. I have no social presence. The tools work but they're sitting in a void.

So I'm trying something different — just writing about what I'm actually doing. What's working, what's broken, what I'm figuring out. No "10x your productivity" stuff. Just... here's what happened.

The whole thing is at nexuslabs.website if you want to poke around. Fair warning, some tools are polished and some look like a hackathon project at 4am. I'm working on it.

But real question — has anyone else done a sprint like this? Built a bunch of stuff in a short window and then had to figure out what to do with it all? What's the craziest thing you've built in under 2 weeks?