How you start a project quietly decides how it ends. So instead of asking what everyone else does, let me put my own method on the table first — take whatever's useful. Here's my kickoff, before I let myself build anything: 1. Brief before build. I open a brief.md and treat it as the one file the whole project has to answer to. Nothing gets built until it's clear on three things: the outcome, who it's for, and what "done" actually looks like. 2. Same skeleton every time. The project drops into the same numbered folder structure I reuse on everything, so I never design the container twice — I just fill it. The shape is familiar before the work even starts. 3. Lock scope before touching tools. I force the scope down to one sentence, and I write the non-goals explicitly — what this is not. That single step is what keeps it from quietly sprawling later. 4. Decide the upkeep on day one. I set how the project stays current from the start, because the mess is never made on day one — it's made on day thirty, when the context has drifted and nobody decided who keeps it honest. 5. The mistake I stopped making. I used to start building before the brief was finished, telling myself I'd write it up after. The build quietly locked in decisions the brief never got to question — and by the time I noticed, they were expensive to undo. That's my version. It works for me — but I know it has blind spots I can't see from the inside. So flip it on me: what would you do differently? Where is this weak, and what am I leaving on the table? 👇

When Bas first added me to this group, I could barely have told you what an API was. I've been mostly quiet since, because I was heads down building something, and I finally get to show you. But the win I want to share isn't the one I thought I'd be writing about. A few weeks in, I was at my kitchen table testing a feature, and my own app wrote something back to me. A little message, the kind it sends to a stylist. I read it and I cried. Me. The person who built the thing. It had just made me feel seen, as a hairstylist, and I wasn't ready for that. I'm a solo hairstylist. That's my actual job. The app is called Rooty, a companion for stylists who are tired of being told the only way to stay booked is to become a full time content creator. I built it between clients over about seven weeks. Here's the part I think this group will appreciate, and it genuinely surprised me: the code was not the hard part. The boring receipts: - 212 commits, about seven weeks, built between appointments - One Python file, roughly 8,000 lines, zero dependencies, just the standard library - 132 tests - Multi-tenant, real logins, running live right now with actual stylists signing up - Claude Code did the heavy lifting on the code, Anthropic's Haiku model runs the AI features - I directed all of it. Every product decision, every word of the voice, every call about what it should and shouldn't do. I'm not a programmer. I'm the person who knew what it needed to feel like. That last line is the whole thing, so let me stay on it. The code, honestly, the AI and I got through together. What I could not outsource, what no prompt handed me, was knowing when a message sounded like a brand instead of a friend. When it was technically fine and emotionally wrong. I felt those the way I feel a bad section in a haircut, right away, in my gut. And I sent them back. So the "it feels like it gets me" that people react to, that came from real decisions: - The captions and replies learn from my actual writing, not a formula. They sound like a person because they're trained on one. - Every AI feature is its own little room with exactly one job. None of them is a general chatbot. A tool that tries to do everything feels like nothing. A tool that does one thing warmly feels like a friend. - And me. I was the reject button. I read hundreds of generated lines and killed every one that rang false.