
For months this site only existed inside my house. I could write anything, break anything, and the only witness was the cat. Today it is on the open internet with my fingerprints all over it, and if you are reading this, you are the thing I spent months quietly dreading: a stranger, looking at my work. This build log is not about the technology of going public; I wrote that one separately. This one is about the harder system to operate: a brain that rehearses disasters, keeps score of every failure since childhood, and would very much rather you never saw anything it made.
The graveyard of finished things
Every neurodivergent maker I know has one: the graveyard. Projects that were genuinely good, taken to ninety-five percent, and then quietly never shipped. Not abandoned, exactly. Just never exposed. The app that stayed on localhost. The article that stayed in drafts. The business idea researched to death and never registered.
For years I told myself this was perfectionism, which at least sounds like a virtue at interviews. It is not perfectionism. It is threat avoidance. If rejection lands on you the way it lands on some of us, disproportionate, physical, hard to shake for days, then keeping your work private is not irrational. It is your threat model doing its job. The graveyard is full of things that could not hurt me, and that was the point of the graveyard.
The cost only became visible to me embarrassingly late: unshipped work cannot help anyone, cannot meet anyone, cannot become anything. It is perfectly safe and perfectly inert. A career, and for that matter a community like the one this site wants to be, is built entirely out of the things that left the house.
Fear wearing engineering's clothes
In the weeks before launch I did a security review, then another one, then a hardening pass, then I decided the backups were not rigorous enough, then I rewrote how the site handles being overloaded. All of that was real, defensible engineering. Some of it was also hiding.
The tell, I eventually worked out, is whether the task has an end. Real engineering finishes: the test passes, the box gets ticked, the risk is closed. Fear dressed as engineering never finishes; it just generates the next prerequisite, because its actual job is to keep tomorrow's launch safely in tomorrow. "I'll ship when it's ready" quietly becomes a machine for making sure "ready" recedes at exactly walking pace.
What broke the loop for me was writing the launch checklist down and declaring it closed: when these specific boxes are ticked, we go, and nothing gets added without a named reason. My working memory is unreliable and my anxiety is inventive, which is a dangerous combination precisely because the second one exploits the first. A closed list on paper defeats both. The night the last box went green, going live stopped being a decision at all, and that was the trick: I never had to summon the courage to jump, only the far smaller courage to stop adding boxes.
Make the disaster boring
Here is what actually reduced the fear, and it was not confidence, positive self-talk, or exposure therapy. It was making every disaster I could imagine boring.
The rehearsing-disasters brain is not wrong that things can go wrong; it is wrong about what that will feel like. Its scenarios all end at the moment of catastrophe, freeze-frame, no next scene. So I gave every scenario a next scene, in advance. Site gets attacked? There is a switch that takes it offline in seconds, and the attacker is suddenly shouting at a closed door. Data gets corrupted? Last night's backup already proved it restores. Something breaks at 2am? There is a runbook written for a version of me with no working memory left. Someone finds an embarrassing bug? Then a stranger cared enough to look, and bugs, unlike reputations, patch cleanly.
Catastrophising, it turns out, is just planning with the hope removed. Give it somewhere rigorous to put its scenarios and it becomes one of the best site-reliability engineers I have ever worked with. I did not defeat that part of my brain to ship this site. I hired it.
The scale of the fear versus the scale of the day
And then the day itself. I pressed the final button with my heart going like I had done something brave, and what happened was: nothing. A page loaded. The same page as yesterday, on a different address. No applause, no ambush. A handful of visitors trickled in. The catastrophe did not come, and neither did the triumph, and by evening I was making dinner.
I want to be honest about that flatness, because I think it is the most useful thing in this article. The fear had promised me an event. Shipping is almost never an event. It is a Tuesday with one extra DNS record in it, followed by the slow, ordinary work of making the thing better in public. Every launch I have feared has been like this, and I have feared every single one anyway, and I expect to fear the next one too. The fear does not update. You just stop taking its forecasts as fact.
So: the site is live, and you are here, which means the graveyard has one fewer resident. If you have something at ninety-five percent, something safe and inert and finished-but-unexposed, I am not going to tell you to be brave, because bravery on demand was never the mechanism. Close the list. Rehearse the disasters until they bore you. Then let the launch be the anticlimax it was always going to be. And if you want to tell someone about the thing you finally shipped, or the thing you can't yet, the community is open. I would genuinely like to hear it.
Tried it? Improved it?
Tell the forum what worked and what didn’t: real experience beats recommendations, and the best answers get folded back into this guide with credit.
Related guides

What you actually buy when you buy a domain name
This week the site got its name. A plain-language tour of domains and DNS: the internet's phone book, why you rent a name rather than own it, what the dots mean, and why the name is worth more than the machine.
6 min read

A backup you have never restored is a wish, not a backup
The night the site went public I built its backup system, and the step that matters is the one everyone skips: every night it restores its own backup into a scratch database and proves the data comes back.
5 min read