Vibe code beyond the MVP

An upload flow example

Consider a feature that lets users attach a file to a project. The upload button is only part of the experience. You also need to account for what happens before, during, and after the upload.

• Before uploading: Show accepted file types and size limits near the upload control. If someone selects an unsupported file, explain the issue immediately.
• During uploading: Show that the upload is underway, with a progress bar when you can measure progress. Prevent repeated clicks from uploading the same file twice.
• If it fails: Explain what went wrong and offer a way to retry. Preserve any other information the user has entered so they don’t have to start over.
• Once it succeeds: Show the uploaded file’s name or preview and make it clear that it has been attached. Give the user a way to remove or replace it.

When prompting AI to build this feature, describe these behaviors alongside the upload itself. Otherwise, you’ll get a working upload with little guidance for the person using it.

As a human, it is your job to be empathetic to your fellow humans. Don’t expect the robots to “just know what you’re thinking”.

Let users change their minds

Users won’t always finish what they start. They might close a form halfway through, cancel an edit, or delete something by mistake.

Trust me: You’ll piss off a lot of users if they can’t recover something they accidentally deleted.

Decide how your app should handle those moments.

• Leaving an unfinished form: For a longer form, consider saving a draft so users can return without starting over. If their changes will be lost, warn them before leaving and offer a choice to keep editing or discard them.
• Deleting an item: If deletion can be reversed, offer an undo action. If it’s permanent, ask for confirmation and explain exactly what will be removed, including any related content.

When prompting AI, specify what should be saved, discarded, or recoverable. Then, test these paths yourself.

The little things

Fair warning: A surprising amount of time can go into details that seem obvious until you work through them. Even a simple message may need different wording and actions depending on what happened.

Take empty states, for example. Showing “nothing here yet” seems straightforward. But why is there nothing there? Consider a project list:

• The user hasn’t created a project yet: Explain what belongs here and provide a “Create project” button.
• A search or filter finds no matches: Explain that no projects match and offer a way to clear the search or reset filters. Don’t imply that their projects are gone.
• The user deleted their last project: Provide a way to create another. They don’t need the same introduction as a first-time user.

Loading and failed requests need their own treatment, too. Don’t flash “No projects yet” while data is still loading, or show it when the app couldn’t retrieve existing projects. Show a loading indicator or an error with a retry option instead.

When prompting AI, specify why the screen is empty and what the user should be able to do next. Asking for “an empty state” alone leaves those decisions open.

If you plan to charge for access, features, or content, decide what users are buying and how they’ll pay.

Subscriptions charge on a recurring basis for continued access.

One-time purchases charge once for an item, download, or defined access.

Credits give users a balance they spend on specific actions.

Choose a model that fits the value you provide and your ongoing costs. For example, unlimited access to an AI feature could become expensive if each use costs you money.

Define what payment unlocks

Before asking your AI to connect payments, define what’s free, what requires payment, and any usage limits attached to each plan or purchase.

Then specify when the paywall appears and what purchasing unlocks. For example, free users might be limited to three projects. When they try to create a fourth, show an upgrade message explaining the limit and offering a subscription.

After payment is confirmed, let them continue creating that project without re-entering their information.

Connect payments to access

A working checkout is only part of the setup. Your backend needs to receive verified payment notifications from the provider and associate each purchase with the correct user account.

Your database then records what that user has purchased: an active subscription, access to a particular item, or a credit balance. Payment notifications keep those records updated as purchases, renewals, cancellations, and refunds occur.

When someone requests a paid feature or protected content, the backend checks those records before allowing access. Hiding a button or showing a paywall isn’t enough. The restriction must still hold if someone opens the feature’s URL directly or tries to bypass the interface.

Ask your AI builder to implement this complete flow:

• Verify the payment
• Update the user’s database record
• Enforce access on the backend

Reaching a “payment successful” page alone shouldn’t unlock anything, and a purchase should still register if the user closes their browser after paying.

Describe how the app should handle changes afterward:

• Cancellation: Specify whether access continues until the end of the paid billing period.
• Failed renewal: Decide how users are notified, how they update their payment method, and when access ends.
• Refund: Define what happens to the purchased access or unused credits.
• Repeated payment notifications: Ensure the same purchase cannot grant access or add credits twice.

In the previous article of this series, we discuss the importance of building the supporting pages of your app. Such pages would include a place where users can manage billing and payments associated with their access / plan level.

Should go without saying, but you’ll need to test the purchase flow yourself. Better you detect any weird stuff with cancelations before a user starts complaining loudly about it.

Once people start using your app, you need a way to understand whether it is helping them accomplish anything.

Website analytics can show where visitors come from and which pages they view. Product analytics helps you understand what happens after they enter the app: which features they use, whether they complete important tasks, and where they drop off.

Start with a few questions you want the data to answer:

• Are visitors creating accounts?
• Are new users completing the app’s main task?
• Where do people abandon that task?
• Do they return to use the app again?
• Which actions lead to a purchase?

Then identify the events needed to answer those questions. An event is a recorded action, such as creating an account, saving a project, completing an export, or purchasing a subscription.

For a songwriting app, signing up tells you someone was interested. Saving their first song suggests they reached an initial moment of value. Returning to edit it gives you another signal about whether the app is useful to them.

Ask your AI builder to track those specific actions. “Add analytics” leaves too much open to interpretation. “Track when a user successfully saves their first song” gives it a defined behavior to implement.

Pay attention to when an event is recorded. Clicking “Save” and successfully saving are different outcomes. If a request fails but your analytics counts it as a success, your numbers can hide the very problem you need to fix.

Keep the initial setup focused. You can expand it as new questions arise. Check that events appear in your analytics tool, that a single action is not counted twice, and that you are not sending unnecessary personal information or private user content.

Many apps need to respond to activity beyond updating what appears on the screen. A new account might need a welcome email. A submitted request might need to notify an administrator. An export might take several minutes, then notify the user when their file is ready.

These are automations: something happens, the system checks the relevant conditions, and an action follows.

Describe each automation as a complete rule. For example:

“When an export finishes successfully, send its owner one email containing a link to the finished file.”

That tells your builder what triggers the automation, who receives it, when it should run, and what it should contain. “Add email notifications” leaves those decisions unresolved.

For each automation, define:

• The trigger: What action or change starts it?
• The conditions: When should it run, and when should it skip?
• The response: What should the system send, create, or update?
• The failure behavior: What happens if that response cannot be completed?

Some automations respond immediately to an event, such as a request being submitted. Others need a scheduled check, such as finding trials that expire tomorrow. Make that timing explicit.

You should also decide what belongs inside your app and what needs to connect to another service. A request might appear in an internal dashboard, send an email, or create a record in your CRM. Start with the follow-up needed to keep the process moving.

Finally, test what happens when things go wrong. If an email service is temporarily unavailable, can the system retry? If the same event is received twice, will it send two messages or create duplicate records? Can you see which actions failed?

A useful automation should complete its job reliably and give you enough visibility to investigate when it doesn’t.

The funny thing is, as I created this series, the more I wrote, the more I realized how much there was to cover.

Some other concepts you’ll need to factor in as your app matures are:

• Automated testing
• Quality assurance
• In-app support
• Security / encryption

We’ll save those topics for some other article. In fact, once you’ve launched the initial versions of your app and gain traction, you’ll probably decide it’s time to hire a team.

This is why I kind of chuckle at the notion of “AI can just build the app so engineers are no longer needed”.

Building the initial app is just the beginning; you still need to continue development to support the users you acquire.

Heck, I as an experienced engineer with these AI tools, often feel the need to assign tasks to other engineers to free up time to focus on marketing, sales and other business functions.

As you can see, there are a bunch of rabbit holes you’ll need to go down when building an app.

This is exactly why organizing your app planning into task lists with due dates and marked by priority is so important. Creating a roadmap with tasks bucketed in categories (ex. “bug fixes”, “dashboard edits”, etc.) will make the process far more manageable.

An ongoing process

Your roadmap will definitely change as people use your app. Some planned features will become less important. Problems you hadn’t anticipated will get added and move up in priority.

Capture those findings in your project management tool, then review your priorities regularly. Before each building session, choose a few tasks and give AI the requirements it needs.

AI can help you build faster. Your role is to act as the captain and steer the ship.