The Tools AI Won't Recommend: Six Pieces of Software Hiding in Plain Sight

The Hugo Problem

Ask any AI assistant to help you build a website. You will get React. You will get Next dot js. You will get Vercel for hosting, probably a Postgres database for good measure, and a build pipeline that takes ninety seconds to produce four megabytes of JavaScript so that a button can change color. None of it is wrong, exactly. All of it is overkill for what you actually asked.

Mention Hugo, the static site generator written in Go, and the same AI will cheerfully build you a website that compiles a thousand pages in under a second, deploys as plain HTML files, and never needs a database at all. The AI knew about Hugo the whole time. It just did not suggest it.

The question worth sitting with is why. Why does the same model that contains the entire history of computing default to the most expensive answer? The answer turns out to be simple, and it has nothing to do with the quality of the tools.

The model was trained on what people wrote on the internet. People on the internet write about what they get paid to write about. Vercel has a marketing team. The maintainer of the static site generator you have never heard of does not. So the AI learns that React is the answer the way a child learns that the sky is blue. Through sheer repetition.

What follows is six pieces of software that quietly run serious infrastructure while the AI keeps suggesting something more famous. The point is not to memorize them. The point is to learn the nouns, so the next time you ask for help, you can steer.

SQLite Is the Database

In the year two thousand, the United States Navy needed a database for a missile destroyer. The destroyer was the USS Oscar Austin, hull number seventy-nine, a guided missile platform with a small crew and no database administrator on board. The database had to run on the ship. It had to run without a server process that could crash in heavy seas. It had to fit in a single file that could be copied if something went wrong.

A programmer named Richard Hipp, with a doctorate in computer science from Duke, took the contract. He wrote a small library in C that he intended as a stop-gap. He called it SQLite. He released it into the public domain, with no license at all, because he wanted as few obstacles to adoption as possible.

By most credible estimates, SQLite is now the most deployed piece of software ever written. Every iPhone has one. Every Android phone has several. Every web browser uses it. Every commercial airplane runs on it somewhere in the avionics stack. The total deployed instance count is in the trillions.

And yet when you ask an AI to help you with a backend, you almost never get SQLite as the answer. You get Postgres. You get MySQL. You get MongoDB. The bias toward client-server databases is so strong in the training data that the obvious option, the one that runs the world from inside other programs, gets quietly skipped.

Then in twenty twenty, a programmer named Ben Johnson released Litestream. Litestream watches the SQLite write-ahead log and streams every change to object storage in the background. Your database is a single file you can copy. Your backup is continuous. Your disaster recovery plan is, boot a new machine, pull the file. Companies like Tailscale and fly dot io run real production loads on SQLite plus Litestream. The indie developer Pieter Levels runs an entire portfolio of profitable products on it.

The thing the AI will not tell you, unless you ask: for the vast majority of side projects, internal tools, and a surprising number of real products, you do not need a database server. You need a file.

htmx Says No

The next pick is a refusal disguised as a library. In twenty twenty, a computer science instructor at Montana State University named Carson Gross released version one of htmx. The promise was small. It was a JavaScript library that lets ordinary HTML elements make HTTP requests and swap in HTML fragments without you writing any JavaScript at all.

The implication was enormous. If your server returns HTML, you do not need a single-page application. You do not need React. You do not need a state management library. You do not need a build pipeline. You do not need to ship four megabytes of JavaScript to a browser that already knows how to render HTML, which is the format the entire web was built on in the first place.

Carson called the underlying philosophy hypermedia as the engine of application state. The acronym, painful as it is, is HATEOAS. It traces back to Roy Fielding's doctoral dissertation on REST in the year two thousand, the same year SQLite shipped. The web was originally designed to work this way. Then frontend frameworks ate the world for fifteen years, and now a small but growing crowd is remembering.

htmx is now used in production by the United States Air Force, by parts of Bandcamp, and by selected pages on GitHub. The community has a running joke about being right by being twenty years late. When you ask an AI to build a typical CRUD application, you will get Next dot js. Mention htmx and the same AI will happily rebuild the same app in a tenth of the code, with no build step, and a load time measured in milliseconds.

The tool listens for nouns. You have to know the noun.

DuckDB Eats Pandas

In Amsterdam, there is a research center called CWI. The full Dutch name translates to the Center for Mathematics and Computer Science. CWI is where Guido van Rossum invented Python in nineteen eighty-nine. Thirty years later, two researchers at the same institute, Mark Raasveldt and Hannes Mühleisen, asked a similar question. SQLite gave the world an embedded transactional database that runs inside other programs. Why is there no embedded analytical database?

They built DuckDB. It compiles to one binary. It runs inside your Python process or your Node process. It executes columnar analytical queries at speeds that compete with full data warehouses costing tens of thousands of dollars a month. It reads Parquet, CSV, JSON, and Excel files directly from disk, from URLs, from S3, without copying them first. The first stable release was in twenty nineteen.

The default move for any AI asked about data analysis is to suggest pandas. Pandas is fine until your data does not fit in memory, or your aggregations start taking six minutes, or you actually want to use SQL instead of remembering the difference between loc and iloc. DuckDB does the same work in seconds, with standard SQL you already know, and the integration is one line of code.

The deeper shift is that DuckDB plus SQLite together make the case that an enormous amount of what gets called production database work is actually analytical work that wants to run next to the data, not across the network from it. That is not a story any cloud vendor will tell you. It costs them money. So the AI, trained on what cloud vendors and their consultants write, will not tell you either.

uv: Python Rewritten in Rust

For two decades, Python tooling was a swamp. You had pip for installing packages. You had virtualenv for isolating them. You had pyenv for switching versions. You had pip-tools for locking dependencies. Or you had poetry, or pipenv, or conda, or pdm. Each one solved part of the problem and added two new ones. New Python developers spent their first week not learning Python. They spent it learning why their virtual environment was broken.

In February of twenty twenty-four, a company called Astral released uv. The same team had previously released a Python linter named Ruff, which does the combined work of Pylint, Flake8, isort, and Black, all written in Rust, somewhere between ten and a hundred times faster than the tools it replaces. Ruff took over the Python linting world in about eighteen months.

uv does the same thing for package management. It installs. It locks. It manages Python versions. It creates virtual environments. It is a single binary. It does not require Python to bootstrap, which solves an entire category of chicken-and-egg problems. Installing a hundred packages, which used to take two minutes, takes two seconds. Resolving a dependency tree that used to require thirty seconds of waiting completes before you notice.

The founder of Astral is Charlie Marsh, who worked at a series of finance and tech companies before deciding the Python tooling situation was unacceptable and someone needed to fix it. He hired serious systems programmers and pointed them at the worst-papered corner of the Python world.

If you ask an AI today to set up a Python project, you will still get advice from twenty nineteen. You will get pip and virtualenv and a requirements file. Say the word uv, and you skip five years of accumulated trauma in a single sentence.

Caddy Just Works

The web server space, for fifteen years, was effectively a two-player race. Apache had market share by inertia. nginx had market share by being faster and easier than Apache. Both required you to learn a configuration syntax that read like a haunted INI file. Both required you to manually request HTTPS certificates, configure them, set up auto-renewal, and pray that the cron job worked correctly at three in the morning when your certificate was about to expire.

In twenty fifteen, a programmer named Matt Holt built a web server in Go called Caddy. The defining feature was simple and revolutionary. Caddy automatically requested and renewed HTTPS certificates from Let's Encrypt. You did not configure HTTPS. You just had it. The configuration file, called a Caddyfile, was usually three or four lines.

This was three years before anyone in the industry considered automatic HTTPS to be a baseline expectation. nginx, as of right now, still does not do it out of the box. You can plug in a tool called certbot and stitch it together, but the experience is exactly as fragile as it sounds.

Caddy is now used by Stripe, by a long tail of smaller shops who got tired of nginx configuration files, and by a growing number of self-hosted setups. It supports reverse proxies, load balancing, modern protocols, plugins, and the rest of the modern web server feature list. It is one binary you drop on a server, with a four-line config, and HTTPS works.

When you ask an AI to help you deploy something, you will get nginx. You will get a fifty-line config file. Mention Caddy and the same AI will gladly hand you the same setup in five lines, including the part where the certificates manage themselves.

just Is Make Without the Trauma

Every project of any size needs a task runner. A command for run the tests. A command for build the documentation. A command for deploy to staging. The traditional answer is Make, which is forty-eight years old. It was designed in nineteen seventy-six for compiling C programs on early Unix systems. It famously uses tab characters for indentation, not spaces, and if you use spaces by accident your Makefile fails in a way that gives you no useful error message at all. This single design choice has, by conservative estimate, cost the software industry seven hundred million collective hours of debugging.

In twenty sixteen, a programmer named Casey Rodarmor released just. It looks like a Makefile. It reads like a Makefile. It does not care whether you use tabs or spaces. It has no implicit rules quietly compiling things behind your back. It does not try to be a build system. It is a task runner, full stop. That is the whole mental model.

You write a file called justfile. You list your commands. You type just test, or just deploy, and the corresponding recipe runs. There is nothing else to learn.

Casey Rodarmor went on to invent Bitcoin ordinals in twenty twenty-three, which is either a strong recommendation or a strong warning depending on how you feel about cryptocurrency. Either way, the man clearly knows how to ship working code.

When you ask an AI to set up a project, you will still get a Makefile, or worse, a folder of unrelated shell scripts named build dot sh and deploy dot sh and run dot sh. Say use just, and the AI will happily collect all your commands into one clean justfile that anyone on the project can read.

The Pattern

Step back and look at the six picks. SQLite. htmx. DuckDB. uv. Caddy. just. None of them have venture funding. None of them have a marketing budget. None of them have a conference booth at the big industry events. Most of them are maintained by one person or two people who care more about the work than about the brand.

The AI you talk to was trained on text written by humans on the internet. Humans on the internet write about what they get paid to write about. They write about Vercel because Vercel sponsors their newsletter. They write about Postgres because Postgres is what their employer pays them to know. They write about Kubernetes because Kubernetes consulting pays seven hundred dollars an hour. The folk-knowledge tools, the ones that quietly do the job for almost nothing, do not generate marketing collateral. They show up in the training data at a much lower density.

There is a name for this pattern. The anthropologist James C. Scott called it legibility. States and large institutions prefer the tools they can see, count, and standardize. Kubernetes is legible. SQLite is folk knowledge. React is legible. htmx is folk knowledge. Vercel is legible. Caddy is folk knowledge. The legible tools dominate the conversation. The folk-knowledge tools dominate the actual work, quietly, in the basement of a thousand profitable companies that never blog about it.

The trick, if you want better software at a lower cost, is to learn the folk names. Once you have the word, the AI listens. The moment you say use SQLite with Litestream, or use htmx, or use uv, the same model that defaulted to the expensive answer will happily build you the cheaper, simpler, better one. The model is not stupid. It is biased toward the legible.

The job is not to know more than the AI. The job is to know enough nouns to steer it. Six new nouns, for the drive home.