← Back to blog
April 8, 2026 · Scott Hardy · 11 min read Build log

18 months in the workshop.

A build-in-public retrospective. What worked, what got cut, the three rewrites, and the day I almost gave up.

Vibes started as an iMessage extension over a long Thanksgiving weekend in November 2024. It went on TestFlight in mid-April 2026. The interval — about 18 months — is what people mean when they say software takes longer than you think. I want to walk through what happened in those 18 months, partly for my own benefit and partly because most build-in-public posts I read either over-glamorize the journey or skip the parts where things went wrong.

So: the receipts, then the timeline, then a few honest notes.

The receipts.

Numbers I tracked because I'm bad at remembering how things actually went otherwise:

18
Months end-to-end
3
Full rebuilds
47
Features cut
$0
Outside funding

Eighteen months of nights and weekends, plus three months full-time at the end. Three full visual rebuilds — the iOS-26-Liquid-Glass pass, the cinematic-UI rebuild, then the Wrapped-vocabulary rebuild that actually stuck. Forty-seven features I built and then cut, which I know because I kept a graveyard list (more on that below). And $0 of outside funding because I never raised. That last number is going to matter for the rest of this post.

The timeline, abbreviated.

The early code is for learning what the product wants to be. By the time you know, the early code is wrong.

Three things I learned.

The right answer was almost always smaller. Every time I shipped a feature and it felt off, the fix was to remove something rather than to add something. The feed almost-shipped. The discover tab almost-shipped. The follower count almost-shipped. None of them survived a beta tester's first hour. Restraint isn't a virtue I had — it's a habit I learned by failing.

Visual identity matters more than I thought. The first version of Vibes was visually competent. It looked like every other carefully-designed indie iOS app. That's not nothing — but it didn't make people remember the product. The Wrapped vocabulary rebuild in March changed that. The app suddenly looked like itself. Beta users started screenshotting things. Conversion on the landing page tripled. Identity is a multiplier on every other piece of the product.

The thing you build last is the thing you wish you'd built first. The contacts-hashing flow, the iMessage extension, the weekly recap engine — every piece I'm proudest of came late in the project. The pieces I built first either got rewritten or cut. I think this is just how software goes; the early code is for learning what the product wants to be. By the time you know, the early code is wrong.

The graveyard.

Forty-seven features I built and cut. Some of them existed for a single weekend; some shipped to TestFlight before I yanked them. None made it to launch. The greatest hits:

The pattern, if you squint at it: anything that could become a habit-forming engagement loop got cut. Anything that turned the friendship into a number got cut. Anything that asked the user to perform got cut. What's left is small, slow, and silent — which is exactly the product I wanted.

What I'd do differently.

Mostly, ship faster. The 18-month timeline includes at least 4 months of features that didn't survive into the final product. Some of that was unavoidable — you don't know what to cut until you've built it. Some of it was me being too perfectionist about surfaces that nobody would have used anyway. "Build the smallest version, then learn what's wrong" is advice I'd give earlier-me, and earlier-me would have politely ignored it. Hopefully someone reading this will take it instead.

Also: get on TestFlight earlier. Six months earlier. The feedback I got from the first fifty TestFlight users in April was more valuable than the prior six months of solo design iterations. The product changed more in three weeks of beta than in the three months before it. I should have shipped a worse version, sooner, to a smaller group.

And: I should have written more of these posts during the build, not after. I have a folder of half-finished build notes that I never published because they didn't feel ready. They were ready. Nobody reads them looking for thesis-grade arguments — they read them looking for the shape of someone else's process. The shape is the value.

The money question.

The other question I get asked is how this is funded. The honest answer: my savings, my consulting income on the side, and a small pile of credit-card debt I'd rather not talk about. I've taken zero outside investment. I made the call early — I knew that the moment Vibes had investors, it would be expected to grow on a curve that would force the algorithm + feed + advertising stack I'm refusing to build. The two are incompatible.

The post-launch plan is a small subscription tier — lossless audio, the annual recap, group vibes — which I think will fund the project at a small-team scale. If it doesn't, it doesn't, and I'll keep it solo. Vibes is allowed to be small. That's not a back-up plan. That's the plan.

What's next.

The roadmap is public and current. The short version: Apple Watch and CarPlay polish, real legal review, public launch, then the optional subscription tier with lossless audio + the annual recap. Group vibes in Q4. Possibly Android in 2027. Definitely not a feed, ever.

If you want to follow along, the letters page is the lower-frequency, more personal channel. The changelog is the high-frequency, ship-receipt channel. Email signup on the homepage if you want me to ping you when the App Store launch happens.

Thanks for reading. If you've been quietly watching this project come together — and I know some of you have — thanks for being patient with the gaps.

Get the app
Eighteen months. Forty-seven cuts. One inbox.
Vibes is on TestFlight now. Free. No ads. The smallest possible music-sharing app, built by hand, on purpose.
Download the app Read the manifesto

— Scott · Brooklyn, April 2026