Built to Own

This site did not start this way.

It started in Webflow. Fast to launch, good-looking, the obvious choice when I wanted something professional without spending weeks on infrastructure. I used it until the things I wanted kept hitting the edges of the product: interactive visuals inside articles, custom rendering, control over the publishing pipeline. The pricing climbed, but that was not the reason I left. I left because I could not build what I wanted inside it.

So I exported the HTML and rebuilt the pieces that mattered.

What I have now: a blog compiled from Markdown, a CRM in a Google Sheet, a robotics research dashboard on a weekly cron job, and a notes system made of plain files. I can describe every piece in two sentences. That is the constraint.

The robotics dashboard is the clearest example. It looks like a live data product. New papers every week. LLM summaries. Research clusters. Underneath: Python scripts, a cron schedule, JSON, and one HTML page that reads it. No database. No framework waiting for its next migration.

The files and HTML should outlive me. The Python libraries and APIs will not. Someday one will change and I will patch the few functions that talk to it. An afternoon, not a rebuild. Remove the APIs entirely and the last generated version still works.

Off-the-shelf software gets this backwards. It carries features I will never use and still cannot do the one thing I want. What I built does exactly what I need and stops there. That only makes sense once building becomes cheap enough.

What changed

Web is not my terrain. I work mostly in C++ and Rust. 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 collapsed that cost. The build pipeline, the visualization configurations, the serverless patterns.

But generating code is not understanding a system. The design decisions stayed mine. What to include. What to leave out. What to own and what to rent.

You cannot prompt your way to a philosophy about dependencies.

I kept returning to one question: will I understand this in six months? When the answer was no, I cut it. It did not matter how good the generated version looked.

Data format matters more than the host

Ownership is not where the data lives. It is whether I can leave with it.

The CRM is rows in a Google Sheet. I can export them as CSV in ten seconds. Google can raise the price or kill Apps Script and I move a file. The notes are Markdown. A wikilink is a name inside two brackets. The build turns it into previews and linked reading, but any text editor can still open the source. Obsidian can disappear and the notes stay mine. The site is HTML on Vercel. Vercel can disappear and the files move to another static host.

I do not own any of those vendors. I do not need to. Portability gives me the right to leave.

I would use Stripe for the same reason. Customer records and payment history export cleanly. Building my own payment processor would trade a vendor for my worst code in the most expensive place to be wrong.

The dependency to fear is the one you cannot read your way out of. Content in a proprietary format. A workflow fused to one platform. Data that only one application understands. Everything else is a host, and hosts are replaceable.

Markdown. CSV. Flat JSON. Boring formats are what make the system movable.

Start small, resist code growth

The rule is simple: use the most basic tool that works. Add something only when the simple version hurts now, in a way you can name. Not when it might hurt someday.

A Google Sheet is a fine CRM until it is not. A cron job and a JSON file are a fine pipeline until they are not. Does it scale? It does not have to. A team of ten reaches the limit sooner than I do, so they add more sooner. Same rule. Different threshold.

Building for problems you do not have is carrying weight you do not need.

The stupid-simple fix is my favorite kind. The flat file. The one-liner. The thing you can explain in a sentence.

AI pulls the other way. Give an agent a small problem and it reaches for a framework, abstractions, a configuration layer. A pile of code around the one thing you asked it to do. Left alone, it defaults to volume. Most of the job is pulling the answer back to the size of the problem.

Ownership has a downside. A stack only I understand is still a dependency. The dependency is me.

That matters when I hire someone, take a real vacation, or sell. But the same boring formats help again. There is nothing proprietary to hand off. Anyone can open Markdown or CSV and know what they are looking at. The portability that lets me leave a vendor lets someone else take over from me.

The code still takes someone who knows what they are doing. There is just less of it to know. Plain HTML and JavaScript. No React. No giant framework before line one. The build is one small file that does the few things I need and stops.

AI did not remove the need for judgment. Someone still has to know what to build, what to cut, and when generated code is quietly wrong. It removed the toll around that judgment. The unfamiliar tooling. The boilerplate. The setup with no bearing on the thing being made.

AI collapsed the cost of building. Judgment is still the cost of owning.