This isn't a dramatic failure post. Nothing blew up.
These are the ordinary mistakes, the kind that quietly cost time or money and are easy to leave out of a build-in-public thread. Each one is traceable to something real: a commit, a spreadsheet, a screenshot. I'd rather publish these while they're still a bit uncomfortable than turn them into a neat story later.
1. I left the app store's cut out of my pricing
My first pricing model had a $7 pack for 25 generations and assumed a 64% margin.
It didn't include the commission Google and Apple take on in-app purchases. At the 15% small-business rate, the real margin was about 58%. At the standard 30% rate, it would be about 49%.
This wasn't a hard problem. It was a number I could have looked up in five minutes. That's what makes it a real mistake: it wasn't bad luck, it was skipping the obvious step.
What I do now: platform fees go into the model before anything else. Full breakdown here.
2. I priced a big pack that wasn't a better deal
The second pack was $55 for 200 generations. Per generation, that's $0.275, compared with $0.28 for the $7 pack. That's about a 2% discount for spending eight times as much.
Nobody sensible buys that, and anyone who does might feel cheated later.
What I do now: every bigger pack has to be clearly cheaper per unit. The rebuilt plan uses $0.30 → $0.28 → $0.25 and tops out under $20.
3. I rebuilt the landing page about four times before it had real traffic
The website's git history shows it: a full landing page on August 24, a revamp on August 30, another on September 1, and the hero rebuilt again on September 7. That's about four rebuilds in two weeks. The full history is here.
Each rebuild felt productive. But they were based on my opinion, not on what visitors actually did, because there weren't many visitors yet.
What I do now: before redesigning, I ask what I'd learn from it. If the answer is "I'd like it more," that can usually wait until real traffic tells me what's wrong.
4. Every recommendation showed the same match score
In the first version of the app, the style report showed four top picks, and all four said 98% Match. You can see that version described here.
A score only helps you choose if it's different between options. When everything is 98%, the number is decoration.
What I learned: a UI element can look right in a demo and still not do its job. I only noticed this by looking back at my own screens with some distance.
5. I built a lot of surface area before knowing what mattered
By late July, the first version had analysis, a style report, detailed style pages, try-on, a style studio, a 100+ style library, filters, a home screen, and a separate hair analysis.
None of that is bad work. But it's a lot to maintain before I know which parts people actually use. The core of the product is one line: photo → your face with a new haircut. Everything else should have to earn its place.
What I'm doing now: measuring which screens lead to a first generated look, before adding more.
6. My content calendar had posts for events that hadn't happened
My 30-day X plan was written in advance. When I reread it, some posts described things that hadn't happened yet:
- "Someone used Hairover today and sent us their result."
- A "Build Log #02" with placeholders:
[feature],[improvement],[fix].
Planning posts ahead is fine. Publishing them before they're true would undo the whole point of building in public.
The rule now: a post that describes an event only goes out if the event happened. The plan is here.
A risk I caught before it became a mistake
What counts as "one generation"? If one tap produces four variations and I charge for one, my real cost per tap is four times what the pricing assumes, and every margin number is off by 4×. I haven't gotten this wrong, but it's the kind of thing that quietly breaks an AI app's economics, so it's on this list as a warning.
What these have in common
Looking at the list, most of these aren't really about skill. They're about skipping the step where you check against reality:
- Pricing without checking the platform's real fees
- Redesigning without checking visitor behavior
- Showing scores without checking if they help anyone choose
- Planning posts without checking if the events happened
I'm an engineer, and engineers are good at building the thing in front of them. What I've had to learn is to stop more often and ask: what would tell me this is wrong?
What I'm testing next
Whether the fixes hold up in the real world: the rebuilt pricing, fewer but clearer screens on the path to a first look, and a posting habit that stays honest. I'll add new mistakes here as I make them. I'm sure there will be more.
Key takeaways
- Put platform fees into your pricing model first.
- A bigger pack has to be a clearly better deal per unit.
- Don't redesign based on opinion when you could wait for real behavior.
- A score that's the same on every option isn't helping anyone choose.
- Only publish build-in-public posts about things that actually happened.