My library was named after my high school nickname. That was the first sign.

I have been trying to build a personal website since my girls were born. That was twelve years ago — twin daughters, now seventh-graders, who have outgrown more iterations of this site than I'd like to admit.

I would make real progress, hit a wall, walk away frustrated, and come back six or twelve or eighteen months later with whatever new technology had shown up in the meantime — convinced this time I'd finish it. Each restart felt like a fresh start. None of them were. They were all the same project, and the project kept losing.

This post is about the moment I finally figured out why.

The thing under the thing

The website I kept failing to finish is the one you're reading this on. dougwilliamson.online — a place that's mine, not a corporate profile, not a LinkedIn page, not a Twitter handle that could disappear if someone changes a policy.

To build it, I needed components — the buttons, the cards, the headers, the layouts that every site is made of. And here's where developers and non-developers diverge for a moment: a developer will instinctively want to build those components once, in a reusable bundle, and then use them across every project they ever build. We call that bundle a library. The idea is that if you build the button well one time, you never build a button again.

So somewhere along the way I decided I wasn't just building a website. I was building a UI library — a set of pre-made interface pieces — and the website would be the first thing to use it.

I named the library ng-rhombus. ng because it was built in Angular, the framework I use. Rhombus because it was my high school nickname.

I shipped it to npm — the public registry where developers share their code with each other — back in February. A few months later, I was rebuilding the whole thing from scratch under a new name.

This is the part of the story where I'd usually tell you it was broken. It wasn't. ng-rhombus worked. It did what I built it to do. The problem was quieter than that, and I think a lot of people — developers and otherwise — are sitting on their own ng-rhombus right now without realizing it.

What it actually was

ng-rhombus started as a hand-made Angular UI library — buttons, scaffolding, the kind of small repeatable pieces you build because you keep retyping the same patterns and one day decide you've had enough. I built it slowly. Half-finished for a long time. Then AI tools got good enough that I could actually finish it, and I did, and I shipped it.

Here's the part I had to admit later: I didn't ship it for anyone. I shipped it because I could. Completion was the goal. The audience was a footnote — and the footnote said "me."

That's a fine reason to publish something. I want to be clear about that. There is nothing wrong with putting your notebook online. The mistake isn't doing it. The mistake is mistaking it for a product.

The conversation that wasn't a conversation

I'd love to tell you there was a moment — a peer pulled me aside, a tweet that hit different, a single afternoon where the whole thing reframed itself. There wasn't. It was inner dialog. Perfectionism doing what perfectionism does, circling something until I couldn't ignore it.

The thing I was circling was a longer-term strategy. I wanted reusable libraries that could scale. Maybe monetize, eventually. Real product trajectory, not just personal infrastructure. And every time I looked at ng-rhombus through that lens, the same thought came back: this isn't that. This is the thing I made before I knew I wanted to make that.

The name was the tell. Rhombus was my high school nickname. It meant something to me. It meant nothing to anyone else. You cannot put "named after the author's high school nickname" on a thing that wants to be taken seriously, and the gap between what the name signaled and what I actually wanted to build was the whole problem in miniature.

The rename wasn't cosmetic. The rename was an admission.

I think this is also why the website kept failing for twelve years. Each previous attempt was the same shape: a personal thing, named for me, built in whichever technology I was excited about that month. Every restart was a chance to pick a new tool. None of them were a chance to pick a new intention. The tools changed. The bar didn't. The bar was always "good enough for me," which is a moving target that keeps moving.

What FolioKit had to be that ng-rhombus couldn't

Once I let myself start over, the structural decisions made themselves — and most of them weren't decisions I would have bothered with on ng-rhombus, because ng-rhombus didn't have the ambition to require them.

The first one: I split the project into a suite of smaller pieces instead of one big package. (In developer terms: an Nx monorepo with separate libraries for @foliokit/models, @foliokit/api, and so on. In plain terms: one workshop with several specialized benches, instead of one toolbox where everything is jumbled together.) ng-rhombus was a single package that did several things, which is fine when you're the only person using it. The moment you imagine someone else reaching for it — needing one piece without the others — single-package architecture becomes a liability.

The second one: a real backend. ng-rhombus had a backend story that was, generously, vibes. FolioKit has a real one — proper data storage, login security, server-side operations that happen safely on a server instead of in a user's browser. That's not a feature; it's a baseline. But it's a baseline I would not have built into ng-rhombus, because ng-rhombus didn't need it. I didn't need it. The audience of one was satisfied without it.

This is the part that took me a while to internalize: the bar of "works for me" and the bar of "works for other people" aren't on the same axis. They're different products. You don't get from one to the other by polishing. You get there by deciding, and then rebuilding around the decision.

The growing pains part

I won't pretend the rename felt great. There was sunk cost in there — months of work under one name, an npm package I'd told people about, a small but real attachment to seeing ng-rhombus in my own projects. Some grief. Mostly, though, it was growing pains. The kind you accept as part of the process, because the alternative is staying small on purpose.

Twelve years of false starts will teach you which kind of frustration is worth listening to. The frustration that says this tool is wrong, try a new one is usually a lie. The frustration that says this thing isn't what it needs to be, and you've been pretending it is — that one is telling you the truth.

I'd rather build something that has to earn its name than keep something that already has mine.

If you're sitting on your own ng-rhombus

Maybe yours isn't a library. Maybe it's a novel you keep restarting, a business idea you keep renaming, a habit you keep reframing instead of doing. The shape is the same.

The question isn't is this thing good? It probably is. The question is who is it for?

If the honest answer is "me" — keep going. There is nothing wrong with making something for an audience of one. Just call it what it is, and don't let the act of publishing convince you it's something else.

If the honest answer is "other people" — the name, the shape, the standards, and the bar all need to change. Probably more than you think. You can't ship a notebook and call it a product, and the longer you try, the harder the eventual rename gets.

FolioKit isn't done. But it knows what it is. ng-rhombus never did.

And the website you're reading this on? It's been twelve years coming. Turns out the thing I needed wasn't a new framework. It was a new intention.