What should you do in the first month after your AI-built app goes live?

Launch traffic usually fades within days. That is normal, and it is not the part that decides whether the app grows. The month after is: it is when you find out who stayed, why the others left, and where to find more of the first kind.

This chapter is the loop to run, in order. Each step is short and links to a page that goes deeper. If you want the same month laid out week by week, what to do after launch does that.

Step 1: Read the numbers by source, not in total

Open your analytics a few days after launch and make one small table: for each tagged link from chapter 8, how many visits, how many signups and how many payments it led to.

Rank the rows by signups and payments, not visits, and look at the table again after a few weeks: some people sign up on the day and pay later. With a handful of signups per place you are looking for the place that stood out, not a precise rate.

If you set up measurement in chapter 7, this table is already there. If you didn’t, add it now: the next post is the first one you can learn from. Which channel brings paying customers explains how to link a payment back to the visit that started it.

With Nordva Launch: once you connect Stripe (every plan can), Insights shows paying customers by referring site next to the visits and signups from the same source.

Step 2: Talk to the people who used it

Numbers tell you where people came from and where they stopped; only people can tell you why. Ask the users who returned for a short call or a written reply, and ask about what they did rather than what they think. What to ask users for feedback has the questions. Keep their exact words for the post in step 5.

Conversations are the richest source, but most people won’t volunteer one. A small feedback button inside the app catches the moment someone gets stuck, while they still remember why. How to collect feedback inside your app covers where to put it and what to send with each message.

With Nordva Launch: the free plan takes 50 in-app feedback messages a month per project, sorted by keywords into bugs, feature requests, praise, billing and support questions. Indie ($19 a month) takes up to 1,000, and sorts up to 500 of them with AI.

Step 3: Write to the people who never came back

Some people will sign up and never use the app, or use it once and disappear. They are easy to ignore, and they know something you don’t: why they stopped.

Send each of them a short personal email, from you, not a template: you saw they signed up, you are the person who built it, and what were they hoping it would do? Keep it to three or four lines, with no link to click and nothing to sell. A few will come back; more will tell you why they left, and that answer is usually the same step of your app, over and over.

Then fix that one step before you send more people to it. People sign up but never use it lists the usual culprits (an empty first screen, a setup step that needs something they don’t have yet) and how to find which one is yours.

With an AI builder or a coding agent, this is where fast building pays off: describe the step and what people said about it, and ask for the smallest change that removes it. Change one thing at a time, or you won’t know which change helped.

Step 4: Ship what they asked for, and tell them

When you fix something a user asked for, tell that person first, personally. It shows them the message they sent was read.

Then write it down in a public changelog: a dated list of what changed, one short entry per change, in words a user understands (“You can now export your list”, not “refactored export module”). It does three jobs at once:

• Visitors who check whether the app is still alive find recent dates.
• You have a link to share when you post in step 5.
• It becomes the record of what you shipped and why, which helps when you look back at the numbers.

How to announce a new feature covers where to announce and how to write it.

With Nordva Launch: the changelog is on every plan (25 entries on Free, unlimited on Indie), with a public page. On Indie, up to 500 people can subscribe to get an email when you publish an entry.

Step 5: Decide the next place to try

At the end of the month, go back to your table from step 1 and pick one or two places for the next post. Returning where it worked, with the fixes from step 4 to show, is covered in what to do after launch. Beyond that, try one new place that looks like the one that worked (a similar community, the same kind of reader), and set aside the places that sent visits but no signups.

Give every new post its own tagged link, as in chapter 8, so next month’s table has one more row. A launch is not one day: the first place you tried is rarely the only one worth trying, and you can only tell which ones work by keeping the sources apart.

Step 6: Decide when to charge, or raise the price

If the app is free today, the first month tells you whether people come back to it. When some users return without being reminded and one or two ask for more, that is the sign to ask for money. Ask the ones who use it most first, one by one; how to get your first 10 paying customers shows how.

How to set the number is covered in how to price your first SaaS, and whether to keep a free plan or offer a trial in free plan or free trial. The short version: start from what the problem costs your customer, not from your costs, and raise the price when new customers stop hesitating at it.

If you already charge through Stripe, changing the price is a small job, but not an edit. Stripe doesn’t let you change the amount of an existing price: you create a new price, switch your checkout to it and archive the old one. Archiving a price keeps the subscriptions that already use it active until they are cancelled, so your first customers stay on the price they signed up for unless you move them (Stripe Docs). The payments chapter covers where the price lives in your app. Keeping early customers on their original price is a simple thank-you for trusting you first.

Who should not use Nordva Launch for this

If you already collect feedback in a tool you like and post updates somewhere your users read, keep them. The steps above work with a spreadsheet, a mail client and a notes file. Launch helps most when you want sources, feedback, the changelog and payments in one place instead of four.

Where to go from here

You now have the whole path: an idea checked with real people, an app built with AI, data, login and payments, hosting on your own domain, measurement, a launch and the loop that follows it. From here the work is that loop, repeated: find the people, listen, fix, tell them, and go where the last round worked.

When you want a step again, the Build with AI guide lists every chapter in order, and the launch checklist is there for your next launch.