We built a feature before deciding who it was for. Here are the numbers and the mess.
Bunzee turns an idea into a PRD, IA, wireframes, design, and a working prototype, then hands the whole thing to an AI coding tool over MCP. Two years in, three Product Hunt launches, 3,065 signups.
A few weeks ago someone on the team wanted to know whether you could point the pipeline at an app that already exists instead of at an idea. Not clone it. Read it. Take an App Store listing, look at the screenshots, and work out how the thing is actually put together.
It works better than I expected.
We ran it on our own app, because that is the only place we can grade the answer:
- 8 screenshots in
- 16 screens out, 5 paths, 61 components, named and nested
- Half the screens were never in the screenshots. It inferred them from the structure
- Nothing was invented. Every inferred screen was one that actually exists
- Our primary red is #EA6560. It read #E36B65
- Total cost: $1.94. IA pass $0.135, the rest was code gen
- It scored its own confidence at 7/10 on our app, and it was right to
The honest limit: a store listing is the app on a good day. Empty states, failed payments, logged-out flows never make the screenshots, so they never make the structure either. That is a limit of the input, and a human doing the same exercise misses the same things.
Now the part I actually want to ask about.
I have no idea who this is for, and our own data is arguing with me.
Of 3,065 signups: 1,561 planning, 1,013 business, 184 other, 158 design, 154 development. Designers are 5%. But "extract an app's structure into editable layers" is a designer's problem. The 84% who actually showed up don't open Figma. They write the plan and hand it to someone else.
So either I'm building for the 5%, or I need to reframe the output entirely for the 84%, which means the useful thing isn't the layers at all. It's the diff: here is what a shipped competitor decided, here is what your plan doesn't cover yet.
And the uncomfortable version: we have 3,065 signups and 13 people logged in yesterday. Retention is the actual problem. This feature brings new people in. New people will leave the same way the old ones did.
Which makes me think we built the right toy at the wrong time.
What I'd like to hear from people who have been here:
When you've built something that works but doesn't obviously belong to your existing users, do you ship it as a separate wedge, fold it into the core flow, or sit on it until retention is fixed?
Happy to share the raw output from either run if it's useful.
This is a painful but useful lesson. I think the interesting part isn't just “validate before building,” but knowing what evidence is strong enough to justify building in the first place.
Sometimes you can validate the problem and still get the feature wrong.
That second line is exactly where I am. Right problem, wrong feature. Still stings.
Yeah, that distinction is brutal. 😅 I think the interesting question then becomes whether the feature can be reframed around the actual retained value, rather than throwing away the work entirely. Curious what direction you’re leaning now.
the diff, i think. though not for the reason you'd expect.
layers are a one-time thing. you export them, you take them into figma, done, and i never see you again. a diff against your own plan is something you'd actually run twice, because the plan keeps moving and someone's always shipping something new.
but honestly, the fact that the version i like is also the version that fixes my worst number is making me squint at it. i already got the audience wrong once in that post. so this might just be me wanting something to be true.
leaning toward not shipping it separately. a new front door on a product people walk out of doesn't really help, it just makes the leak wider at the top.
which isn't a free call either. three people built a thing that works and it's sitting there. that costs something on a team this size, so it's less "parked" and more "not next."