AppScreenshotKit

AppScreenshotKit was another one from the sprint with the same co-founder. App Store screenshots are a real, boring pain point — most of them look bad, and making good ones is fiddly. So we built a tool to make pixel-perfect ones fast.

The Thesis

Two bets. First, that we could build and ship something genuinely useful in a day. Second — the one I cared about most — that organic distribution alone could get a brand-new tool in front of the right people, with zero ad spend, if you knew where to show up.

What I Built (and How Fast)

The product went live in about 24 hours. Within the first week it had real users — and, more importantly, actual purchases — almost entirely from Reddit posts I wrote and from AI tool directories that picked it up. I’d optimized the listing and positioning so it got found. A meaningful share of all our traffic came straight from AI-discovery and directory sources.

That was the bet paying off: directory-and-community distribution is a real, scalable early channel. I now treat “one-day build + ninety-day organic distribution” as a repeatable way to test a concept.

What Happened

Then we started using our own product day to day, and it needed more polish than a 24-hour build gave it — the speed that got us to market fast also meant there was ongoing work left to do. That’s the trade-off of moving fast: you win the timeline and inherit the cleanup.

Underneath that was a difference in what each of us wanted to spend the next stretch of time on. Building software has gotten faster and more accessible than ever — increasingly, people with little or no coding background can ship a working product with the right tools. That shift changes where the real leverage sits: less in who can build something, more in who can find distribution and keep sharpening the product once it’s out. I wanted to keep pushing on both; my co-founder was drawn to starting something new. Neither pull is wrong — they’re just different instincts about where to spend limited time, and this venture asked for both of us to want the same next chapter at the same time, which we didn’t.

What I Learned

Building fast is a commodity skill now — the scarcer discipline is agreeing, up front, on who owns quality and distribution once real users show up. A weekend proved distribution wasn’t the bottleneck for this product; the trade-off that actually mattered was never settled clearly enough at the start.

• Speed-to-launch and product polish are two different budgets — decide together how much of each you’re spending, before you spend it.
• Two founders can want different next chapters and both be right — that’s not a partnership failing, it’s a signal to notice early.
• In a world where building is easy, the moat moves to distribution and follow-through — plan your division of labor around that, not around who’s “the technical one.”