My Website Had Too Many Ideas, So I Fired Most of Them
Last month I opened my website's codebase for the first time in a while and found a graveyard. A half-built newsletter archive. A "now playing" widget that had been showing the same Bon Iver track since 2023. A dark mode toggle wired to a design system I'd abandoned two redesigns ago. The site worked, technically. It just didn't say anything.
So I did what I should've done years ago: I deleted everything and started from one blank HTML file. Here's the honest postmortem — including the features that died and why.
What I Kept: Three Pages and a Promise
The rebuild forced a question I'd been avoiding: if I could only show someone three things, what would they be? For me, the answer was the same on paper and in practice:
- Who I am and what I do — one page, plain language, no buzzwords.
- The work itself — projects with real screenshots and honest descriptions, including the ones that flopped.
- My writing — because the writing is how people actually get to know how you think.
Everything else had to earn its way back in. Almost nothing did.
What Got Cut, and Why
The blog comments. I'd been paying for a third-party comment service that had accumulated eleven comments in four years, two of which were mine replying to myself. Comments made sense in the 2010s web. Now the conversation happens wherever the link gets shared, and that's fine.
The analytics dashboard. I had Google Analytics wired up and I checked it maybe once a quarter, always feeling vaguely worse afterward. Now I have a plain server log and a single question: is the site up? That's it. My website isn't a funnel, so why was I measuring it like one?
The "now" page with a mood tracker. Yes, this existed. It was a little chart of my daily mood rendered in pastel colors. It lasted six weeks in 2022. The lesson: features that require emotional vulnerability on a schedule will always, eventually, lose to features that just sit there.
Custom search. Three days of work for a search bar that visitors used roughly never. On a site with forty pages, scrolling is search.
The Technical Decisions That Actually Mattered
After a decade of trying every framework, the winning stack is aggressively boring: static files, a build step I understand completely, and hosting that costs less than a coffee per month. Total page weight dropped by about 80%. Load time went from "noticeable" to "instant."
The single best decision was writing the content before writing any code. Every previous redesign started with technology and tried to squeeze writing into it. This time I drafted every page in a notes app first, and the design basically drew itself around the words. Content-first sounds like a cliché until you actually do it, at which point it feels like a cheat code.
The second decision: no CMS. Editing markdown files and pushing to deploy is a friction point, sure — but that friction is a feature. It means every post is a small, deliberate act instead of a reflex.
What I'd Tell Anyone Rebuilding Their Own Site
If you're staring at your own accumulated cruft, here's the short version:
- Cut anything that needs ongoing data to be interesting. Mood trackers, streaks, live widgets. Static sites should tell stories, not require maintenance.
- Your about page matters more than your homepage. People land on project pages from search and social; the about page is where they decide to stay.
- Ship the boring version first. You can always add the fun feature later. You rarely go back and remove one.
- Delete the old code with ceremony. Seriously — save a copy, pour one out, and enjoy the lightness.
The rebuilt site has four pages, no JavaScript framework, and one image per page. It is, objectively, the least impressive thing I've ever made. It's also the first version of my website that feels like me — and it took deleting five years of ideas to find out which ones actually mattered.
