Engineering · 2 min read
Setup should be one command, not a copy-paste ritual
The gap between "installed" and "actually sending data" is where most integrations die. We closed it with a single command that shows you the diff before it touches anything.
By Akhil Anand · September 17, 2026
The most dangerous moment in a developer tool's life is the five minutes after npm install. The package is in, the docs are open, and now the person has to copy a snippet, figure out where it goes, add an env var, and hope they got the order right. Every one of those steps is a place to bounce. "Installed" and "working" are very different numbers, and the distance between them is where activation quietly dies.
The old flow, honestly
For AtlasBurn it used to be: npm i @atlasburn/sdk, then copy initAtlasBurnAuto({ apiKey: process.env.ATLASBURN_KEY }) to the top of your entry file (which for Next.js isn't your entry file — it's instrumentation.ts), then add the key to .env.local (or .env?), then remember to gitignore it, then... did it work? Open the dashboard and check.
That's four decisions and a verification step, each a small tax on the exact person you most want to succeed.
The new flow
npx abn init
That's it. The CLI detects your framework and package manager, figures out the right env file, auto-detects your providers, takes your key with hidden input, and — crucially — shows you a diff of exactly what it will change and asks before writing a single line. Then it wires the correct init location for your stack and runs a verification test so you see it work.
Nothing is written until you've seen it. New init file, one env line, the import location — all previewed, with +/− counts, gated behind a yes.
Plus abn test, abn status, and abn doctor for when something looks off. It's bundled with the SDK, zero new dependencies.
Why "show the diff" matters more than "make it fast"
The instinct with setup automation is to make it invisible — one command, magic happens. We deliberately didn't. A tool that silently edits your code is a tool you don't trust, and trust is the whole game for something that's about to sit in your production request path.
So the CLI is fast and legible: it does the tedious part for you, but it never surprises you. You always see the change before it happens, and you can always say no. That's the version of "one command" that developers actually want — not less control, just less tedium.