HANK ELSNER/FOR EDEN

A blueprint, not a sales pitch

Eden — build the machine that builds your projects.

I'm Hank. You've seen the crypto sites I run — the wallet, the mints, the collections. Here's the part that matters: I didn't build them one at a time. I built a system that builds them. One server, one front door, an AI agent that does the programming, and a set of written rules that make every project easier than the last.

This page isn't me offering to build your portal. It's better than that: it's how you stand up the same kind of machine yourself, so you can build your own projects — as many as you want, as fast as you can think them up.

None of this is theory. Everything below is exactly how my platform runs today, live, in production. Steal all of it. And when you get stuck, call me — I've already hit most of the walls, and I'll walk you through them.

Start here See what it builds

You own the boxOne cheap server you control — every app, every byte, every key decision yours.

The agent does the typingAn AI coding agent in a terminal builds and operates it — you direct, verify, and decide.

The system remembersMemory is written files on git. Every lesson learned becomes a rule it never forgets.

The idea: stop building apps, start building the builder

Most people open an editor and start typing an app. Six months later they have one fragile app and no memory of why anything is the way it is. The move that changed everything for me was building the system first:

One box you own. A single modest Linux server runs everything — dozens of apps in my case. Not a constellation of cloud services you rent and half-understand: one machine you can hold in your head.
One front door. A single reverse proxy (I use Caddy) with a wildcard domain. Every new project is a small config block and a folder — HTTPS is automatic, and shipping app number twenty feels identical to shipping app number one.
An AI agent in a terminal, with real autonomy. The agent writes the code, runs the commands, fixes what breaks — end to end. Your job moves up a level: describe what you want, set the rules, verify what comes back.
Memory as plain files. The agent forgets each session; the system must not. Everything worth knowing — how it's built, why decisions were made, what bit you last time — lives in markdown files the agent reads at the start of every session.
Everything on git, automatically. Code and memory both. If the box dies or you sit down at a different machine, you clone and continue exactly where you left off.
Guardrails where mistakes are irreversible. For you that's crypto: keys, spends, broadcasts. The system is built so the dangerous paths fail closed and nothing goes live by accident.

The result compounds. Each project adds patterns, rules, and scar tissue to the system — so the next one ships faster and safer. That's the machine. The apps are just what falls out of it.

The parts list

Everything here is cheap, boring, and replaceable on purpose. No exotic infrastructure — the leverage is in the method, not the parts.

The box

A small VPS from any provider — a few dollars a month runs a whole platform. Debian or similar, and you get root.
A domain with wildcard DNS pointed at it, so anything.yourdomain.com resolves without touching DNS again. Every project gets its own subdomain for free.
systemd to supervise every backend: each app is a service that starts on boot and restarts itself if it dies. You don't babysit processes.

The front door

Caddy as the only web server. One small config file per subdomain; TLS certificates are issued and renewed automatically. You never hand-manage HTTPS again.
A repeated app shape: static files for the page, plus (when needed) a tiny backend listening only on localhost, reachable solely through the proxy. Nothing is exposed directly to the internet.

The agent

An AI coding agent that lives in your terminal — a flat-rate subscription, running in a persistent tmux session on the box, so work survives you closing your laptop.
A rules file it reads every session — who you are, how the box is laid out, what it may do alone, and what it must never touch. This one file is the difference between an agent and a liability.

The memory & the vault

Git everywhere: every project is a repo with a private bare mirror, and a timer auto-commits and pushes every few minutes. Keep a clone on at least one machine that isn't the box — your laptop is fine — and losing work becomes structurally impossible.
Per-project memory files, versioned with the code: current state, architecture and why, an append-only decision log, and a gotchas file. More on these below — they're the heart of it.
An encrypted secrets vault (I use age encryption) for every API key and credential. Secrets are fetched by name at runtime and never written into application code.

The method: rules that make it compound

The parts are an afternoon of setup. The method is what makes the machine worth having — these are the working rules I actually run under, learned the hard way:

Memory is the product

Four files per project: a state file (where things stand, rewritten freely), an architecture file (how and why), an append-only decision log (dated; decisions get superseded, never silently rewritten), and a gotchas file (current truths and traps — later entries win).
The decision log is sacred. It's what stops a later session — yours or the agent's — from confidently undoing a choice you made for a reason. A decision that only exists in a chat transcript is a decision that's gone.
Write memory before finishing, every session. The agent reads it first thing next session. That loop is the whole trick.

Scaffold by script, not by memory

One command creates a new project — repo, mirror, sync registration, memory files, all together — because any step a human has to remember is a step that eventually gets skipped. I learned this by shipping a project that committed into a void for an hour because its mirror never got created.
Automate every recurring operation into a plain script with no AI in the loop. The agent writes the script once; after that, a timer runs it deterministically. Reserve the agent for judgment, not chores.

Direct the agent like an operator

Give real autonomy inside written limits. Mine works end to end without asking permission — but the rules file spells out the carve-outs: it never creates accounts, never types passwords, never enters payment details. Hard lines, in writing.
Every rule carries its reason. A bare rule gets optimized away by a future session; a rule with its "why" attached survives and generalizes.
Root cause, not patches. When something breaks, find why, fix the why, write it in the gotchas file. The same failure should never be learned twice.

Verify like the number is money

Adversarially verify anything you'll act on. Cross-check important numbers two independent ways. I do this because people order real material off my numbers — and your case is harsher: your numbers move coins.
Mutation-test your checks: plant the exact defect a check is supposed to catch and prove it fires. A check that's never seen its bug is a decoration.
Correct the record out loud. When a number moves, say so explicitly — silent corrections destroy the trust the system is built to earn.

Crypto guardrails: where your system must fail closed

Everything above applies to any project. This section exists because yours are crypto, and crypto mistakes don't roll back. These are the rules my live money code runs under — build them into yours from day one:

Keys

Non-custodial by default. User keys are generated and used for signing in the user's browser; your server only reads chain state and relays signed transactions. The strongest security posture is not holding the thing at all.
Deterministic signing (RFC 6979, low-S, strict DER) so there's no random-nonce failure mode, and known-answer self-tests that must pass before the signing code is allowed to sign anything.
If a server-side key is unavoidable (minting), isolate it: signing happens in a separate offline step that cannot broadcast, and the key material is wiped on success and on error.

Spends

Classify every coin before spending it — plain funds versus inscription, token, or other asset. Anything unproven is held back. This is the rule that stops an NFT from being burned as a network fee.
When the system can't be sure, it stops. Indexer unreachable? Halt — don't guess. "Not confirmed yet" is a wait, not a failure.
Integer money math only. Base units end to end; floating point never touches an on-chain amount.

The kill-switch

One money engine, not many. Put all key handling, signing, and broadcasting in exactly one codebase every project calls into. One place to review, one place to fix, and no copy-pasted money code drifting out of date.
Dry-run by default. A fresh deploy of anything that can spend must come up unable to broadcast. Going live is a separate, deliberate operator act — and the check is fail-closed, so any error reads as "off."
Automation follows rules, never judgment. My mint fulfills paid orders autonomously and a watchdog auto-resumes stuck ones — but only inside rules I switched on: known-remediable failures, confirmed funds, a hard retry cap. Nothing automated ever improvises with money.

What this machine has built

One person, directing the system described on this page. These are live — open them and kick the tires:

Live

GOD SAVES

godsaves.hankelsner.tech

The complete King James Bible on Dogecoin — 31,102 verses, each a one-of-one inscription, sold through a mint that fulfills paid orders autonomously under the guardrails above.

Live

Doge Wallet

doge.hankelsner.tech

A non-custodial Dogecoin wallet for DOGE, DRC-20 tokens, and Doginal NFTs. Keys and signing stay in the browser; every spend goes through fail-closed coin classification.

Live

BLUE COLLAR

bluecollar.hankelsner.tech

A fully built, ready-to-inscribe 250-piece Doginal collection for the 25 skilled trades — deterministic art, quota-enforced rarity, and the exact inscription bytes served publicly for verification.

Live

The platform itself

hankelsner.tech

Dozens more production apps under the same roof — inventory a work crew depends on, safety tools, a time clock, family finance — all built and operated the same way. The crypto sites aren't the exception; they're the pattern.

Your first week

You can have the skeleton of this machine running in days. A working order:

Get the box and the door. Rent a small VPS, point a domain's wildcard DNS at it, install Caddy. Put a hello page on a subdomain and watch HTTPS come up on its own. That felt like magic to me the first time; it still ships every one of my sites.
Move the agent in. Put an AI coding agent in a tmux session on the box. Write its rules file: the layout of the machine, what it may do alone, its hard carve-outs. Small file, biggest lever.
Wire up continuity. Bare git mirrors on the box, every project a repo, a timer that auto-commits and pushes. Then write the scaffold script so a new project gets repo + mirror + memory files in one command, every time.
Ship one real app end to end. Something small you'll actually use. Static front, tiny localhost backend behind the proxy, systemd service, memory files written. This teaches the whole house pattern in one pass.
Add the vault, then the guardrails. Encrypted secrets store first. Then, before any crypto code exists: the one-money-engine rule, classify-before-spend, and dry-run-by-default. Guardrails go in before the money does.
Go deeper. I teach this whole system — the pattern, the agent direction, the verification discipline, the war stories — at THE SCHOOL (ai.hankelsner.com). The Foundations module is free. Start there, then work the labs.

And you don't have to do it alone — that's what the phone number is for.

Call me when you're ready — or stuck

I'll help you pick the VPS, sanity-check your setup, and get you past the walls I already hit. Straight answers, no funnel.

hank@hankelsner.tech

+1 (650) 649-4265

Poke at the live sites first if you want — godsaves, doge, bluecollar — then start with the free Foundations module. Build the machine, Eden. The projects will follow.

— Hank