Why we still bet on boring infrastructure
The most durable AI systems are built on the most boring infrastructure. S3, SQS, Lambda, Postgres — not because we lack imagination, but because boring scales quietly.
There is a version of this industry that runs on novelty. New vector databases, new orchestration frameworks, new model providers — a new layer to add to the stack every quarter.
We don’t run that version.
The systems we build use S3, SQS, Lambda, Postgres, and occasionally RDS. Not because we haven’t looked at the alternatives, but because we’ve looked at them carefully and concluded that the interesting part of the problem is rarely “which database.”
Boring infrastructure has predictable failure modes
When something breaks on AWS primitives, there is a decade of Stack Overflow threads, runbooks, and post-mortems explaining what happened and how to fix it. The failure modes are documented. The oncall rotation has seen them.
When something breaks in a system built on a framework that raised its Series A six months ago, you are alone.
Boring infrastructure is owned, not rented
Every abstraction above the cloud primitive is a dependency. Some of those dependencies are worth it. Most of the AI-specific ones are not, because the marginal value over writing it yourself is smaller than the marginal risk of it disappearing or changing its pricing when you’re not looking.
We have yet to recommend a vector database to a client that couldn’t use Postgres with pgvector. We have yet to recommend an orchestration framework that couldn’t be replaced by a queue and a Lambda function.
What we do pick carefully
The model provider. The prompting approach. The validation layer between model output and any system of record. These are the places where the right choice is non-obvious and where the wrong choice is expensive.
Everything else: use the thing that’s been running quietly in production for ten years. Let the interesting part be the thing you’re actually trying to build.