Naming It, Buying the Domain, and the First Commit: Two Days from Idea to Code
I had the debate pick the name too. A domain purchase at dawn, remote dev setup fumbling, and 22 commits on day one
The persona board from episode 1 picked a service where AI summarizes Korean corporate disclosures. Starting development meant a name and a domain, plus a dev environment for driving the Mac mini at home remotely. I gave myself two days for all of it, and while the name came out of a debate, the environment setup dragged on until dawn.
What I set out to do
The board (episode 1) picked a service where AI summarizes Korean corporate disclosures. To start development I needed a name and a domain, and I had to set up a dev environment. I wanted to finish all of it within two days.
Naming by debate too
I didn’t think about naming separately. I put it straight onto the agenda of the persona board from episode 1: decide the service name and domain by debate. Eight rounds ran, and each candidate got arguments like “awkward to say in Korean” or “short and easy to remember overseas too.”
One thing I did right here was including the domain-availability check inside the debate. However good a name is, it’s void if you can’t get the domain, so every time candidates were narrowed down I had it check whether they could actually be registered. The top candidate, gongsiai.com, was in fact already taken, so it was dropped on the spot. With three left, I did the same role-barging I used in episode 1. I named DartBrief as the CEO and gave four reasons, and the rest agreed on the grounds that “brief” evokes a briefing and makes the purpose obvious, so it was confirmed unanimously. If I had settled on a name outside the debate and looked for the domain afterward, I’d have wasted a full lap.
When I didn’t know, I just asked
The name was settled at dawn, and I wanted to buy the domain right away, so I kept going. The problem was that I’m a backend developer who has only ever built on company infrastructure, so I knew nothing about the ecosystem for deploying personal projects. So I just asked.
“Vercel, Railway, Supabase… are these all cloud services?”
An embarrassing question for someone with 9 years of experience, but there’s nothing to be embarrassed about in a chat window. I also asked where it’s best to buy a domain and where it’s cheapest to host a server, and paid for the domain right there.
I sorted out the project structure the same way. It would split into three chunks, backend, frontend, and AI server, so how should I open Claude Code sessions, and how do I close a session and resume it later? I threw in all of these basic operational questions. The conclusion was simple: one session per unit of work.
That said, I only made two repos that day. Backend and frontend sat side by side inside one repo as backend/ and frontend/, and only the sessions were separate. The one thing that got its own repo was the AI server, and not because the code differed but because it runs on different hardware. So the unit is not the repo, it is the session. Whatever one session has to hold in its head at once goes in one bundle.
Where it broke: remote dev setup at dawn
The dev machine is a Mac mini at home; I was sitting at a Windows desktop. I was setting up passwordless ssh access, and this is where a chain of fumbles blew up. Key registration worked, but the connection alias didn’t take; when I tried to add the alias, it said the PowerShell profile file didn’t exist; creating it didn’t help either; and in the terminal, mouse scrolling paged through input history instead of the screen. I didn’t want to go sit in front of the Mac mini, so I wrestled with it until 1:30 in the morning, and in the end I wrapped up with passwordless access working. Environment setup is a stumble even with AI. The only difference is that now there’s someone to paste the error messages to.
The first session
At 1:32 a.m., I opened the first session in the new repo. The first prompt was this.
“Hi. What should I do first?”
In other words, I even asked Claude what to ask it to do. I approved its answer to start with initial setup, and 22 commits piled up that day, the first at 1:49 a.m. and the last at 11:04 p.m., so it was not an overnight sprint but a whole day spent end to end: the project skeleton, social login, the disclosure dashboard, the collection scheduler and web push, and the AI summarization integration. In the evening I spun up a separate agent to review the code written that day, and a bug where login didn’t persist was fixed the same day too.
I don’t know whether this is normal speed. But two days earlier I didn’t even have an idea.
Lessons
- Have the naming debate check domain availability at the same time. If you look for the domain after settling on the name, you waste a lap.
- When you don’t know, just ask. Even knowing nothing about the deployment ecosystem, it went from question to purchase to setup in one flow. The embarrassment only survives in the log.
- One session per unit of work. Backend and frontend lived in one repo and still got separate sessions. The reason to split a repo was different hardware.
- Separate writing from reviewing. From day one I had code review done by a separate agent, not the session that wrote the code. Whether it helps remains to be seen.