DEV Community: Sike Ren

No accounts meant no license server — so my $19 one-time SaaS signs its keys with ECDSA P-256

Sike Ren — Thu, 20 Aug 2026 19:18:12 +0000

I made a product promise I didn't think through: no accounts, no subscription, $19 one-time. The product is Resbetter — paste your resume, get the interview questions it will trigger, with STAR answers already built. The "no accounts" promise made sense for privacy (there's nothing to breach if there's nothing stored). It also closed a door: with no user table, there is no server-side place to record "this person paid". Which means a $19 license key has to prove itself without any server lookup — and a key that works offline is a key someone can study, patch around, and share.

Here's the architecture that fell out of that constraint.

The constraint chain

No accounts → no entitlement store on the server → the key must self-verify.
Privacy by construction → the resume is parsed in the browser, only plain text is ever uploaded, held ≤24h, then deleted → there's no user profile to attach a key to.
One-time $19 → no recurring billing → no subscription token to check on every request.

The key had to be a self-contained proof: something only I can produce, that the browser can check offline, that the server can check again.

Signed keys, not random strings

A random "XXXX-XXXX-XXXX" license key is checkable server-side only if the server has a list. An asymmetric signature is checkable anywhere — the public half ships in the bundle, the private half never leaves my machine.

The key format is deliberately boring:

"RN1-" + base64url( version(1 byte) || serial(uint32 BE) || ECDSA-P256-SHA256 signature(64 bytes) )

5 bytes of payload, 64 bytes of signature. Nothing clever — the cleverness would be in the tooling around it.

Keys are minted offline with a small Node script, using node:crypto (which wraps OpenSSL, so no extra dependency):

import { webcrypto as crypto } from 'node:crypto'

const VERSION = 1
const PAYLOAD_BYTES = 5
const PREFIX = 'RN1-'

function payloadFor(serial) {
  const payload = new Uint8Array(PAYLOAD_BYTES)
  payload[0] = VERSION
  new DataView(payload.buffer).setUint32(1, serial, false)
  return payload
}

const pair = await crypto.subtle.generateKey(
  { name: 'ECDSA', namedCurve: 'P-256' },
  true,
  ['sign', 'verify'],
)
const privateKey = pair.privateKey
// privateKey is exported as JWK and written to .secrets/licence-key.jwk
// (mode 0600). It is the one file whose loss cannot be recovered from:
// without it, no further key can ever be signed.

for (let serial = 1; serial <= 200; serial += 1) {
  const payload = payloadFor(serial)
  const signature = await crypto.subtle.sign(
    { name: 'ECDSA', hash: 'SHA-256' },
    privateKey,
    payload,
  )
  const bytes = new Uint8Array(PAYLOAD_BYTES + 64)
  bytes.set(payload, 0)
  bytes.set(new Uint8Array(signature), PAYLOAD_BYTES)
  console.log(PREFIX + Buffer.from(bytes).toString('base64url'))
}

The serial isn't a secret — it's the identifier. It's the only stable handle the server has for "this key", which is how a redemption ledger can count off it.

Verifying in the browser, network off

The client bundles the public key — 65 bytes, safe to ship:

export const LICENSE_PUBLIC_KEY =
  "BDHuQN7mU6QpfyASU9h15DW1R9UNdvRV5F7XZdpOKRYt2ShXhM0IugtJ6HQ2NSJOmVB3z9Om_t8L8VV_Ci-btSc"

Verification is stock Web Crypto:

const key = rawKey.replace(/\s+/g, "")
const body = key.slice(0, 5).toUpperCase() === "RN1-" ? key.slice(5) : null
if (!body) return null

const bytes = fromBase64Url(body)
if (!bytes || bytes.length !== 5 + 64) return null

const payload = bytes.subarray(0, 5)
const signature = bytes.subarray(5)

const valid = await crypto.subtle.verify(
  { name: "ECDSA", hash: "SHA-256" },
  publicKey,
  signature,
  payload,
)
if (!valid) return null

// payload = version(1) || serial(uint32 BE)
return new DataView(payload.buffer, 1, 4).getUint32(0, false)

That's it. crypto.subtle.verify is available in every modern browser over https (and even file://). Enter the key with the network switched off and it still validates. The serial it returns is remembered in localStorage so the unlock UI doesn't re-prompt.

Why the server re-verifies the same signature

An offline-verifiable key has a structural weakness: it's a client-side check. A user can patch the bundle, delete the check, or just read the source. So the browser check is the fast path, not the gate.

The gate is the Worker. When you redeem a key, the server verifies the same signature with the same public key, and only then mints access:

// functions/api/unlock.ts
const serial = await verifyLicenseSerial(licenseKey)
if (serial === null)
  return fail(401, "That key isn't valid. Check it and try again.")

// Redemption ledger, keyed by serial (KV)
const ledgerKey = `lic:${serial}`
const used = Number((await env.PACK_KV.get(ledgerKey)) ?? "0") || 0
if (used >= MAX_REDEMPTIONS) return fail(403, "Key used too many times.")
await env.PACK_KV.put(ledgerKey, String(used + 1))

Two things worth saying about that ledger:

MAX_REDEMPTIONS = 5, not 1. A buyer legitimately unlocks more than once (second device, a retry, a fresh run after the 24-hour document window closes). But each redemption spends a full paid-tier generation, so it can't be unbounded — one $19 key posted publicly would bill me forever. 5 is the ceiling where neither side is harmed.
KV has no compare-and-swap. Two simultaneous unlocks can read the same count and both write count+1, losing one tick. That's the right way to lose this race: a buyer is never wrongly locked out, and the ceiling still holds within one extra redemption.

The public key being in the client is not a weakness to hide — it's the design. Ship the public half, keep the private half in .secrets/, verify in two places, and a patched bundle still can't forge a key.

The same constraint also moved parsing into the browser

The "privacy by construction" promise didn't stop at license keys. The resume file itself never leaves the browser until it's been reduced to plain text — PDF via pdfjs-dist (with CJK CMaps for Chinese resumes), DOCX via mammoth, both dynamically imported so the landing page stays lean:

if (ext === "pdf") {
  const { getDocument, GlobalWorkerOptions } = await import("pdfjs-dist")
  const workerUrl = (await import("pdfjs-dist/build/pdf.worker.min.mjs?url")).default
  GlobalWorkerOptions.workerSrc = workerUrl
  const buf = await file.arrayBuffer()
  const pdf = await getDocument({
    data: buf,
    cMapUrl: "/cmaps/",   // CJK CID fonts need pdf.js's glyph CMaps
    cMapPacked: true,
  }).promise
  // ...re-cluster pdf.js text items into rows, split into lines
}

Only the extracted plain text is ever sent to the API — one request, held ≤24h, deleted. Which is exactly the claim that makes "no accounts" honest: there's nowhere to store a profile, so there's nothing to leak.

What I'd do differently

crypto.subtle is unavailable on insecure origins. The whole scheme silently dies over plain HTTP. Ship HTTPS or ship nothing.
The offline key invites reverse-engineering. The public key in the bundle is public, and the check can be patched out. The server-side re-verification closes the forgery hole; it does not stop a determined freeloader from cracking their own copy. For a $19 one-time product, that's an acceptable line — the redemption cap is what actually keeps a shared key from becoming an unlimited leak.
Sign more than 5 bytes. Version + serial is minimal by design, but if you want the key to encode the buyer's email or a product tier, ECDSA signs whatever you put in front of it — the payload size just grows.

The lesson I keep re-learning: product constraints are architecture constraints. "No accounts" didn't mean "smaller backend" — it meant no backend entitlement at all, which is a strictly harder problem. But it's also why the system holds together: every part re-verifies what the part before it trusted, and nothing trusts the client.

Tattoo data taught me to delete every third-party script — and build analytics from a SQLite table

Sike Ren — Tue, 18 Aug 2026 18:55:06 +0000

The post is a casual chain, not a product pitch. Blackwork is only the evidence.

A tattoo booking is one of the most sensitive payloads a web app can touch. Not in the "payment card" sense — in the body sense. The booking form asks for placement (which arm, which rib), size, reference photos, a deposit amount, and a phone number. That's more personally identifying than a bank transfer: it describes a body and a plan to permanently modify it.

I built Blackwork, a booking/deposit/CRM system for tattoo studios. The studio's clients submit that data. And the default SaaS stack would have handed a copy of it to a dozen companies I never met.

Here's the chain of decisions that ended with: my app ships exactly one inline script.

The default stack leaks

A fresh Next.js app, following the path of least resistance, ships a pile of third-party requests:

GA4 or Plausible or PostHog for analytics
Sentry for errors
Hotjar or Microsoft Clarity for session replay
Google Fonts / a font CDN

Each of those is a company that now receives a copy of every page load — IP, user agent, behavior, and whatever ended up in the DOM. For a page that collects tattoo references, that's a leak nobody asked for.

Blackwork's landing page makes a promise: "No analytics scripts, no tracking. Your data is yours."

The mistake would be treating that as marketing copy. I treated it as an architecture constraint. Once it's a constraint, the downstream decisions stop being judgment calls.

Consequence one: exactly one inline script

Here is the entire client-side script footprint of the app — a three-line theme toggler that runs before first paint to avoid a flash:

(function () {
  try {
    var t = localStorage.getItem('blackwork_theme');
    var dark = t === 'dark';
    var el = document.documentElement;
    el.classList.toggle('dark', dark);
    el.style.colorScheme = dark ? 'dark' : 'light';
  } catch (e) {
    document.documentElement.style.colorScheme = 'light';
  }
})();

That's it. Fonts are self-hosted at build time by next/font. No <Script>, no gtag, no error SDK, no widget. If you open DevTools → Network on the public pages, the request list is mostly your own assets.

Consequence two: analytics became a table

But I still wanted to know the same things a founder needs: does anyone land on the pricing page? Do launch channels convert? So I wrote the smallest possible first-party tracker — one route, one INSERT into the same SQLite the app already runs on:

// app/api/track/route.ts — fire-and-forget, returns 204 so the client pays nothing
export async function POST(req: Request) {
  const store = await cookies();
  let vid = store.get("vid")?.value;
  if (!vid) {
    vid = crypto.randomUUID();
    store.set("vid", vid, {
      httpOnly: true,
      sameSite: "lax",
      secure: process.env.NODE_ENV === "production",
      path: "/",
      maxAge: 60 * 60 * 24 * 365,
    });
  }

  let path = "/";
  try {
    const body = await req.json();
    if (typeof body.path === "string" && body.path) path = body.path;
  } catch {
    // malformed body — still count it as a pageview
  }

  trackEvent(eventForPath(path), path, vid);
  return new Response(null, { status: 204 });
}

trackEvent is a prepared INSERT into a site_events table, wrapped in a try/catch so tracking can never break a page:

export function trackEvent(event: string, path: string, visitorId?: string): void {
  try {
    db()
      .prepare("INSERT INTO site_events (event, path, visitor_id, created_at) VALUES (?, ?, ?, ?)")
      .run(event, path || null, visitorId || null, Date.now());
  } catch {
    // best-effort: tracking failure is never fatal
  }
}

The visitor id is an httpOnly cookie, so a visitor can't be fingerprinted from JS, and it's only ever stored first-party.

The dashboard reads the same table

The analytics dashboard at /analytics/[secret] is a server component gated by an env var. No client bundle, no chart library on the page — the queries do the work. The one that surprised me by being pleasant to write is distinct daily visitors:

SELECT strftime('%Y-%m-%d', created_at/1000, 'unixepoch', 'localtime') AS day,
       COUNT(DISTINCT visitor_id) AS n
FROM site_events
WHERE created_at >= ?
GROUP BY day

Plus pageviews, signups, logins, bookings, and subscription states from the same database. The whole thing is under 200 lines of queries and a zero-filled 30-day grid.

What the constraint buys

No cookie banner. The vid cookie is first-party, httpOnly, functional. There's nothing to consent to.
A one-paragraph privacy policy. "What Blackwork stores, and what we deliberately do not do with your data" — the page honestly describes a very short list of stored things.
No GDPR vendor list. The privacy policy doesn't need a table of 40 processors. There is one processor: our own server.

The part I like least

The constraint has a cost, and it's real:

No session replay, no heatmaps, no real-time. If a visitor bounces on the pricing page, I know the count went up but not where their cursor went.
Crash telemetry is a console.log on a server nobody is watching. The trade: the studio's data never leaves the request path. If the app breaks, the app breaks loudly and locally.
Attribution is UTM query params only. "Which directory sent visitors" is answerable. "What's the LTV per channel" is a spreadsheet exercise.

If I ever need real funnel analysis, I'll outgrow this — and that's fine. The point of a constraint isn't to be the best possible analytics setup. It's to make the privacy promise structurally true instead of rhetorically true.

The loop closes

"Zero third-party scripts" reads like a slogan and works like a spec. Every feature that wants a script now has to justify crossing the boundary: it has to be first-party, or it doesn't ship.

The weirdest outcome: a privacy constraint that most products treat as a legal paragraph turned into the product's strongest feature. Studios don't ask "is this compliant?" — they ask "who sees my clients' references?" and the honest answer is one server, ours.

If you're building a vertical SaaS where users hand over data they'd be embarrassed to leak, try deleting every third-party script for a week. The panic lasts a day. The clarity lasts longer.

I ship an Ed25519 public key in my JavaScript bundle and call it a licence

Sike Ren — Fri, 14 Aug 2026 13:48:57 +0000

I build a Bates-numbering tool for litigation PDFs. Bates numbers are the unique page identifiers stamped across a document production — DEF-000123, DEF-000124, running continuously — so a court or an opposing party can point at one exact page. It runs entirely in the browser.

The reason it runs entirely in the browser is the part people don't guess, and it's the part that forced every interesting decision downstream, including the licence check.

The constraint: the documents can't leave the device

The PDFs this tool processes are privileged. Under a protective order, the court can literally forbid the material from leaving the machine it was produced on — "highly confidential — attorneys' eyes only" is a phrase with teeth. Uploading to a server is not a "trusted" option, it's a non-option. A hosted SaaS that asks you to "securely upload your privileged documents for processing" is asking the wrong question.

So the tool parses and rewrites PDFs locally with pdf-lib, in the tab, and writes the finished files through the File System Access API to a folder you pick. Your originals are never touched; output goes somewhere else, because stamping a PDF can't be undone.

You can verify that claim instead of trusting it. The only network requests the page ever makes are six counters — page view, batch finished, check finished, checkout opened, licence verified, error type. Each is a ~30-byte JSON object, no cookie, no identifier, no filename, no page count:

// src/lib/analytics.ts
const ENDPOINT = 'https://api.bateskit.com/e'
export type Event = 'view' | 'run' | 'check' | 'buy' | 'unlock' | 'error'

function send(body: string): void {
  const blob = new Blob([body], { type: 'text/plain;charset=UTF-8' })
  if (navigator.sendBeacon?.(ENDPOINT, blob)) return
  void fetch(ENDPOINT, { method: 'POST', body, keepalive: true, mode: 'no-cors' })
}

Block the endpoint and the tool is identical. Or load the page once, disconnect from the network, and run a batch — it works. That's the property a hosted tool can't offer, and it's the whole reason to use it.

The consequence: there is no server to ask "did they pay?"

Here's the cascade. The tool can't have a server, because the documents can't go to one. And if there's no server, there's no licence server. Every SaaS licence check works by asking the server whether a key is valid, because the server is the trusted party. Mine can't have one — and the person doing production QC might be on a machine that has never been on the network. Air-gapped is not a hypothetical for this audience.

So the licence check has to run offline. That means the verification logic ships in the page, and the verification key ships in the page. The key format is BK1.<payload>.<signature>, both halves base64url, and the verification is a single WebCrypto call — no crypto library at all:

// src/engine/license.ts
export async function verifyLicense(key: string): Promise<LicenseInfo> {
  const parts = key.trim().replaceAll(/\s+/g, '').split('.')
  if (parts.length !== 3 || parts[0] !== 'BK1') return { ok: false }

  const payload = fromB64Url(parts[1])
  const sig = fromB64Url(parts[2])
  const pub = await crypto.subtle.importKey('raw', fromB64Url(PUBLIC_KEY_B64), 'Ed25519', false, ['verify'])
  const ok = await crypto.subtle.verify('Ed25519', pub, sig, payload)
  return ok ? { ok, order: new TextDecoder().decode(payload) } : { ok: false }
}

The payload is just the order reference. The public key is a 32-byte constant sitting in the bundle:

const PUBLIC_KEY_B64 = 'RzWyRhHf12xzr32jodAg0CiconSeTLDz6_E6n_xpr0M'

The signing half of the pair never leaves the signing machine. crypto.subtle.verify is available in every browser, so this has zero dependencies and needs no network at any point.

The part I had to accept: the wall doesn't exist

Now the honest part. I can't actually stop anyone from pirating this, and neither can anyone building the same thing. The public key is public by construction — you cannot hide the verifying half of a signature, because the verifier is the whole point of the mechanism. Anyone can open the bundle, extract the key, and sign their own payloads. Or simply read the verification code and patch the result. There is no technical wall here. There is no wall that could exist, offline, in shipped JavaScript.

The model I landed on works by accepting that and choosing which failure mode I don't want. A licence that phones home to a server can't be cracked, but it can lock out a paying customer the day the server goes away — or the day I get bored and stop paying for the domain. An offline-verified licence can be extracted, but it keeps working forever, air-gapped, with no account, no telemetry, and no one to go out of business.

For a $19 one-time purchase used four times a year, "keeps working if the maker vanishes" is worth more than "hard to pirate." So the free tier is one file up to 25 pages with every feature enabled — genuinely useful, enough to validate the output on your own document — and the paid tier is a signed key that unlocks unlimited use. The licence isn't a fortress; it's a convenience unlock for people who'd rather pay $19 than extract a 32-byte key. That's the entire anti-piracy strategy, and it's a deliberate one.

Why I'm telling you this

Tools like this usually get dismissed as "just a wrapper" or — worse for a tool handling privileged documents — assumed to be secretly phoning home. The offline licence is my answer to both, but it only works as an answer because the verification code is readable. Security through obscurity would be a contradiction here: the whole model depends on the user being able to look at the bundle and confirm the only cryptography is a signature check against a published key.

If you're building a client-side tool that needs to charge for it, you'll hit the same wall. The instinct is to bolt on a server just for the licence. Before you do: ask whether the thing you lose — a customer who can never be locked out — is worth the piracy you think you're preventing. For a small one-time price on a tool your users run on machines that may never see the network, it probably isn't.

BatesKit is at bateskit.com. It numbers a folder of PDFs, checks redaction and metadata and privilege markers, reconciles against your index, and writes a Summation-style load.dat — all locally, all read-only on the checks, $19 once.

Why SharedArrayBuffer forced me to delete every third-party script on my site

Sike Ren — Thu, 06 Aug 2026 04:35:10 +0000

I wanted multithreaded ffmpeg running in a browser tab. What I got, several steps
later, was a site with zero third-party scripts — no analytics vendor, no font CDN,
no embedded video, no chat widget. Not because I took a principled stand on privacy.
Because the platform stopped allowing them, and by then it was too late to argue.

Here's the chain, because each link is obvious in isolation and the destination is not.

The chain

ffmpeg is a C program that uses threads. Compiled to WebAssembly via Emscripten,
those threads become Web Workers, and the workers need to share one linear memory
with the main thread. Shared memory in a browser means one thing: SharedArrayBuffer.

SharedArrayBuffer was restricted after Spectre, because a shared buffer plus a
high-resolution timer is a usable side-channel. Browsers brought it back behind a
gate: your document must be cross-origin isolated. That means two response
headers on the document:

  Cross-Origin-Opener-Policy: same-origin
  Cross-Origin-Embedder-Policy: require-corp

On Cloudflare Pages this is a plain text file at public/_headers, no build step,
no framework config:

    Cross-Origin-Opener-Policy: same-origin
    Cross-Origin-Embedder-Policy: require-corp

Verify it in the console, not by reading your config:

  crossOriginIsolated              // must be true
  typeof SharedArrayBuffer         // 'function'

If crossOriginIsolated is false, ffmpeg.wasm silently falls back to
single-threaded and you spend an afternoon wondering why encoding is slow.

What COEP: require-corp actually does

This is where the third-party scripts died. require-corp says: every cross-origin
subresource must explicitly opt in to being embedded, either by sending
Cross-Origin-Resource-Policy: cross-origin or by being loaded with CORS.

Almost nothing on the open web sends CORP. So:

Third-party analytics is gone. A <script src="https://vendor.example/a.js"> is a no-cors request. No CORP header on the response, no script. Every hosted analytics vendor I checked, self-hosted or not, fails this.
Google Fonts is gone. The stylesheet request from fonts.googleapis.com is not CORS, so it never loads, so the @font-face rules never arrive.
Embeds are gone. A YouTube iframe, a demo video, an embedded widget — iframes are subject to the same rule, and none of them send CORP.
COOP: same-origin breaks popup flows too. It severs the window.opener relationship with cross-origin windows, which is exactly the channel that popup-based OAuth uses to hand a token back to you.

There is a softer variant, Cross-Origin-Embedder-Policy: credentialless, which
loads cross-origin no-cors resources without credentials instead of blocking them.
It's the escape hatch if you need third-party images or media — check current
browser support before you build on it. I went with require-corp because I needed
nothing from anyone else.

What still works

Same-origin resources are unaffected: your own fonts, your own images, your own JS.
And crucially, a CORS fetch to your own API is fine — CORS requests satisfy
the opt-in requirement.

So analytics became about twenty lines posting an event name to my own Cloudflare
Worker, and a token-protected plaintext URL to read the counters back. Five events:
page loaded, batch finished, checkout opened, licence verified, encoder failed.
That's enough to tell me which step of the funnel is broken, which is the only
thing I ever actually used a dashboard for.

The part I didn't plan

The tool encodes video locally and uploads nothing. Every site that claims something
like that is asking you to trust a sentence in a footer.

Cross-origin isolation turns it into something you can check in ten seconds: open
DevTools → Network, run a batch, watch it stay empty. Load the page once, go
offline, encode again — it still works, because there's no server in the path.

And the stronger version: I can't quietly leak your data through a third party,
because the browser will not let me load one. The privacy property isn't a promise
I'm making; it's a consequence of a constraint I accepted for an unrelated reason.

Honest costs

You own your analytics forever. No Sentry, no session replay, no funnel tool. When something breaks in production you have the events you thought to add, and nothing else.
No embedded demo video on your own landing page. Self-host the file or use a GIF.
No drop-in chat widget, no support tooling, no A/B testing service.
If you genuinely need a third-party resource later, your options are self-host it or proxy it through your own origin. Both are work you didn't budget for.

For a tool whose whole premise is that nothing leaves the tab, that trade was free.
If you're building anything else, understand that turning on SharedArrayBuffer
means adopting all of it — the isolation is not a flag you can scope to one route.

One link

The thing I built with it is BatchCrunch — drop a folder
of video, it compresses all of them locally via ffmpeg.wasm. But the headers above
are the part worth stealing.

Happy to answer anything about the setup, the Emscripten pthread build, or the
worker-side licence check in the comments.