Nikita SavchenkoNikitaSavchenkoeverywhere

My 2nd SaaS: AfterPack — the Modern JavaScript Obfuscator

Oct 2, 2026#tech #career
1
My 2nd SaaS: AfterPack — the Modern JavaScript Obfuscator

Every web app hands its code to every visitor. Your paywall check, your pricing rules, the license check in your desktop app, the anti-cheat in your game — all of it ships to the user's device. And in 2026, anyone can paste that bundle into an AI agent and get clean, editable source back in minutes, together with a one-line patch that unlocks your paywall.

Yesterday I launched AfterPack — my second SaaS after DataUnlocker, and a modern JavaScript obfuscator built for exactly this. It doesn't pretend your code can't be read: given enough time, any obfuscated code can be. Instead, it rewrites your production build into a different program on every build — or, inside a Cloudflare Worker, on every request. A patch written against today's release simply doesn't fit tomorrow's.

Think of a lock. You can't stop a determined person from picking it once. But if the lock changes every night, yesterday's copied key is just a piece of metal.

This is what it looks like on a real function. I ran AfterPack 0.2.1 on it three times this morning, at the medium preset:

Same function, same results, three different programs. A patch written for build #1 has nothing to hold on to in build #2 — and your users get build #2 with your very next deploy.

Why obfuscate JavaScript if AI can read it anyway?

Because reading code is no longer the expensive part — so what matters is how long that reading stays useful.

Guess how long it took Claude Code to turn two popular obfuscators' own flagship demos back into clean source? 10 minutes. One four-paragraph prompt, Claude Opus 4.6. I ran that experiment in May, and those models are already a generation behind. Minification never hid much either: the Claude Code "source leak" was a readable bundle that had been sitting on npm since launch.

So the question changed. It's not "can someone read my code?" anymore — they can. It's "how much of that work still applies to my next release?" With the most popular open-source obfuscator, it's nearly all of it: it emits the same output shapes every time, and free deobfuscators ship ready-made recognizers for them. With AfterPack, under 6% of what a deobfuscator recovered from one build still resolved on the next (our September 2026 measurement, method).

Who needs a JavaScript obfuscator?

Anyone who ships code they'd rather users didn't change:

  • SaaS apps with paywalls, feature gates and pricing logic in the frontend
  • Browser games, where a cheat is just a patch with a fan base
  • Browser extensions and Electron apps with license checks
  • Anti-fraud and anti-bot scripts, which only work while bots don't understand them
  • Sites that get scraped, cloned or "improved" by someone else's extension

From DataUnlocker to AfterPack

AfterPack didn't start as AfterPack. In 2017 I wrote an article about saving web analytics from ad blockers, and it turned into DataUnlocker — my first SaaS, which crossed 400 clients without a penny spent on marketing.

DataUnlocker 1.0 had a weak spot: blockers learned to get around it. DataUnlocker 2.0 fixed that by weaving its Defender script into the website's own JavaScript, so it can't be cut out without breaking the site. To keep that script unrecognizable, DataUnlocker needed an obfuscator — and in 2024 I started building one.

AI-assisted development made a whole new level of complexity doable for one person, and that's what made AfterPack possible. I built most of its Rust engine by directing AI agents, in a language I'd barely touched before — that story is here. The same kind of agent that unwinds a bundle in 10 minutes ran overnight trying to break AfterPack's early output, and every break it found became a fix.

Somewhere along the way, it clicked. An ad blocker works by matching something stable on your site: a script URL, a class name, a function. So does a game cheat. So does a userscript that removes a paywall, a scraper's CSS selector, an extension that injects itself into your page, and an AI agent asked to patch your app. Analytics was one narrow slice of a much bigger problem: anything you ship to the browser is a target for as long as it holds still.

Where AfterPack is going

JavaScript is step one. Next is network transport cloaking: API requests and responses running through a codec that changes with every build. After that come HTML and CSS — class names, DOM structure and selectors, different on every build while the page looks and works exactly the same.

That's where AfterPack and DataUnlocker meet. DataUnlocker already handles the network side; AfterPack makes the code, and later the markup, new on every build. Put together, a shipped web app has nothing stable left to anchor to: no fixed selector for a cosmetic filter, no fixed function for a patch, no fixed URL for a blocklist.

Whether that ends up as one product or two, I'm not sure yet. I might also be wrong about how fast it gets there — polymorphic HTML and CSS that never breaks a layout is a hard problem.

How to try AfterPack

Run one command in your project after a build:

npx afterpack@latest

It finds your build output (dist/, .next/, build/, out/ and others), rewrites it in place and keeps a backup — npx afterpack@latest restore undoes the run. To make it part of every build, there are plugins for Next.js, Vite, webpack, Astro, Nuxt, SvelteKit, Vue, Angular, Electron and more.

This blog runs through AfterPack, too. It's a Next.js site, and the whole integration is one wrapper in next.config.ts: withAfterpack(config). Open DevTools and have a look :)

Nothing to install:

  • Playground: paste a function, pick a preset, see the output. It runs in your browser, so your code never leaves the page.
  • Site scanner: shows what any website's JavaScript already gives away — public source maps, readable logic, leaked keys.
  • Your coding agent: paste Add AfterPack to this project: read afterpack.dev/llms.txt, follow the quickstart for my framework, then run a production build and show me the Protection Map.

The Protection Map is a report of your original source, with every token colored by how much transformation it went through:

AfterPack Protection Map — a JavaScript file with every token highlighted by how strongly the obfuscator transformed it, next to per-file stats: complexity, names hidden, weak spots and output size

The CLI and plugins are open source under Apache-2.0, and the local engine is free. Pro adds cloud builds and heavier protection aimed at the code that matters, from $49 a month (plans).

What AfterPack can't do

It can't hide secrets. Anything your running code uses can be observed by someone who runs it in a browser they control, so API keys belong on your server. It also can't make anyone forget what they've already read — it only makes the next release a new problem. And protection has a cost: on real bundles, the default light preset comes out 1.9–2.4× the input size, gzipped.

The 52-second version

If you'd rather watch than read:

AfterPack launch video on YouTube — Nikita introduces the JavaScript obfuscator that ships a different program on every build

DataUnlocker took me from a 2017 article to 400 clients. AfterPack is one day old. If you ship JavaScript you'd rather nobody patched, try it on your code and tell me what got in the way — I read every GitHub issue.

Your help would be invaluable at this stage — it takes a few clicks to follow AfterPack on Telegram, X, LinkedIn or Reddit, or to star it on GitHub. Thanks!