# I built a $9 lifetime app with negligible server interaction — here's the architecture

Hitesh M — Thu, 04 Jun 2026 19:49:57 +0000

A few months ago I got tired of every bookmark tool asking me to create an account, sync to their cloud, and pay monthly for the privilege. I just wanted to save URLs and find them later. That's it.

So I built one myself. It's called Squirrel — a bookmark manager that runs entirely in your browser, stores everything locally, and costs $9 once. No subscription. No account. No server.

This article is about how that works technically, the tradeoffs involved, and what I learned shipping it.

What "no server" actually means

When I say no server, I mean the app has no backend of its own. There is no database I'm running somewhere. No API you're talking to. No cloud storing your data.

Everything — your bookmarks, your sections, your settings — lives in your browser's built-in storage. When you close the tab and come back, your data is still there because the browser kept it, not because I have a server remembering it.

There are exactly three places where the app makes an external request:

Loading the app itself — from Cloudflare Pages, which is just static file hosting
Analytics — a cookieless Cloudflare beacon that counts page visits (no personal data)
License validation — a single request to a Cloudflare Worker when you activate a premium key

That last one is the only server-side logic in the entire product. Everything else is the browser doing the work.

The database that lives in your browser

Most developers reach for a database when they need to store structured data. But browsers have had a capable built-in database for years — IndexedDB.

IndexedDB is not localStorage (which is just a key-value store, limited to strings). It's a real document database that runs natively inside the browser — no network requests, no server, no setup. Your data never leaves your machine because there's nowhere to send it.

Squirrel uses IndexedDB with four stores:

bookmarks — your sections and links
settings — theme, preferences
autoBackups — rolling 30-minute snapshots
dailyBackups — one named backup per day, 7 days of history

The daily backup history is a premium feature. Which brings me to the hardest part of building this.

How do you sell a $9 app with no server?

If the app runs entirely offline and there's no account system, how do you gate premium features? The honest answer is: imperfectly, with a Cloudflare Worker as the one server-side component.

When someone buys Squirrel on Gumroad, they get a license key in the format BM-XXXX-XXXX-XXXX. When they activate it, the app sends the key to a Cloudflare Worker, which verifies it against Gumroad's API and returns valid or invalid. That's the entire backend.

After successful validation, the result is cached locally with a tamper-evident integrity token — a salted hash of the key and timestamp. The app checks this cache on startup instead of calling the Worker every time. If someone manually edits their localStorage to fake the cache, the hash won't match and they get bounced back to the free tier. The salt is buried in the bundle, and the honest reality is: the kind of person who can reverse-engineer all that is probably not the kind of person who'd pay $9 anyway. Ship it and move on.

Security — because the browser is the boundary

When there's no server, the browser becomes your security perimeter. That changes how you think about threats.

On a traditional web app, user input gets sanitised server-side before it touches a database. Here, everything happens in the browser — which means I had to be deliberate about it on the client.

A few things I hardened specifically:

XSS prevention. Every bookmark URL goes through a protocol allowlist before it's saved — javascript: and data: URLs are rejected outright. All user-supplied strings (section names, bookmark titles, import previews) are HTML-escaped before being rendered into the DOM. It sounds obvious, but it's easy to miss when you're moving fast.

Cloudflare Worker hardening. The license validation Worker only accepts requests from squirrel.aditco.in — the CORS header is locked to that origin, not a wildcard. It also rate-limits by IP: more than 10 validation attempts per minute from the same address gets a 429. This protects against brute-force key guessing without any additional infrastructure.

Security headers. The Cloudflare Pages deployment sets HSTS, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, and a strict Referrer-Policy. Small things individually, but they close a set of browser-level attack vectors that are trivial to block and easy to forget.

No third-party favicon proxy. An earlier version used Google's favicon service to show site icons — which meant Google could see every URL you bookmarked. Replaced with a direct fetch from each site's own /favicon.ico. Your browsing habits don't leave your machine.

None of this makes the app a fortress. Client-side security has real limits. But for a tool that makes a privacy promise to users, getting these details right matters more than the features do.

The tech stack

The entire app is two JavaScript files:

app.js — UI, event handlers, rendering, all business logic
indexedDB.js — data persistence layer

No framework. No build step for the app itself (only obfuscation for production). Vanilla JS, a bit of CSS, and a single HTML file.

Why no framework? Partly because I wanted the app to be distributable as a literal single HTML file — download it, open it in any browser, works forever. Partly because a bookmark manager doesn't need React. The DOM manipulation is simple enough.

The production build runs the source through javascript-obfuscator, bundles everything into one self-contained squirrel.html, and deploys to Cloudflare Pages via a GitHub Actions workflow.

What I'd do differently

Ship the article before the product, not after. I launched on Product Hunt and got 200 visitors on day one with solid engagement. But I had no written content anywhere explaining how it was built or why. The people most likely to buy are developers who understand what they're getting — and developers read. This article should have existed on launch day.

Plan for domain migration before it happens. I renamed the product from BookMark Manager to Squirrel mid-launch and changed the domain from bookmarks.aditco.in to squirrel.aditco.in. What I didn't account for: IndexedDB is scoped to the origin. Every user who had saved bookmarks at the old domain had their data stay behind when the redirect kicked in. I had to disable the redirect, add migration banners to both domains, and give users a 48-hour window to export and re-import. A lesson learned the hard way about client-side storage and domain changes.

The "no server" constraint is a feature, not just an architecture choice. I started building this because I didn't want to run a backend. But users responded most strongly to the privacy angle — your data never leaves your browser. That's the pitch, not the implementation detail.

Where it is now

Squirrel launched on Product Hunt in June 2026 and is live at squirrel.aditco.in. Free up to 25 bookmarks, $9 one-time for unlimited — no subscription, no account required.

The top traffic countries so far are India, the US, and Turkey, which led me to enable purchasing power parity pricing on Gumroad so the $9 price point scales fairly across markets.

If you're curious about the architecture or want to look at how the license validation works, feel free to ask in the comments. And if you've built something similar — a local-first app with a lightweight monetisation layer — I'd genuinely like to hear what tradeoffs you made.

Built with vanilla JS, IndexedDB, Cloudflare Pages, and one very small Cloudflare Worker.

DEV Community: Hitesh M