I finished the first working version of IdeaMade — free preview coming next week
A few days ago, I shared the workflow I’m exploring for AI app building:
Idea → Requirement clarification → Editable Blueprint → App
After several days of development, the first part of that workflow is now working.
I’ve completed:
The first version of the IdeaMade website
AI-generated clarification questions
An editable product Blueprint
Users describe what they want to build, answer 3–5 questions about users, workflows, business rules, and missing decisions, and then receive a Blueprint containing:
Product goal
Users and roles
Core workflows
Key assumptions
Main pages
The first public version will be available next week and will be free to try.
To be clear, this release focuses on requirement clarification and Blueprint generation. It does not generate the complete application yet.
The main thing I want to test is whether defining the product more clearly before development can reduce generic first versions and unnecessary iterations later.
I’ll share the public link next week. In the meantime, I’d be interested to know:
What information would you expect to see in a Blueprint before letting AI build your app?
Getting the first working version out is a huge milestone.
The interesting part usually starts after that though — when the product moves from "I built this" to "a stranger instantly understands why they need this."
Early users don't have the same context as the builder. They don't see the weeks of decisions and iterations behind the product, they only see the first few seconds of the experience.
The next challenge is often finding that one sentence that makes someone think: "Wait, this is exactly for me."
The free preview should be a great way to learn what part of the product makes people lean in and what needs more explanation.
Your blueprint list is solid on the "what" (goal, users, workflows, pages), but the thing that actually reduces generic first versions and wasted iterations, your stated goal, is mostly missing. Generic output isn't caused by underspecified features, it's caused by underspecified constraints and edge cases. So the highest-value additions are the things people forget to say, not the things they already know.
What I'd add:
The anti-goal. What this explicitly is NOT. "Not a social network," "no payments in v1." AI over-builds because nobody told it where to stop, and half of "unnecessary iterations" is ripping out what it helpfully added. Bounding scope prevents more rework than defining it.
The unhappy paths. Your workflows capture the happy path. Iterations come from cases nobody specified: empty form, failed payment, two users hitting the same record. A blueprint that forces "what happens when this goes wrong" catches exactly what becomes bug-fix iterations later.
The one non-negotiable. Every product has a single thing that must be right or it's worthless (booking app: no double-bookings; chat: never lose a message). Flag it as never-compromise and the AI builds around the real constraint instead of weighting every feature equally.
Priority. Not just "main pages" but which is core vs supporting. AI treats a flat list as equal priority and builds a shallow version of everything instead of a deep version of the one thing that matters.
The deeper point, and your actual wedge: the value of a blueprint step isn't documenting what the user knows, it's extracting what they haven't thought about yet. Anyone can restate "I want a booking app." The tool earns its place by asking the question that makes them realize they never decided what happens to a cancelled booking. Your clarification questions are the product, not the blueprint format. Optimize for questions that surface the un-thought decision.
To answer directly: scope boundaries, failure behavior, the one non-negotiable, and priority order, more than another restatement of features.
This is a thoughtful point. The current Blueprint focuses mainly on what the product should do, while your examples highlight decisions users may not realize they need to make.
I don’t want to make the Blueprint too heavy, but I’ll pay attention to whether scope limits, failure cases, and priorities repeatedly come up during testing.
The "don't want it too heavy" instinct is exactly right, and it's actually the core design tension of your whole product, so worth resolving cleanly rather than just watching for it. Because a heavy blueprint and a thorough blueprint aren't the same, and conflating them is what kills tools like this.
Heavy = making the user fill out more fields. That's the failure mode, nobody wants a 40-question form, and if IdeaMade feels like enterprise requirements software, people bounce. You're right to resist that.
But thorough doesn't have to mean heavy, because the un-thought decisions shouldn't come from asking the user more, they should come from the AI inferring what's missing and asking only the sharp ones. The user says "booking app," and the tool already knows booking apps have a cancellation question, a double-booking question, a no-show question. It doesn't ask all of them. It asks the one or two the user clearly hasn't considered, based on what they did say. The intelligence is in what you don't ask.
That's the reframe: the value isn't more questions, it's fewer, better ones. A dumb tool asks twenty generic questions. A smart tool asks the three that make the user go "oh, I hadn't thought about that." Same thoroughness, a fraction of the weight, and it feels smart instead of tedious. Your clarification-question engine is where that lives, which is why the questions are the product.
So the beta test isn't "do scope/failure/priority come up," it's "can I surface the one critical un-thought decision without adding a form field the user resents." Nail that and heavy stops being the tradeoff, because you're not adding weight, you're adding judgment about what to ask. That's the hard part and the defensible part.
The lightweight version that works: infer the likely gaps from their description, surface only the highest-stakes one or two as a single "did you consider..." prompt, let them dismiss it in one click. Thorough where it counts, invisible where it doesn't.
I like that you're treating clarity as a deliverable instead of something that's expected to emerge during development.
A lot of AI tools accelerate building, but the harder question is whether they've accelerated understanding first. Those are very different milestones.
Generating a Blueprint is easy.
Generating a stable one from the same requirement is much harder.
I added stricter structure and validation. The results are already much more consistent.