Loading...
Behind the scenes
The launch checklist is a web app I built with Sinter. This page is the honest walkthrough: what I did, what I skipped on purpose, and what Sinter actually contributed.
Constraints shape what the project becomes.
When AI makes coding cheap, planning is the easiest thing to skip. The risk is building the wrong thing fast.
The demo had to do two things at once: show what one person can build with Sinter, and stand on its own as something genuinely useful. I worked through a handful of options against those constraints. A launch checklist for solo founders going from prototype to public was the one that hit both. Same audience for the demo and the checklist, so the artifact teaches the visitor while it demonstrates the tool.
Sinter ships with a PRD template, useful even outside the Sinter workflow. I worked through it across multiple sessions with Claude: the five-phase structure of the checklist itself, the full task list with titles and one-sentence descriptions, the user flows, the success criteria, and what was deliberately out of scope. By the time I finished the PRD, the rest of the build was mostly mechanical.
The PRD also captured the shell, not just the content. A sidebar for phase navigation and progress, a main column for the current phase, a drawer for task details. Progressive disclosure as the controlling principle: the surface answers what you need now without exposing what you don't. Nailing the architecture early makes the pixel work easier, because pixels are cheap to redo and architecture isn't.
I dropped the PRD into docs/prd/ and /bootstrap analyzed it and broke it down into three artifacts: a roadmap file with architecture and dependencies, a GitHub Epic, and the linked feature issues that hang off it. The backlog was ready to go.
Not a Sinter feature but a discipline I lean on often. Before touching code, I asked Claude to read the issue list and group it by file-overlap risk: which issues could run in parallel without contention, which had to be sequential. Claude set up one git worktree per cluster, and I opened one Cursor window per worktree and kept the planning conversation pinned in the original tab as the reference. Then /start [issue] inside each one. Two or three streams of work in parallel without agents stepping on each other's files.
Each issue starts with /start [issue] in Claude. Sinter picks the lane automatically: a fast lane for simpler tickets, the spec-driven lane for anything bigger, security-sensitive, or otherwise risky. From there, the workflow runs itself. Agents, skills, and safety hooks do most of the work, and I step in at the checkpoints that matter: review the plan, commit when it's good, open and merge the PR.
Before each merge, I quickly checked the app in Cursor's built-in browser to catch anything obviously off. If something was clearly wrong, I'd iterate. Otherwise, I deferred the bigger reworks to the next step. The discipline was to deliver the PRD first and test everything to make sure it worked as expected. Any ideas for visual design, polish, and other features got noted down for later.
With the issues merged and the app working end-to-end, the next sweep set the visual system. I had Claude generate five directions for color and typography with a switcher at the top of the page so I could step through them. Two felt right, and I generated five more variations closer to those. From there I picked the final palette and typography. The design tokens got updated to match, and I added gold later as a clear celebratory color for milestones.
I filled in the design brief at .claude/design-brief.md along the way: principles, references, anti-references. For example, PostHog inspired the saturated colors, the playful shape language, and the chunky button weight. Headspace shaped the celebratory treatment of milestone cards. I used Open Doodles by Pablo Stanley for the illustrations, recolored to fit the project's palette.
The result is a restrained palette: forest green for primary, brick red for state, gold reserved for milestones. Paper-cream surfaces underneath, with hand-drawn scribble SVGs in negative space behind each phase to break the grid. The design system was complete.
I went back and forth on the details to nail the overall feel of the app, matching the design concept. Sinter ships with motion guidelines in the design system, which informed the micro-interactions and animations. For visual excitement, I added a stacked-tile shadow to the built-in button, an off-grid headline bleed, rotated check marks, and colorful animated success cards. The effort indicator on each task moved into a hover tooltip, making the drawer less cluttered. I added a "copy prompt" button on each task card, expecting visitors would take the prompt to their AI tool of choice to help them plan and manage the task. Celebration cards and a confetti burst land at each milestone, calibrated to feel like a real moment without tipping into game-app energy.
The last polish move was a copy sweep against the project's voice-and-tone guidelines, making sure every visible text string sat in the same register.
/audit:words for UX writing, /audit:visual for visual design, and /audit:a11y for accessibility. I pointed them at the /demo route, and they flagged where copy was inconsistent, where visuals got too heavy, and where accessibility fell short, each finding citing the guideline or WCAG rule behind it. It's not a CI gate. I ran them manually when I wanted a second opinion.The launch checklist is for founders building a product to sell. This is a marketing artifact, so I broke a few rules on purpose.
The checklist is still valuable for people building real products. I broke rules because my goal was different, not because the rules are wrong.
The more repetitions you do, the more you learn. Here are some of my takeaways from this project.
/bootstrap and the first /start. I did it after I built the core functionality with Sinter's default design brief and visual system, then reworked everything into the Workshop aesthetic. A brief in place earlier would have meant first shots closer to the intended look. Minor smoothness gain, not a major miss./start command, ending with a PR happens automatically. The polish and refinement that followed piled up on a feature branch instead, which meant Sinter's CI gates (typecheck, lint, build, security scans, accessibility, Playwright) didn't run on that work as I went. Opening a draft PR as soon as the next ad-hoc cluster started would have caught small things earlier instead of letting them pile up./commit makes it quick and easy, like pressing the "save" button in apps where auto-save isn't built in.