We Code Econo
We Jam Econo
The Minutemen had a phrase: “We jam econo.” Three guys from San Pedro who made some of the most important music of the 1980s without ever pretending they had a budget. They recorded fast and cheap, booked their own shows, drove their own van, kept the songs short because tape cost money and they had something to say without padding it out. Econo was the whole point. Constraint was the instrument.
Mike Watt still talks about it that way. Econo is a discipline — making the most of what you have and refusing to confuse spending money with solving a problem.
I’ve been writing software since the 90s, and I spent enough years around punk to have absorbed that ethos in a way I can’t shake. I said in an earlier piece that you can take the engineer out of the punk band but you can’t take the punk out of the engineer. This is the part of that I actually want to talk about. Not the anti-authority reflex. The econo part. Because the way the Minutemen made records is, almost line for line, how a small team should build software in 2026.
We code econo.
Throwing Money at the Problem
The corporate reflex is the opposite of econo. The corporate reflex is to throw money and complexity at a problem and call the spending a strategy.
You’ve seen it. A two-person startup with eighteen microservices. A queue, a service mesh, a Kubernetes cluster, and a dedicated observability stack — to serve a few hundred users who would have been perfectly happy with a single deployable and a database. Nobody decided this was necessary. It accreted, one “best practice” at a time, because that’s how it’s done at the kind of company everyone is cosplaying as.
That’s cargo cult engineering. You see the shape of what big companies build and you copy the shape without the thing that made the shape necessary. Netflix has hundreds of services because Netflix has hundreds of teams who need to deploy independently without stepping on each other. You have two people. The microservices buy you a distributed system’s worth of failure modes in exchange for an isolation problem you don’t have.
The establishment told you this was the professional way to build. The punk move is to ask who that actually serves. Usually it serves the vendors selling you the complexity, and the résumés of the people who wanted to play with it.
What Econo Actually Optimizes For
Here’s the part people get wrong about econo. They hear it and think it means do everything yourself, the cheapest possible way. Self-host everything, write everything from scratch, never pay for anything.
That misreads it. The Minutemen recorded cheap, but they didn’t build their own mixing console. They used what was already there and spent their energy on the part that was theirs to make — the songs. Econo is about spending your scarcest resource wisely. For a two-person team that resource is time.
So it cuts both ways.
On one side: don’t over-build your own stuff. A monolith over microservices, almost every time, until you have an actual reason measured in team size and deploy contention rather than in blog posts. One deployable you can hold in your head beats eighteen you have to orchestrate.
On the other side: don’t reinvent the undifferentiated. I reach for Clerk for auth, Neon or Supabase for the database. I am not going to spin up my own authentication infrastructure and a Postgres cluster with failover so I can have the satisfaction of having built it. That work isn’t mine to make. It’s the console; the song is what I’m there for. Paying a few dollars a month to never think about session token rotation is the most econo decision available, because it buys back the only thing I can’t make more of.
The thread that ties both sides together is lock-in. The reason I’ll use Supabase is that there’s standard Postgres underneath it — I can pull my data and walk if I need to. Econo means keeping your exits open. Use the managed service, but pick the one that doesn’t own you. That’s where the anti-establishment reflex and the econo reflex are the same reflex: don’t let a vendor make a decision permanent that should stay yours.
The Default Stack Isn’t the Right Stack
This is where I’ll get some mail.
The enterprise default — the heavyweight framework, the language built for thousand-person orgs — is not the right choice for a small team building with AI agents. And the math changed enough in the last two years that this is worth saying plainly even though it sounds like a language war.
Take Java. I have nothing against the JVM. But in an agent-assisted workflow, enterprise Java works against you on three layers that compound.
First, verbosity and ceremony. Every line of boilerplate is more surface area for the agent to generate, for you to review, and for something to go subtly wrong in. Go says the same thing in a third of the code. Less code is less to get wrong, whether a human or a model is writing it.
Second, the magic. Enterprise Java leans on annotations, dependency injection, XML, framework behavior that happens at runtime through reflection you can’t see by reading the file. Agents reason worst exactly where the behavior isn’t on the page. A uniform, explicit language like Go gives the model clean patterns to follow. Spring gives it a haystack.
Third, the loop. The thing that makes agent development fast is a tight edit-run-verify cycle. Maven and Gradle builds, app server startup, the whole heavyweight toolchain — every second of that friction is multiplied across hundreds of iterations. Tighten the loop and the agent gets dramatically more useful. Slow it down and you’ve capped your own leverage.
All three stack. The simpler and more explicit the language, the more an agent can do reliably.
And here’s the part that keeps this honest: you don’t have to switch languages to code econo. Say Java is where your expertise lives, and you’re not ready to hand an LLM the wheel in a language you can’t review with confidence. Fair. Stay in Java — and still refuse the interface-and-inheritance hell. You don’t need the abstract factory and the six layers of indirection. Java is already more verbose than Go; enterprise Java is verbosity you inflict on yourself on top of that. Econo is a posture you can take inside any language. Strip the ceremony and write the plain version.
AI Made Econo Win
For most of my career, econo was a trade. Doing it yourself, lean and cheap, meant slower and often worse. You accepted that in exchange for independence and for not being captured by some vendor’s roadmap. The Minutemen’s records sound like they cost nothing, and part of the romance is that they didn’t quite compete with what a major-label budget could buy. You picked econo for what it bought you — independence — and accepted that you were playing the weaker hand to get it.
Agents changed that. I’ve written before about giving Claude Code a feature at a time and having a real prototype in a week that would have been a week of research alone the old way. That’s the whole equation flipping. A punk with agents now competes with a funded team. The output that used to require headcount and budget is available to two people who know what they’re doing and refuse to waste motion.
That’s why econo stopped being the romantic underdog choice and became the strong one. The constraint that used to cost you something now compounds in your favor, because the simpler stack and the tighter loop are exactly what makes the agents work. Econo and AI leverage point the same direction.
Knowing When Not To
Econo is a discipline, which means it’s not a dogma. The whole point is judgment, and judgment includes knowing when the cheap, simple answer is the wrong one.
Sometimes you do need the complexity. Real scale, real compliance requirements, real reliability guarantees where the failure cost is measured in lawsuits or lives — those earn their weight. I’ve spent enough time building for regulated industries to know that the boring, heavy, auditable version is occasionally the only honest choice. The senior engineer’s job is to say no, and that no points in both directions: no to the eighteen microservices you don’t need, and no to the duct tape holding up something that actually has to not fail.
Econo means refusing to spend — money, complexity, or your own scarce hours — on anything that isn’t yours to build. Most of the time that points to the simple version. The discipline is knowing which time is which.
The Minutemen never got the budget. They also never needed it, and the work outlasted most of what the budgets bought. Thirty years into writing software, that’s the bet I’d still make. Spend nothing you don’t have to. Build only the part that’s yours. We code econo.