Is Datacentre Sovereignty Important? Why I Built a 38,000-Ticker FinTech App with No Database

#nextjs #typescript #architecture #security

The Sovereignty Trap and the Death of Database Lock-In

The standard advice for building a SaaS is always the same: Spin up a heavy database, set up an auth provider, and start collecting user data.

But two major discussions trending on Hacker News today prove how fragile and risky this architecture has become:

The Sovereignty Debate: "Is datacentre sovereignty that important?" is sparking intense arguments [mart1, mart2]. Developers are finally realizing that renting cloud servers without owning the physical jurisdiction of your data is an existential liability.
The Infrastructure Rebellion: "The tiniest logging stack: Fluent Bit, Parquet and DuckDB" is gaining massive traction. Engineers are actively fleeing heavy, bloated database clusters like Elasticsearch in favor of simple, local-first file formats [obel1].

We have over-engineered the modern web to the point of functional absurdity. We lock simple application states inside proprietary cloud databases, exposing ourselves to platform lock-in, data breaches, and constant security audits.

When I set out to build DividendFlow—a tax-aware compounding engine for 38,000+ US tickers—I decided to reject this complexity entirely. Here is why I went DB-less, Auth-less, and AI-less to build a highly scalable, sovereign financial utility.

1. Why True Sovereignty Means Having No Database

The recent high-profile cloud suspensions have proven a hard truth: if your app's state is locked inside a proprietary cloud database, you don't actually own your business. A single account lockout by an automated moderation bot can delete years of user data and kill your SaaS overnight.

Instead of storing user portfolios, contribution amounts, and tax brackets in a database (and dealing with connection limits, migrations, and security audits), I moved the entire application state to the URL address bar.

How the "URL-as-a-DB" Architecture Works:

Stateless Execution: Every toggle change (Taxable vs. Tax-Free), monthly contribution tweak, or ticker selection instantly serializes into the URL parameters.
Zero Latency: Since there is no database lookup for a user profile, every request is a pure function. Projections render in under 150ms at the Edge.
Instant Portability: Users don't need a "Share" button. They copy the browser link, send it to a friend, and the engine re-runs the exact same math in under two seconds. If we get banned or locked out tomorrow, we can copy our static Next.js bundle and redeploy it to any cheap bare-metal VPS in 5 minutes. No database migrations, no platform lock-in.

2. Why Fintech Cannot Tolerate "AI Vibes" or Dirty Data

While the developer community is realizing that simple, local-first file formats are better than heavy database clusters [obel1], we must also realize that compounding finance math cannot tolerate probabilistic logic.

A tiny 0.1% rounding error in your Qualified vs. Ordinary dividend tax calculation today compounds into a $50,000 shortfall over a 20-year horizon.

In FinTech, a 99% accurate model is 100% dangerous. We built our compounding engine in 100% deterministic TypeScript running on Next.js 15 Server Components (RSC).

// Strictly deterministic, zero-dependency compounding loop
export function calculateNetCompound(payout: number, taxRate: number, isQualified: boolean): number {
  const applicableRate = isQualified ? taxRate * 0.75 : taxRate; 
  return payout * (1 - applicableRate);
}

3. Escaping the Frontend's Lost Decade via Next.js 15

To fight the massive JS bundle bloat, we offloaded 240+ recursive compounding loops to the server.

By utilizing React Server Components (RSC), the user's browser receives zero calculation JavaScript and no heavy JSON arrays. It only receives the final coordinates required to render the chart.

It is lightweight, host-agnostic, and runs securely without requiring any private bank logins or OAuth credentials.

Conclusion

We’ve over-engineered the web. You don't always need a database. You don't always need AI. Sometimes, the most "senior" move you can make as an engineer is to say no to the cloud database tax, avoid the AI hype, and just write fast, accurate, deterministic code.