I'm Marco — solo-building CAPTD, an AI content-pack generator for photographers, around a full-time job, AI-assisted development, honest about all of it.
Quick follow-up to my last post: the full redesign just shipped.
What actually changed:
Complete visual overhaul — new design system, every page rebuilt from scratch
A real information-architecture rethink: instead of one flat nav, things are now grouped by what they actually are — the core Snapshot/Slideshow/Video workspaces live together under "Creator Suite," while Marketing, the AI Photography Assistant, and free tools sit as their own distinct items
A new Account section — sign-in, history, and settings all in one predictable place instead of scattered
Multi-language UI support, 10 locales in progress
The honest part — real bugs found shipping this:
Merging a redesign this size surfaced real problems I hadn't caught in testing: the AI was silently ignoring the selected output language in some cases, alt text was coming out way shorter than intended, and video uploads could die silently if someone navigated away mid-upload with no warning. All genuinely fixed now, and I'm glad they surfaced before more people hit them.
Stack unchanged: TanStack Start, Supabase, Google Gemini, Vercel.
What's next: real payments, a referral system, finishing the full-workspace translation, then an actual public launch.
Try it, break it, tell me what's wrong: captd.app
Top comments (2)
The naming nit is a fair catch and I'll use it — "what broke AND got fixed" is the honest header, and you're right that the fix count next to the break count is what makes it credible rather than alarming.
On payments going live: it's been more interesting than I'd like already. The short version is that hosted checkout hands you the email the customer typed, not the account in your app — so unless you started the checkout from inside your product and passed the user id through, you're matching purchases to accounts by email. I found every purchase row in my database had a null user id for exactly that reason, and the email comparison was case-sensitive on one side and never trimmed. It mostly worked, which is the dangerous kind of bug.
Worse was the failure mode. When the purchase didn't resolve, the code fell through to the free-tier path, so the customer saw "you've reached your generation limit" rather than anything about their purchase. A confident wrong answer pointed both of us at completely the wrong problem for a few hours.
So yes — build in public gets interesting at payments, mostly because the bugs stop being cosmetic and start being "someone paid you and the app is behaving as though they didn't". Going live properly in early October.
"Try it, break it, tell me what's wrong" is the right energy for a redesign post - most people hide the bugs they found mid-launch.
Shipping the language-ignore and alt-text truncation catches before public launch is exactly why build-in-public works: those bugs found you while the stakes were low.
One naming nit, use it or ignore it: the section where you list the bugs reads as "what broke" but everything in it already has "genuinely fixed now" attached - so the honest headline for that block is "what broke AND got fixed." Future readers skimming headers will trust the redesign more seeing the fix count next to the break count.
Good luck with payments going live - that's the milestone where build-in-public gets really interesting. (Comment drafted with an AI helper, posted by the founder.)