The Prototype vs. the Product: How to Know When Your AI-Built App Is Actually Done

A few weeks ago, a founder I know built a scheduling app for therapists. The whole thing took her four days with an AI app builder. It does what she needs: therapists can see their calendar, clients can book appointments, confirmations go out via email. It works.

She’s been staring at it for two weeks and hasn’t launched.

When I asked why, she said: “It works, but… it doesn’t feel done.”

I asked her what she’d change. She said: “I don’t know. That’s the problem.”

This is the hardest moment in building with an AI app builder. The thing is functional, but there’s a gap between “functional” and “I’d feel comfortable asking real people to use this.” Understanding that gap—and knowing which side of it you’re actually on—is the difference between shipping and staying stuck in the voice-in-your-head phase forever.

What “done” actually means

Here’s the distinction that matters: a prototype is something you use to test an idea. A product is something you use to solve a problem.

The therapist scheduling app is a prototype. It proves the concept works. A therapist could use it. But there are seventeen little things that make it feel rough:

• The email confirmations are bare. No logo, no custom branding, generic copy.
• Cancellations don’t send notifications. Clients just don’t show up.
• There’s no waiting list if a therapist is fully booked.
• The signup flow doesn’t collect the therapist’s specialties, so there’s no way to filter by practice type.
• There’s no reminder email sent 24 hours before the appointment.

None of these things break the app. All of them make a real therapist think: “This feels like something I put together in a weekend, not something someone is charging me for.”

That feeling is real, and it matters. A prototype solves the problem in theory. A product solves it in practice, for the actual human using it.

Three questions that separate prototype from product

Here’s the hard part: you can’t know everything that’s missing. Your AI builder can’t know it either. So you need three quick questions to figure out which side of the line you’re on.

1. Would you use this to solve your own problem?

This one is honest, because you have to actually live with your own product.

If you’re the founder of that therapist scheduling app, would you use it to schedule your own therapy appointments? Not “could you”—would you actually use it instead of an email chain or a shared Google Doc?

If the answer is no, you’re not done. You know exactly what’s wrong—you feel it every time you open the app. If the answer is yes, you’re closer.

The founder I mentioned went through her own therapist signup. She got stuck at the form (it asked for too much information before letting her book). She saw the confirmation email and thought it looked amateurish. She started thinking about how her therapist would receive the email and whether it would end up in spam.

She wasn’t using her own product the way a paying customer would. When she did, she found ten things to fix.

2. Have you shown it to three people who are not you?

Talking to potential users is harder than building, and most founders skip it because they want to surprise people at launch. That’s a mistake.

You don’t need a focus group. You need three people who are similar to who you think your customer is. For the therapist app, that’s three actual therapists.

Here’s what you’re looking for: where do they get confused? Where do they hesitate? What do they ask about? Not “what do they think of it?” (people are too nice). Ask them to actually do the thing—book an appointment, send a confirmation email, cancel something.

When the founder showed her therapist app to three therapists, two of them asked: “Can I set rules for when I’m available? Like, I only see new clients on Thursdays, and I don’t double-book before 2pm.” The app had a calendar, but not rules. She’d built the prototype for how she thought scheduling worked, not how therapists actually work.

That’s product information. You couldn’t guess that from a spec.

3. What would break if you gave this to ten real users?

This is the hardest question because it requires you to really think about your edge cases.

For the therapist app:

• What happens if a client tries to book two appointments at the same time? (The app doesn’t check.)
• What happens if a therapist cancels an appointment? Do clients get notified automatically? (No.)
• What if a client’s email address is wrong? Is there a way to fix it without starting over? (No.)
• What if a therapist has a sick day and needs to close her calendar for a week? (She’d have to manually delete every appointment.)

These aren’t bugs. The app doesn’t crash. But they’re paper cuts. With ten real users and real edge cases, you’ll hit all of them in the first week.

A product handles the edge cases. Not all of them—some things can wait. But the ones that happen in the first two weeks with real users, those need to work.

How to decide: the three-layer test

Use this to figure out where you are:

Layer 1: Core flow — Does the happy path work? Can a user do the main thing your app is designed for?

For the therapist scheduler: yes. Someone can sign up, book an appointment, get a confirmation. It works.

Layer 2: Edge cases from real usage — You’ve shown it to three actual users. Did they hit anything you didn’t build for? Did they get confused anywhere?

For the therapist scheduler: yes. The three therapists wanted rules-based availability. One got confused because the email confirmation looked too generic. One tried to bulk-delete appointments and couldn’t.

Layer 3: Polish and professionalism — Does it feel like you care? Or does it feel like you cobbled it together?

For the therapist scheduler: it feels cobbled. The email confirmations are bare. There’s no custom branding. There’s no error message if something goes wrong, so if something breaks, the user has no idea what happened.

Here’s the heuristic:

• All three layers working? You’re a product. Ship it.
• Layers 1 and 2, not 3? You’re 80% done. Spend a day on polish.
• Layer 1 working, layers 2 and 3 aren’t? You’re a prototype. Don’t ship yet.
• Layer 1 isn’t solid? You’re not done. Keep building.

The therapist app was stuck at the boundary between Layer 1 and Layer 2. The core flow worked, but real therapists found it missing pieces. So the founder had a choice: spend another week with her AI builder adding the features therapists actually need, or launch with what she had and add them later.

(She added them. It took three days. Now it’s a product.)

The thing that makes this hard

The reason so many founders get stuck here is that building is fun and shipping is scary.

Building is a conversation with your AI tool. You have an idea, you describe it, the tool executes it. There’s a feedback loop that takes minutes. Shipping is different. You hit publish, and if something is wrong, real humans find out. There’s no do-over.

So we find reasons not to ship. “It’s not polished enough.” “I should add one more feature.” “What if the fonts are wrong?” And six weeks later, you’re still sitting on something that works but doesn’t feel done, and you’ve convinced yourself it’s because of the fonts.

It’s not the fonts.

It’s usually that you haven’t spent time with a real user, or you’ve built something that made sense in your head but doesn’t quite fit how real people work. That’s fixable. It just requires admitting that you don’t know what you don’t know, and then going to talk to someone who does.

The launch readiness checklist

Use this. It’s short and honest.

• I’ve used it myself to do the real task, and it worked (not in a demo-mode way, but actually).
• I’ve shown it to three people who would actually use it, and I’ve fixed the things they were confused about.
• Every error that can happen has a message that tells the user what to do about it (not “error”, but actual guidance).
• I’d be okay if this was the last version for six months (meaning: it’s complete enough to be useful even if I never touch it again).
• I’m more excited about what I’ll learn from real users than I am about adding more features in a vacuum.

If you can check all five boxes, you’re done. Launch.

If you can’t, don’t. But be specific about why. “It doesn’t feel done” is not a reason. “Real therapists need availability rules and I haven’t built that yet” is a reason. That’s actionable. That’s fixable. That’s the difference between being stuck and being on a path.

The founder of the therapist app shipped it yesterday. She has her first paying customer. The product isn’t perfect, but it’s real, and her customer is already telling her what to build next. That’s when you know you’re done: not when the app is perfect, but when you’re ready to learn what perfect actually means to the people using it.