This site didn't start this way.
It started with Webflow: fast to launch, good-looking, the obvious choice when you want something professional without spending weeks on infrastructure. I used it until I hit the ceiling. The pricing climbed, but that wasn't the real problem. The real problem was that the things I wanted kept running into walls: interactive charts inside articles, custom rendering components, full control over the publishing pipeline. None of it was in the product. So I exported the HTML, stripped it down, and rebuilt the pieces that mattered.
What I have now: a blog with a custom Markdown parser, a CRM that lives in a Google Sheet, a robotics research dashboard that runs on a GitHub Actions cron job, and a notes system built on plain Markdown files. I can describe every piece in two sentences, and nothing on the list can surprise me: no price-increase email, no break because a vendor shipped a major version.
The robotics dashboard is the clearest example. It looks like a live data product: a page that updates weekly with new papers, runs LLM passes, surfaces research clusters. Under the hood it's a Python script, a weekly cron schedule, and an HTML page that reads a JSON file. No database. No subscriptions. No framework to migrate when a major version drops. The dependencies are the Python standard library, a handful of API calls, and browser-native HTML. The standard library and the HTML should outlive me. The API calls are the one part I expect to fix someday: outside services change, and when one does, I'll patch the few functions that talk to it. That's an afternoon, not a rebuild. Strip the APIs out and it still runs.
Off-the-shelf gets this backwards. It's bloated with features I won't use and still can't do the one thing I want. What I built has exactly what I want and nothing past that. The math only tips once the cost of building it yourself drops far enough to be worth it.
Web wasn't my terrain. I've written systems software (mostly C++, some embedded), and JavaScript was not where I started. A few years ago, building this myself would have meant weeks of fighting unfamiliar tooling, which is exactly why Webflow made sense: renting was cheaper than learning.
AI is what collapsed that cost. The build pipeline, the Plotly config, the serverless patterns. I got there by asking good questions and iterating on the output.
But generating code is not the same as understanding a system, and the design decisions had to stay mine. What to include, what to leave out, what to own and what to rent. You can't prompt your way to a philosophy about dependencies. The limit I kept returning to was one question: will I understand this in six months? When the answer was no, I cut it, no matter how good the generated version looked.
If I can read my data without a specific application, the vendor holding it doesn't matter. The CRM is contacts in a Google Sheet: rows I can download as CSV in ten seconds. Google can raise its pricing or kill Apps Script; I move a file. The notes are plain Markdown: a wikilink is just the note's name wrapped in brackets, and the build step renders it into a hover preview and a linked reading experience, but strip the renderer and it's still readable in any editor. Obsidian could disappear tomorrow and I'd lose nothing. The site is HTML on Vercel. If Vercel doubles its price, the files move to any static host.
None of those vendors are "owned," and none of them need to be. The data is portable, so I can leave any of them by default. I'd use Stripe for payments on the same logic: customers and payment history export cleanly, and rolling my own processing would just trade a vendor for my own worst code on something expensive to get wrong.
The only dependency worth fearing is the one you can't read your way out of: content in a proprietary format, a workflow fused to one platform's model, data in a database only their software understands. Everything else is just a host, and hosts are interchangeable. Markdown, CSV, flat JSON: boring when I chose them, and the entire reason I'm flexible now.
The discipline behind all of this is boring: use the most basic tool that does the job, and don't build anything more until the simple version actually hurts, not "might hurt someday," but hurts now, in a way you can feel. A Google Sheet is a fine CRM until it isn't. A cron job and a JSON file are a fine pipeline until they aren't. That's also the honest answer to "does this scale?" It doesn't have to. A team of ten hits the pain sooner than I do, so they add more when it hurts. Same rule, different threshold. Pre-building for problems you don't have yet is just carrying weight you didn't need.
The stupid-simple fix is my favorite kind: the flat file, the one-liner, the thing you can explain in a sentence. Which is the exact opposite of how AI wants to code. Point an agent at a problem and it reaches for a framework, a few abstractions, a config layer. A whole pile of code, when you already know you just need one small thing that does the one thing. Left alone it defaults to volume; pulling it back to the size of the actual problem is most of the job.
All of this has a downside. A stack only you understand is great until you're not the one running it. The day you want to hire someone, take a real vacation, or sell, "I can describe every piece in two sentences" turns into "and nobody else can." But the boring formats save me here too. There's nothing proprietary to hand off. Anyone can open a Markdown file or a CSV and know what they're looking at. The same portability that lets me leave a vendor lets someone else take over. The code takes someone who knows what they're doing, but there's not much to know: plain HTML and JavaScript, no React, no giant build framework to learn before you can read line one. The build step is a small file I wrote that does the few things I want and nothing else. That was the point of keeping it boring.
None of this means you can skip knowing what you're doing. You still need someone who can tell a good system from a bad one, who knows what to build, what to cut, and when the generated code is quietly wrong. AI doesn't supply that judgment; what it removes is everything around it that was never the point: the unfamiliar tooling, the boilerplate, the days of setup with no bearing on the thing you're actually making. And those agents aren't a fad to wait out; they're here, and they make a capable person faster than they've ever been. The cost of building exactly what you want has collapsed, for the people with the judgment to aim it.