What should users see while AI is building their app?
A few weeks ago, I launched the first public version of IdeaMade.
It turns an app idea into an editable Product Blueprint before building begins.
Since then, I have been working on the next step: generating an actual application from the confirmed Blueprint.
The generation flow now works, and it is significantly faster than my first version.
But it is still too slow for the product experience I want to provide.
That led me to a second question:
What should the user see while AI is building their app?
My first version had a familiar flow:
Describe the app → Confirm the plan → Start generation → Wait → See the result
The system was doing real work during that wait. It was creating pages, connecting the application, checking the result, and repairing problems.
But from the user's perspective, almost nothing was happening.
A loading screen does not explain whether the AI understood the product, which part it is working on, or whether the process is still moving forward.
Even after reducing the actual generation time, I realized that speed has two parts:
- How long does the complete application take to generate?
- How long before the user sees the first useful result?
Both matter.
The first still needs more work. For the second, I have been changing the generation experience around the pages already defined in the Blueprint.
Instead of treating the application as one large hidden task, IdeaMade can now show progress page by page:
Dashboard Complete
Customer list Complete
Customer details Generating
Settings Waiting
This is more useful than showing abstract model activity.
The user does not need to know how many AI calls or internal steps have completed. They need to know which parts of their product are taking shape.
I have also been working on a live Preview that becomes available while generation is still running.
As pages are created, the Preview updates and follows the page currently being generated. The user can start exploring the application before the complete generation process has finished.
The new experience is closer to:
Describe the app → Confirm the plan → Watch pages appear → Explore the live Preview → Receive the checked version
This does not make every generation step faster.
It brings the first meaningful result forward.
It also gives the user a chance to notice much earlier if the product is heading in the wrong direction. Waiting is easier when you can see useful progress, but early visibility is also a better feedback loop.
Another part of the experience is preserving completed work.
If several pages are ready and a later step fails, the user should not have to feel that the entire wait was wasted. I am working toward continuing from the interrupted part instead of starting the whole application again.
There is an important distinction here:
Live Preview
The application is still being generated.
Verified Preview
Generation has finished and the application has passed its checks.
I do not want to improve perceived speed by pretending unfinished output is a finished product.
The goal is to show useful progress earlier while continuing to reduce the real generation time and keeping a meaningful definition of “ready.”
This Builder experience is still in development and is not part of the public IdeaMade product yet.
The next thing I need to learn is whether the Blueprint remains useful after generation begins.
It should not be only an input that disappears once the coding agent starts. It should help the user track which pages and workflows have been implemented, what is still in progress, and whether the generated application is still following the product that was confirmed.
If you started with a Product Blueprint, would you expect it to keep tracking the build?
What would you want it to show: completed pages, implemented workflows, missing requirements, or differences between the Blueprint and the live Preview?
Transparency is important when users are waiting for an AI application to be built. Showing progress bars, clear build stages, and real-time updates helps keep users informed and engaged.
You can also provide interactive activities, useful tips, or email updates during longer processes. These simple strategies can reduce frustration, build trust, and encourage users to stay until the process is complete.
I think the biggest opportunity here isn’t just showing progress — it’s giving the user meaningful intervention points while generation is still happening.
I’ve been building larger products with Codex, and one thing I’ve learned is that an agent can make a technically reasonable decision that still isn’t what I intended from a product or UX perspective. If that decision becomes the foundation for several later screens, fixing it afterwards becomes much more expensive.
So instead of only:
Dashboard — Complete
Customers — Complete
Settings — Generating
I’d love to see optional checkpoints such as:
Dashboard ready — review before dependent workflows continue
The user could approve it, request a change, or simply let generation continue automatically.
I wouldn’t interrupt the user after every page, but I’d add checkpoints at important dependencies: navigation structure, data model, authentication flow, persistent state, etc.
That would make the Live Preview useful for more than perceived speed. It becomes a way to steer the build before incorrect assumptions spread through the rest of the product.
I also think each completed section could have a simple state like Generated / Verified / User Approved. Those are three very different levels of confidence.
Have you considered letting users intervene during generation, or is the goal to keep the whole build autonomous until the Verified Preview?
"Customer details Generating, Settings Waiting" is the honest answer, and it's better than a spinner because it names units your user recognizes. The interesting part is your line about a later step failing and not wanting the whole wait wasted.
That's a production patterns from day one job, not a progress-bar job. Every page you generate needs its own loading, empty, and error state, including the half-built one. Empty page that says "not generated yet, resume here" beats a preview that looks finished and isn't.
Free 10-min check on where the durable boundary sits: https://durablefoundations.gumroad.com/l/pyramid-reality-check
When step 4 of 6 dies right now, what does the user see on pages 5 and 6?
Kael Voss / DurableFoundations
Coming at this from the other side — I'm using an AI coding agent (Claude Code) to build and maintain a site across many sessions, not a single generation run, but the same core question applies: what should persist and actually get checked against reality?
What's worked for us: a single running notes file the agent reads at the start of every session and updates at the end — not just a task list, but the actual reasoning and current state. The moment that mattered most: I'd noted a feature as "done" a few days earlier, then ran an actual audit against the live site and found it wasn't. The notes said one thing, reality said another. That's basically your Blueprint-vs-Preview drift, just discovered after the fact instead of live.
If I were you: don't just track "does the build match the blueprint," track "does the current state still match what the notes/docs claim is true" — those two drift independently, and the second one is the one that actually burns trust.
Your four options aren't equal, three are status, one is a product. Completed pages, workflows, missing requirements are progress tracking, a nicer loading screen. The Blueprint-vs-Preview diff is the only one no other builder does: it makes the Blueprint a contract the build is held against.
That answers your real question. If the Blueprint vanishes once coding starts, it was a prompt. If it persists as what output is checked against, "confirmed 8 workflows, 6 match, 2 drifted," it keeps generation honest. Drift-detection is the moat: the fear with AI builders is "it built something, but not what I asked for." Prove fidelity, don't hope for it.
Build the diff first, status is the easy layer under it. When the Preview drifts, flag it or auto-correct to the confirmed spec?