You have an app you can open, demonstrate and put in someone’s hands. That is valuable. You can now have a conversation about something concrete: what people understand, what helps them and what they would change.
The next question is bigger than whether the code has bugs: what needs to be true for this to become a product people can use—and your team can keep improving?
Answering it brings product strategy, design and engineering together. Security belongs in that conversation. So do a confusing first visit, a missing integration, an unreliable booking flow and a release nobody knows how to roll back.
The goal is to preserve the progress and identify the work that matters for your next milestone. A prototype does not have to be perfect, and moving toward production does not automatically mean starting over.
Start with the next real use
“Production-ready” is incomplete without knowing who will use the product and what they will rely on it to do.
An internal trial with five colleagues and sample data asks different questions from a paid service that stores customers’ personal information. Neither needs every feature you can imagine. Both need a clear boundary around what is being offered and who is responsible when it does not work.
Before reviewing the implementation, write down:
- Who is it for? Name the first users and the job they need to finish.
- What is the next milestone? A supervised pilot, the first paying customers, or a wider release?
- What must work? Choose the few journeys that make that milestone useful.
- What happens when it goes wrong? Identify the consequences for those people and for the business.
These answers give the assessment a purpose. They help you distinguish necessary work from improvements that can wait.
Follow one journey all the way through
Imagine a prototype for booking a place in a workshop. This is an illustrative example, not a client project.
The demo looks convincing: choose a workshop, reserve a place, see a confirmation. Now follow that same journey from the customer’s perspective, the organizer’s perspective and the team’s perspective.
The customer needs to know what they have booked. Can they understand the date, location and cancellation terms? Can they complete the form with a keyboard? Does a failed payment leave them with a clear next action? Those are product and design decisions as well as implementation work.
The organizer needs a trustworthy booking. What happens when two people request the last place? If someone taps twice or retries after losing their connection, do they create two reservations? Does the organizer’s attendance list reflect the same state as the customer’s screen?
The team needs to operate and change it. If the confirmation email fails, does anyone know? Can the team trace what happened without exposing customer details? Can they change the reservation rules and check that existing bookings still behave correctly?
One familiar task has revealed questions about usability, business rules, integrations, reliability, data handling and ownership. Looking at the interface alone would miss some of them. Looking only for security vulnerabilities would miss others.
Assess the whole product, with depth where it matters
A useful assessment connects six areas. The balance depends on the product and its next use.
1. Purpose and scope
Does the current product help the intended person complete a worthwhile job? What is essential for the next release, and what could distract the team from it?
The useful output is a decision about the next milestone—not a longer feature list.
2. Experience and accessibility
Walk through onboarding, the main task, mistakes, interruptions and returning later. Look at language, interaction, feedback and accessibility alongside visual design.
A screen can look finished while leaving someone unsure whether their work was saved. The finding should explain that experience and the change needed, rather than simply calling for “better UX.”
3. Code and behavior
Review how the application’s rules are implemented, how its parts fit together and how changes are checked. Look for behavior that is hard to reason about, unnecessary duplication and gaps in tests around important journeys.
The question is which parts can support the next step, which need strengthening and which might be simpler to replace. AI-assisted development can continue throughout this work; the important thing is that the team understands and verifies the result.
4. Data, integrations and responsibilities
Trace where information comes from, who can use it and which systems need to agree. Consider access boundaries, data quality, failed exchanges, privacy and any requirements specific to the product.
In the workshop example, the booking, payment and attendance list need a coherent relationship. Connecting three APIs is only part of that work. Someone must decide what happens when they disagree.
5. Release and operation
Understand how the product is deployed, how problems become visible and how the team can recover. Test performance against expected use rather than an arbitrary promise to support millions of users.
A launch plan should explain what will be checked, who can stop a release and what the team will do if the result differs from expectations.
6. Ownership and continued improvement
Who controls the code, accounts and deployment? Can someone other than the original builder understand the important decisions? Who handles support and chooses the next change?
These questions matter before the first handoff. A product that only one person can operate is harder to build on, even when its current features work.
Turn findings into decisions and evidence
A report should help you act. We organize the next conversation around three questions:
Keep: What already works and is worth building on?
Strengthen: What changes matter most for the next milestone, and why?
Verify: What do we know from the evidence, and what still needs to be tested?
For the workshop prototype, a useful finding might be: The customer can reserve a place, but we have not established what happens when two people request the last one.
That finding leads to a specific engineering task and a check: implement the agreed capacity rule, then exercise concurrent booking attempts and confirm the outcome in both the customer and organizer views. It does not justify declaring the entire application ready.
Likewise, a repository review can identify useful findings without proving every live behavior. Watching people use the product, inspecting its running environment and testing failure or recovery may require separate work. The plan should make those boundaries clear.
Make the next step small enough to choose
You do not need to decide on a complete rebuild before asking for help. Start with the app, the people it serves and the milestone you want to reach.
At Twenty Ideas, our Prototype to Product offering connects a scoped assessment with separately scoped design and engineering work. The assessment gives you a plan you can take to your own team or work through with us. Our sample scorecard illustrates the format with fictional grades and findings.
Bring the progress you have made. Let’s work out what it needs next. Share your app and email—and if the app is private or not online yet, your email is enough to start.