I’ve put five project sites online lately. AltSql, VPN Works, Precomputing, Preconfiguration, BareProxy. Most of that happened in September; BareProxy squeezed in during the first couple of days of October, so parts of it still read like a design note. All five say Alpha or 0.1 right on the page, and I’ll get to why.
The plan was to write each one up separately, like a normal person. Then I lined the five up side by side and had an awkward moment. They’re the same project. Different problems, different users; one runs on a microcontroller, another sits in front of a web server. Under the hood, though, I keep building one thing over and over: a small tool you can ask “why?” and get a straight answer back.
So this is the post about that. It’s long. You’ve been warned.
AltSql, the one that fits in 15 KB
AltSql came first, and it changed how I work. My old habit was concept first: write the big document about the vision, then go build. With AltSql I flipped it. Prototype first, concept second. Build it, poke it until it breaks, then write down what it actually is. A document written after the prototype has a lot less room to lie.
The problem it goes after is a boring one, which is my favorite kind. A connected device keeps its readings in one format while the gateway wants rows in a SQL database, so somebody writes a converter. Then somebody has to babysit that converter for as long as the device stays in the field, and ten years isn’t unusual. That’s a long time to babysit anything.
AltSql takes the converter out. Its core engine compiles to about 15 KB of code for a microcontroller. The device keeps its readings and settings in its own flash, as plain key-value records, and goes on making decisions from its own data when the radio link drops. The gateway stores the very same records, byte for byte, and answers SQL over them. Same bytes at both ends. Nothing in the middle to rot.
The example I keep using is dumb on purpose: switch the fan on if the last ten readings were all above 60°C. That rule runs on the device itself, no round trip to anything. The dashboard asks about the same ten readings with one SELECT on the gateway. The How It Works page puts both halves next to each other (a few lines of C, one query), and I still like how short they are.
Then I got greedy. One engine turned into a plan for eight: the original plus seven new ideas, each with its own prototype and demo. Six of the new ones exist now, all on the engines page. AltSql Ask sends one SQL question to a whole fleet and brings back only the answers; AltSql Mesh lets devices share a table with no gateway at all. The seventh new one, a private-aggregation engine, is parked. It’s the hardest of the lot, and I’m not putting the word “private” on anything until someone from outside has tried to break it.
Status, plainly: everything so far has run on a PC with the flash chips and radio links simulated. Real chips come with the Beta. The live demos run the actual engine in your browser, compiled to WebAssembly, and you can cut a device’s power in the middle of a write to see what survives. Go ahead and cut it a few times. That’s what it’s there for.
VPN Works, the one that keeps coding agents on a leash
Here’s the bit about coding agents that never makes the landing page. They spend their whole day reading text written by strangers, in issues and on web pages. One planted instruction can be enough to make an agent send a deploy token somewhere it shouldn’t. On a machine-wide VPN that request leaves the same way as everything else, and afterwards nobody can tell you which program sent it.
VPN Works shrinks the network down to one program. The vpnw command seals the agent in a Linux network namespace whose only way out is vpnw itself. A script that ignores proxy settings finds no route anywhere. (I like that sentence a lot.) Every connection gets checked against a short policy and written to a record, then it leaves by the path you picked, direct or through an office proxy.
Day to day it’s four commands: run, trace, guard and learn. The last one is the reason I’d show this project to anybody. Nobody wants to write an allow list from scratch; I certainly don’t. So learn drafts one from a traced run. The agent does its normal work, vpnw writes down everything it reached for, and a human reads the draft and crosses out whatever looks wrong. Editing beats writing. That goes for allow lists, and it goes for blog posts.
One detail I’m a bit smug about: under a default-deny policy, a name that isn’t on the list never even gets looked up. So DNS can’t sneak data out either.
Then it grew a second engine. Scope takes the same watch-first, draft-later trick to the company VPN. It learns from traffic who actually uses which systems and drafts least-privilege rules for the gateway, so one stolen login stops opening the whole office network. Both engines are Alphas, tested on Linux. The live demo replays real runs of an agent trying to leak a token, and you can edit the policy against the real engine, compiled to WebAssembly. Loosen the policy and watch the token walk out the door. Tighten it and watch it bounce.
Precomputing, the one I built problem-first
Precomputing is where I set myself a new rule: start from a problem that costs somebody real money, then work backwards to the tech. Before that rule there was an idea for a cache invalidation engine for publishers. I killed it. Hard problem, tiny payoff.
There’s an old joke that computer science has two hard problems: cache invalidation, naming things and off-by-one errors. In September I lost an idea to each of the first two. The cache one I killed myself. The naming one was killed for me: a log reducer I really liked turned out to sit a little too close to somebody else’s registered trademark in the same field, and that was that. Some projects die in code review. That one died in a trademark register.
The good parts didn’t die, though. Two pieces of it moved into Precomputing: an MCP connection, so an AI agent can ask for a precomputed answer instead of chewing through raw rows, and agent traces where each prompt gets stored only once.
The core idea is almost embarrassingly simple. Most dashboards ask the same few questions all day (requests per endpoint, this month’s usage for one customer), and the usual setup recounts raw rows on every refresh. Precomputing does the counting once, as the data comes in. You write a short policy that names the answers you want and says how long each level of detail should live. It compiles to plain SQLite triggers. Every INSERT keeps the answers current, so reading one is just a lookup. Old detail fades on your schedule; unusual events are kept whole.
What I like most is that it’s still only SQLite. Open the file with any SQLite tool you already have and the answers are sitting there as plain views, with nothing running beside them. When triggers get too slow, a Go engine runs the same policy and writes the same file, value for value. The same policy language also drives a usage meter for billing, where a retried request counts once and a closed month stays closed. I find that last bit weirdly soothing.
It’s version 0.1, checked hard on simulated data and not yet run on anybody’s production traffic. The Policy Language walks through a policy line by line, and the SQL demo pushes three hours of simulated API traffic through a compiled policy in SQLite’s WebAssembly build, right there in your tab.
Preconfiguration, the boring files nobody wants to own
With Preconfiguration I started making myself answer four questions before writing a line of anything. Where’s the money? What real problem does it solve? Can I explain the tech in plain words? And why couldn’t somebody else knock it off over a weekend? It’s the screen you’d run on a startup pitch. Running it on yourself is less fun and a lot more useful.
Preconfiguration was the first project to go through that screen. The problem goes like this. Cloud coding agents start every task on a fresh machine. Before an agent can run a single test, something has to install the right runtime and start the database, and every platform wants those instructions in its own file. Copilot runs a setup workflow; Cursor builds a Dockerfile. Use two or three agents and you write the same setup two or three times, and a mistake usually turns up much later as an agent session that goes nowhere.
So I made the setup files build output. You describe the machine once, in a short preconfig.yaml, and preconfig build writes the file each platform reads. preconfig check reads existing files against each platform’s rules, which catches the quiet mistakes, like a Copilot job with the wrong name. Then preconfig verify does the part no reviewer can do by squinting: it runs the setup on an empty Ubuntu container, then runs the project’s tests. A setup file can look fine and still fail. A machine that started empty and passes the tests is proof, and I’ll take proof over a pretty YAML file any day.
When a setup breaks anyway, Preconfig Doctor reads the log (these can run past a thousand lines; nobody reads those for fun) and names the cause. If the fix belongs in the spec, it writes it there. The part I’m oddly proud of: Doctor has no model behind it. It works from rules, so the same log gets the same answer every time. In 2026 that’s almost old-fashioned. I mean it as a compliment.
Both are Alphas, measured on one Linux machine, and runs on the agent platforms themselves come with the Beta. The live demo mixes recorded runs with the real code running in your browser.
BareProxy, the baby
BareProxy is a couple of days old as I write this, so treat this section like a baby photo. It started as a short design note, on purpose, before any spec or prototype. The first cut of the code was meant to be a one-hour job. The site is a quick mockup on the same template as the others, and it’ll get rebuilt later. Probably.
The itch is nginx. Or rather the thin slice of nginx most sites actually use: TLS, a folder of static files, a couple of routes to an app, health checks, the odd reload. The config grows anyway, one regex at a time, until nobody’s quite sure which block handles a given URL.
BareProxy keeps its core to that slice and turns down regular expressions and scripting outright. Every matcher is an exact value, a prefix or a set. That one restriction buys the thing I wanted most: the requests a site can get fall into a finite number of classes, so the server can check every one of them. Which means it can answer questions.
bareproxy explain takes a URL and tells you which rule matched and which file or backend would serve it. It also tells you why the rules above it didn’t match, which is the part I always wanted from nginx. bareproxy why tells the story of a request that already happened, starting from the ID it carried in a response header. And bareproxy plan, the one I’d actually pay for, compares a new config with the running one before it goes live and lists the requests that would change hands. Write a rule that can never match because an earlier rule eats all its traffic, and you get a warning instead of a mystery.
The core serves a static folder directly too, with certificates from Let’s Encrypt, so a Hugo build needs no second server in front of it. That decision is brand new as well. Caching, rate limits and the rest are modules, compiled in only when you want them. The numbers on the site are design budgets: under 5,000 lines of Go in the core, and no dependencies from outside the Go project. Real speed and memory numbers against nginx come next. Until then the demo page shows each command’s output on a sample config.
So, I have a type
Put the five next to each other and the pattern isn’t subtle.
They’re all small, on purpose. AltSql is 15 KB on a chip. BareProxy has a line budget. Precomputing is a SQLite file with some triggers in it. I keep copying the way SQLite got built (start from practically one file, keep the footprint tiny), and when that didn’t stretch far enough I widened it to the nginx way. Funny thing: I’ve written two static site generators of my own, and every one of these project sites still runs on Hugo. Make of that what you will.
They all show their work. BareProxy explains its routing. VPN Works keeps a record of every connection. Doctor names the cause and gives the same answer twice. Precomputing’s answers are plain views anybody can open. AltSql keeps the same bytes at both ends of the link, so nothing hides in a translation step. I didn’t plan any of that. I only saw it when I lined them up for this post.
They all draft and let a person decide. learn drafts an allow list, Scope drafts gateway rules, Doctor drafts a fix into the spec and plan drafts the list of what’s about to change. A human reads it, crosses things out, then commits. I trust that loop far more than any tool that just goes ahead and does stuff.
They all have a demo you can poke. That started as a practical worry with AltSql: I didn’t want anyone to install anything, or to need my source code, only to see it work. WebAssembly sorted out both, and now every project gets a demo page whether it asked for one or not.
And they’re all honest about being early. Every page says Alpha or 0.1, and every page says what was simulated. AltSql hasn’t touched a real chip yet. VPN Works has only been tested on Linux. Precomputing hasn’t seen production traffic. Preconfiguration has been measured on one machine. I’d rather you read “simulated” from me than find it out the hard way.
One last confession. I gave my own checklist a name. Every project gets the same package (a site with a demo for each engine, plus the documents in Word and PDF), and I call it the Project Package Standard, capital letters and all. It sounds like something a committee wrote. It’s one person with a strong dislike of doing the same setup twice. Which, now that I type it out, is exactly what Preconfiguration is about.
If one of them gets something wrong, ask it why. It’ll tell you.