Every architecture starts with requirements. Mine had exactly three: instant load, zero maintenance, and nothing to break at 3 a.m. A database serves none of those for a card game portal, so SolitairePicks ships without one.

What localStorage actually buys

Player statistics — hands played, wins, best times — persist per game in localStorage. No accounts means no password resets, no GDPR export pipeline, no breach surface. The tradeoff: history is device-bound. For a free portal where the session goal is "play a hand while the coffee brews," that trade is correct.

Static pages, edge delivery

Every game page is a static build artifact served from the edge. Klondike, Spider, FreeCell, Pyramid — each is its own page with its own logic file. Deploying is a file sync. Rolling back is deploying yesterday's folder. There is no migration to run and no connection pool to exhaust.

Where the deep links live

• Klondike — draw-one and draw-three, the default first stop

• FreeCell — all cards visible from the deal, pure logic, zero luck

• Pyramid, Golf, TriPeaks and a dozen more — each with per-game win-rate tracking

The cost side of the ledger

No backend also means no server-side analytics. I see aggregates only where I choose to instrument them at the edge. If the portal ever needs cross-device sync, that is a product decision — and it will come with an ops bill. Until then, the simplest architecture that works keeps working.