That's not a rhetorical setup — it's true, and worth saying plainly before anything else on this page. Your AI can scaffold a working API, a data model, and a handful of endpoints over a weekend. The question that actually matters is what happens in the weeks after.
This isn't an anti-AI page. We write code with AI assistance every day, and we design every block to be driven by an agent — clear REST contracts, predictable errors, documentation written so an LLM can actually parse it. If your AI can stand up a working prototype in a weekend, that's a real win: faster iteration, less boilerplate, more of your time spent thinking about the product instead of typing it. We're not going to pretend otherwise, and we're not going to tell you to stop.
The question this page answers is narrower: what happens to that weekend API in the second week, the second month, and the second year — and whether the parts underneath it were ever the part worth reinventing in the first place.
Your AI learned from the same tutorials, the same forum answers, and the same starter repos every other engineer learned from — including the same bugs those sources have been quietly reproducing for a decade. Three places that shows up.
Webhook retries that fire twice and double-charge a customer. A sequence that collides after a migration and silently overwrites a row. A session that won't die across two devices after a password reset. None of it shows up in a demo. All of it shows up in production, usually at the worst hour, to the customer with the least patience.
The weekend API works fine until the framework ships a breaking release, a dependency gets a CVE, or the schema needs a migration that can't take the table offline. Maintenance is where weekend code goes to die — not because the code was wrong, but because nobody budgeted the years of upkeep that follow the first commit.
Deployment, monitoring, backups, incident response, on-call, a support ticket at 2am — that's not a checkbox on a feature list, it's a job. Somebody has to own it, every day, for as long as the product exists. An AI can write the endpoint. It doesn't show up when the endpoint goes down.
Ask an AI to write an auth flow and it will produce something that looks correct — because it learned from thousands of examples of engineers writing auth flows, most carrying the same handful of mistakes: sessions that don't expire cleanly, password resets that leak timing information, tenant isolation that works until it doesn't. The industry has already found these bugs, argued about them, and fixed them — many times, in many companies, over many years. That fix doesn't usually make it back into the tutorial.
A battle-tested block is that fix, kept. It isn't a cleverer way to write the same code your AI would write — it's the version that already survived the mistake your AI hasn't made yet. That's the whole idea: solved problems should stay solved.
The blocks are what your AI would write after 35 years of fixing what it wrote.
Vibe-code your product.
Don't vibe-code your auth.
None of this is a blanket argument against building it yourself. There are good reasons to let AI build the whole thing and ship it, no blocks required.
You're validating an idea, not hardening a product. Speed matters more than edge cases nobody will hit before you know if anyone wants this.
Ten people use it, you know all ten, and a bug means a Slack message, not a support ticket. The stakes are simply different.
You're building it to understand how auth or payments actually work under the hood. The point is the education, not the uptime.
Nobody has solved this particular problem before, so there's no 35 years of production mistakes to inherit — you're the one making, and fixing, them now.
The line to watch for is the moment the project stops being any of these — the moment real customers, real money, or real data show up. That's when the already-solved problems stop being optional.
23blocks is 35 years of building software, condensed into ready-to-run backend blocks. Every block is a battle-tested microservice carrying thousands of decisions, mistakes already made and fixed, and lessons from real products in production. The code is open source — what we sell is running it well, so you spend your time on the product only you can build.
Get product updates, engineering posts, and new block announcements delivered to your inbox.