Forem: Stephen Sebastian

Scaling a Privacy-First FinTech Directory to 48k Programmatic Pages with Zero Server Overhead

Stephen Sebastian — Sun, 17 May 2026 18:07:47 +0000

Every developer loves an elegant solution to an ugly legacy problem. My sister lives in the US and recently hit a frustrating wall: her bank had three conflicting 9-digit routing codes listed across various complex HTML FAQ tables—one for local paper checks, one for electronic ACH setups, and another for wire transfers. She guessed wrong, her wire failed, and she got hit with a $35 bank rejection penalty.

When I looked into the landscape of lookup tools, I found they were universally terrible: slow, ad-ridden, 2008-era directory spam that queried heavy databases on every keystroke.

My lead technical architect, Mathew, and I decided to rethink this from scratch. We engineered USRoutingNumber.com—a blazing-fast, local-first financial directory scaled across 48,000 programmatic directory nodes.

Here is a deep technical breakdown of how we optimized the client-side mathematics, automated the crawl-graph generation, and built it to handle massive traffic with zero database cost.

1. The Math: Client-Side Modulo 10 Checksum Validation

Instead of spinning up server instances or executing backend API lookups to verify if a user has entered a valid American Bankers Association (ABA) routing transit number, we moved the primary compute load completely to the client.

Every valid US routing number follows a strict geometric formula established by the Federal Reserve. The first 8 digits encode the federal reserve routing district and institution identity, while the 9th digit is a mathematical check digit.

The validation formula relies on a specific weighted Modulo 10 arithmetic algorithm:

$$3(d_1 + d_4 + d_7) + 7(d_2 + d_5 + d_8) + (d_3 + d_6 + d_9) \equiv 0 \pmod{10}$$

By wrapping this mathematical constant into a high-performance TypeScript validator, our UI checks character inputs locally inside the browser on every single input change. If a typo violates the equation, the execution safely flags it before the user can even attempt to copy the data or initiate a transfer.

Here is the exact production implementation of the verification function:

/**
 * Validates a 9-digit US ABA Routing Transit Number using the Modulo 10 checksum.
 * @param routing The 9-digit routing string input.
 */
export function isValidUSRouting(routing: string): boolean {
  // Enforce strict 9-digit numerical pattern
  if (!/^\d{9}$/.test(routing)) {
    return false;
  }

  const d = routing.split('').map(Number);

  // Apply the Federal Reserve weighted position multipliers
  const checkSum =
    3 * (d[0] + d[3] + d[6]) +
    7 * (d[1] + d[4] + d[7]) +
    1 * (d[2] + d[5] + d[8]);

  // If the result is a clean multiple of 10, the code is mathematically sound
  return checkSum % 10 === 0;
}

2. Architecture: Local-First State & Hydration Safety

Financial searches are deeply personal information vectors. We decided on a strict local-first architecture: we do not log search strings, we do not spin up cloud user accounts, and we do not persist historical queries to a remote relational database.

All state indicators (recent searches, clipboard copy history, and bookmarked credit unions) live entirely inside the user's browser storage using client-side primitives.

However, operating local browser data footprints inside an SSR/SSG environment (like Next.js or automated React builds) presents a classic engineering hazard: Hydration Mismatch Errors. If the server attempts to compile a static component shell while the client layout attempts to parse a unique localized storage key on initial load, the HTML trees break sync.

To solve this, we decoupled the local data sync by creating a dedicated state hook wrapper that defers memory execution until the DOM mounting phase passes:

import { useState, useEffect } from 'react';

export function useLocalStorageState<T>(key: string, initialValue: T): [T, (value: T) => void] {
  const [state, setState] = useState<T>(initialValue);

  // Defer execution until layout mounts safely on the client engine
  useEffect(() => {
    try {
      const storedItem = window.localStorage.getItem(key);
      if (storedItem) {
        setState(JSON.parse(storedItem));
      }
    } catch (error) {
      console.error(`Local state initialization error for key "${key}":`, error);
    }
  }, [key]);

  const setLocalStorageValue = (value: T) => {
    try {
      setState(value);
      window.localStorage.setItem(key, JSON.stringify(value));
    } catch (error) {
      console.error(`Local state persistence error for key "${key}":`, error);
    }
  };

  return [state, setLocalStorageValue];
}

3. Infrastructure Strategy: Scaling to 48,000 Programmatic Nodes

To make this platform highly discoverable across search bots, we had to compile and render discrete programmatic entry paths for over 48,000 active credit unions, regional hubs, and transactional routing numbers across the United States.

If you scale a system like this using a standard monolithic server model, your database read operations will balloon rapidly, causing high infrastructure costs and slow page-load times.

Instead, our approach splits the architecture into an optimized Hub-and-Spoke programmatic data silo:

                  ┌──────────────────────┐
                  │   /blog (Hubs)       │
                  │   High Editorial     │
                  └──────────┬───────────┘
                             │
            ┌────────────────┴────────────────┐
            ▼                                 ▼
┌──────────────────────┐          ┌──────────────────────┐
│  /states/ca (Spokes) │          │  /states/tx (Spokes) │
│  Regional Directory  │          │  Regional Directory  │
└──────────┬───────────┘          └──────────┬───────────┘
           │                                 │
           ▼                                 ▼
┌──────────────────────┐          ┌──────────────────────┐
│ /routing-number/chase│          │ /routing-number/bofa │
│  Programmatic Node   │          │  Programmatic Node   │
└──────────────────────┘          └──────────────────────┘

Data Optimization: The entire database configuration was compiled down into static JSON indices segmented by US state codes and core banking systems.
Dynamic Route Pre-compilation: During the build step, our route manager iterates over these JSON indices, programmatically generating explicit directory endpoints (e.g., /routing-number/first-california-federal-cu).
Hub-and-Spoke Linking Engine: Search engine crawlers can easily get lost in deep datasets. To prevent unindexed orphaned routes, we embedded contextual cross-links directly inside our core informational guides (like our 2026 Credit Union Density Report). These authoritative editorial hubs pass crawl budget down into regional state sub-paths, completely optimizing our site-wide indexing capability.

The Performance Results

By shifting raw computing parameters to the browser and compiling our 48k data layer into a flattened, static layout grid, we achieved highly optimized performance marks:

TTFB (Time to First Byte): Under 25ms worldwide via edge network distribution.
Search Engine Latency: Sub-millisecond string filtering across 48,000 internal matrix references.
Database Hosting Cost: Exact zero. The site scales seamlessly on cloud object storage without requiring live, heavy SQL server instances.

If you are an indie hacker or an engineer looking at automating heavy programmatic directory structures, I would love to hear your thoughts on this stack. Let’s talk architecture in the comments below!

I Stopped Chunking My Logs. Then Gemma 4's 128K Context Found What I'd Missed for Weeks

Stephen Sebastian — Sun, 17 May 2026 14:35:14 +0000

Last month, I had a server log that wouldn’t give up its secret.

Every Tuesday at 3:14 AM, a background job crashed. The same error appeared: context deadline exceeded. No stack. No breadcrumb. Just that smug, silent timeout.
I pulled twelve months of logs. That added up to 3.2 million lines. Roughly 115,000 tokens of pure, messy reality.
My old local LLM capped out at 8K tokens. So, I did what everyone does: I split the file into chunks—January, February, March, and so on.
Each chunk alone looked innocent. February ran fine. March ran fine. Then April showed the timeout, but with no explanation for why. The cause lived in January—a tiny config change that only became critical when combined with a different change in March.
Chunking ruined the connection between them. I was holding two pieces of a broken plate, trying to see how they ever fit together.

The core lesson

Chunking ruins understanding. You can give a model a fragment, but it has no memory of what came before. It's like trying to solve a murder mystery after someone ripped out every third page of the case file.
Then I learned about Gemma 4's 128K token context window.
Numbers like that seem abstract until you put them into perspective. 128K tokens is roughly the entire Lord of the Rings trilogy—all three books—in one prompt. For my log file, that 115,000-token monster would fit with room to spare.
No chunking. No slicing. Just the whole story, start to finish, fed to the model in one go.

Local setup—exactly what I ran

I use Ollama because it's one command and done.


ollama pull gemma4:26b

📊 Debugging Efficiency Analysis

Parameter	Traditional 8K Model (Chunked Approach)	Gemma 4 26B MoE (128K Context Window)
Data Ingestion	12 Separate monthly segments	Single 115,000-token complete file
Analysis Time	3+ Hours of manual cross-referencing	~50 Seconds (Automated execution)
Correlation Range	Limited to isolated 30-day boundaries	365-Day full system timeline
Root Cause Detection	Missed (Isolated chunks hid the drift)	Found (Linked Jan pool drop with Mar backoff)

That’s the Mixture-of-Experts variant. Active parameters per token are around 4B to 8B, but the model's total size is 26B. It runs smoothly on my M1 MacBook Pro with 16GB RAM. (If you have more memory, gemma4:31b is the dense version—smarter but also hungrier.)

Once downloaded, feeding the log file was simple:

cat twelve_months_of_hell.log | ollama run gemma4:26b \
  "Trace the root cause of the recurring timeout. Connect events across the entire timeline."

The model paused for about 50 seconds. Then it provided an answer.

Not with a guess. With a timeline.

"At line 1,450 (January 12), the connection pool size dropped from 50 to 20. At line 58,200 (March 28), the retry backoff changed from exponential to linear. Neither change caused a problem on its own. But by June, traffic doubled. The smaller pool couldn't keep up, and linear retries worsened the backlog. The timeout first appeared on June 3 at line 112,400."
I had spent three days manually connecting those two changes. Gemma 4 did it in one prompt because it saw both ends of the story at once.

The real insight isn’t about length

We talk about context windows like they're just bigger buckets. More storage. But that's not what 128K actually offers.
It provides temporal coherence.
When a model reads a document from beginning to end without artificial breaks, it maintains the sequence. Not just "word A near word B," but "event X happened, then Y, then Z, and because of that, W failed."
That's cause and effect across distance. Chunking destroys it. The model sees fragments, each isolated from the others.
Gemma 4 sees the whole arc. A variable's first appearance, its slow change, its final break—all visible at once.

Tying this back to something real (my contest project)

This exact issue with logs pushed me to build LedgerGuard—my submission for the Gemma 4 Challenge.

I realised that financial ledgers face the same problem. A small business owner's CSV with a full year of transactions is just a log file with dollar signs. Drifting expense categories, slowly changing deduction rules, a questionable transaction in January that only makes sense when you see the context from November.

So, I wrapped Gemma 4's 128K window into a local-first desktop app. You can drag in your CSV or tax PDF. The model scans everything—no cloud, no data leaving your machine. It flags anomalies, suggests deductions, and even runs "what-if" simulations, like "What if I reclassified this $5,000 as marketing instead of office supplies?"
The same temporal coherence that found my config drift now finds tax errors across 12 months of ledgers. All offline. All private.

🔄 LedgerGuard Offline Data Pipeline

[ Raw CSV / Bank PDF Ledger ] 
              │
              ▼ (Native File Dropzone Parsing)
[ Client-Side Browser Memory ] 
              │
              ▼ (Encrypted Local Storage)
[ Local IndexedDB Cache Database ] 
              │
              ▼ (Stateless Local Port Bridge)
[ Node.js Server Environment (server.ts) ] 
              │
              ▼ (Secure Handshake via @google/genai SDK)
[ Local Gemma 4 Engine (Ollama Runtime Sandbox) ] 
              │
              ▼ (Forensic Token Analysis)
[ 🎯 Structured JSON Compliance Audit Matrix Output ]

When to use 128K (and when to skip it)

Here’s my honest take after a month of experimenting.

Use 128K when:

You're analyzing logs, financial records, legal contracts, or long conversations
The order of events is more crucial than any single event
You're tired of playing "connect the dots" across chunk boundaries

🧠 Local Deployment Matrix

Model Tier	Active Parameters	System Memory Req.	Ideal Operational Workload
Gemma 4 2B (Lite)	~2B Parameters	4GB+ RAM	Ultra-mobile devices, isolated edge scripts, quick standalone functions
Gemma 4 26B (MoE)	4B–8B Active per token	16GB+ RAM	Multi-step interactive applications, deep forensic document log analysis
Gemma 4 31B (Dense)	31B Parameters	32GB+ RAM	High-end hardware deployments, precise deterministic financial audit compilation

Skip it when:

You're summarizing a single email or writing a function
You need responses in under a second (128K takes 30–90 seconds on consumer hardware)
The document is naturally short—don’t drive a truck to buy milk

Final thought

That timeout bug is fixed now. The fix was simple—revert the retry backoff change. But finding it without a 128K context window would have taken another week of manual correlation.

Gemma 4 didn't just give me a bigger bucket. It gave me back the timeline.Sometimes, that’s all you need to see the story that was hiding in plain sight.

This article is part of my submission for the Gemma 4 challenge. The accompanying project, LedgerGuard, is on GitHub https://github.com/hypecuts619-source/Ledger-Guard. All code, all prompts, and all log files used in this post are open source—no cloud required. Thanks Gemma 4.

Building a Zero-Framework, Local-First PWA to Combat Web Bloat

Stephen Sebastian — Sun, 17 May 2026 11:00:34 +0000

Hey dev.to community! 👋

I want to share an indie engineering project I’ve been building over the last few weeks: QuickConvertUnits.

It’s a fast, ad-free, local-first unit conversion utility designed to solve a personal frustration I had with the modern web ecosystem.

Whenever I needed to quickly convert cooking metrics on my phone or map out structural spatial areas (like square feet to acres) on-site, the top search results always led me to ancient calculator directories that completely choked my mobile browser. They forced megabytes of intrusive tracking pixels, pop-up scripts, and full-screen layout shifts onto the viewport.

I wanted to see how clean, lightweight, and fast a modern web utility could be if we stripped away all the bloat and focused strictly on modern client-side capabilities.

Here is a deep dive into the engineering decisions and code patterns behind the platform.

🛠️ The Core Technical Stack

Zero Framework Architecture: Built entirely using native HTML5, semantic CSS, and pure vanilla JavaScript. No React re-renders, no heavy framework hydration lag.
Progressive Web App (PWA): Engineered using custom service workers. Once a user loads a directory path once, the core math engines are cached locally. It runs 100% offline.
Strictly Privacy-First: No backend servers, no cloud storage dependencies, and no remote data parsing. The application processes data instantly inside the local client layer.

💡 Interesting Code Patterns Implemented

1. Zero-Latency Reactive Calculation

Instead of forcing users to click an old-school "Submit" or "Calculate" button, the mathematical calculation logic executes reactively on the active browser input event listener.

Here is a simplified blueprint of the native listener strategy used to handle dynamic structural conversions without unnecessary DOM thrashing:


javascript
const inputElement = document.getElementById('source-value');
const outputElement = document.getElementById('target-output');

// Simple reactive calculation matrix execution
function handleInstantConversion() {
    const rawValue = parseFloat(inputElement.value);

    if (isNaN(rawValue)) {
        outputElement.value = '';
        return;
    }

    const conversionFactor = 0.03527396; // e.g., grams to ounces
    const processedResult = rawValue * conversionFactor;

    // Smooth rendering via precision normalization
    outputElement.value = Number(processedResult.toFixed(4));
}

inputElement.addEventListener('input', handleInstantConversion);

Multi-Language i18n Without Heavy Bundles
To make the application globally accessible, I wanted to support comprehensive multi-language support (English, Italian, French, German, Chinese, Arabic, etc.).

Instead of pulling down a massive external internationalization library via npm, I kept the application bundle highly optimized by utilizing a lean native JSON lookup object matching the language pathing variables inside the window state. This allowed me to serve localized interfaces instantly while preserving a near-zero initial JS payload size.

🚀 What I Learned
Building this reminded me of how powerful native web APIs have become. We often reach for frameworks out of habit, even when building simple, high-performance daily utilities. Relying entirely on native web standards allowed me to keep the mobile performance score near perfect while offering complete offline capabilities that rival native mobile apps.

💬 I'd Love Your Feedback!
The project is live here: quickconvertunits.com

As developers, how are you dealing with floating-point math precision errors when handling deep decimal conversions in pure client-side JavaScript? I'd love to know what strategies you use to ensure absolute math precision without bringing in heavy mathematical utility libraries.

Let me know your thoughts on the performance layout, or if there are any custom conversion modules you think I should add next!
![ ](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/g408hv9biz6qo30h1zai.png)