What to do before launching an app, with three days left

The supports around the product, not the product itself. A working product that cannot see its own failures, and gives users no way to report them, turns a quiet launch into a broken one.

Here is an illustrative example, not a real founder. Say you are launching a browser extension on a launch site in three days. The urgent gaps are not marketing. They are a support email someone actually checks, error tracking, and a test on a slow connection. Error tracking is a small service that records each crash and what the user was doing when it happened. Without it, your first crash report is an angry comment you cannot reproduce.

Your own list holds the things you already thought of. Launch problems come from the other set. A good checklist covers the areas a solo founder tends to skip:

• Empty and error screens: what a user sees before they have any data, or when something fails.
• A privacy line: one plain sentence on what you collect and why, and a privacy policy page once you collect personal data such as an email.
• Link tags: UTM (Urchin Tracking Module) tags, short labels added to a link, show which post sent each visitor. Without them, day-one numbers tell you very little.
• A stop rule: decide before launch what problem would make you pull the release, so you are not deciding at midnight.
• Prepared answers: for questions you can predict, such as why the product needs certain permissions or what it will cost later.

None of these creates demand. All of them stop a launch from losing the demand it does get.

Be present, not just watching numbers. Spend the first hours answering every comment and noticing which complaint repeats. Then fix the single thing that breaks most. The checklist items above make that possible: people can reach you, and you can see errors.

Also plan for a quiet launch. Quiet launches are common, and a quiet one tells you about reach more than about the product. Know your next place to find users before launch day, see where your first users actually are.

The strongest case against leaning on it: a checklist does not create demand. If nobody wants the thing, a flawless launch also lands on silence. That is a different problem with a different fix, covered in how to tell if your idea is good or you are just excited.

The missing fact is whether you already tested the core journey with real people. If you have not, three days is a good moment to pause and check the smallest thing worth building. A checklist assumes the product works and deserves its chance.

Launch Checklist asks about your launch and suggests a list of things to check. Read it against your own situation and skip what does not apply to you.

Today, run two tests. Send a message to your support address from a different account, and trigger one error on purpose. If you do not see both within an hour, fix that before anything else. Then write your stop rule in one line and put it where you will see it on launch day.

Do I really need error tracking for a small launch?

Yes. A crash on day one with no record of what happened is very hard to fix. Adding a basic error tracker is usually a short job. You cannot fix what you cannot see.

I am not charging yet. Does all of this apply?

Mostly. Skip anything about taking payment and keep the rest. Still say plainly whether you plan to charge later, so nobody feels surprised.

Should I answer launch-day comments myself?

Yes, at least for the first hours. Those questions are the most honest user research you will get that week.