What I Check Before a Startup Goes Live

For founders, going live often feels like one technical moment: flip the switch and the product is on. In practice, “live” is a collection of decisions you can make cheaply a few weeks before launch, or fix expensively a few weeks after.

Here is what I check before an early startup goes live. Not to turn it into a security audit, but to limit the risks that can do the most damage in the first weeks.

The question is never “is everything perfect?”. The question is “do we know what we don’t know, and can it come back if it breaks?”.

A minimal production check

Before the actual launch I want answers to a short set of questions:

• Who confirms that the live version is actually the live version, not the staging build by accident?
• Which test user has been removed from the production database?
• Which debug tools, console logs or test payments are still open?
• Which “placeholder” text is still in the build?

These are small things. They are almost always missed because the build team is busy with something else. A founder can walk through everything in half an hour. Cheaper before than after.

Logging and monitoring

A production environment without logging is a black box. You only know something is wrong when a customer tells you, and by then that customer is already gone.

Minimum required:

• Basic error logging with a timestamp, a user ID and the action being performed.
• A notification to someone (email, Slack) when an unexpected error happens.
• An uptime monitor that checks whether the site is reachable at all.

This does not need to be a Datadog setup. A simple error-reporting service and a free uptime monitor are enough for the first months. What they have to do: wake you up before a customer calls.

Backups

Before launch, ask how often the database is backed up, where the backups live and how you restore one. Test that last part once before launch. A backup that has never been restored is not a backup.

The other thing to know: what do you lose in the worst case? An hour of work? A day? A week? If you do not have the answer, you do not know your risk.

Error messages

What does a user see when something breaks? A “something went wrong” message is acceptable. A blank page, a stack trace or an English error message on a localised product is not.

Walk through a few obvious failures before launch: what if someone forgets their password? What if a payment fails? What if the login page is unreachable? What if a download breaks?

A customer’s first impression is often shaped not by what worked but by what broke first.

Payment flow

If you sell products or subscriptions, the payment flow is the most important part. This is what I test by default:

• A successful payment, does the customer get the right access, invoice and confirmation email?
• A failed payment, what happens, can the customer retry?
• A recurring subscription that drops halfway, what happens at the renewal date?
• A refund, does it actually work in practice?

For the first customers of an early startup, I prefer to have verified all four paths at least once in production. Not on principle, but because the corner where payments go wrong tends to produce the most expensive customer conversations.

A workable support process

Who responds to the first customer who asks a question? On which channel? Within what time?

An early startup does not need a 24/7 help desk. But there should be an agreement about how questions come in, who answers them and what the reasonable expectation is for your customer.

Practical minimums:

• One email address that is actively monitored.
• A simple FAQ on the site with answers to the five questions you most expect.
• An internal note where you keep recurring questions and answers, so the second time goes faster.

Security basics

For an early startup this is not a full audit. It is a short checklist:

• HTTPS is enforced on all paths (no mixed HTTP/HTTPS).
• Passwords are stored correctly (hashed, not plain text).
• Access to the production environment is limited to people who need to do work in it.
• No secret keys in the codebase or in a public repository.
• Two-factor authentication is on for your hosting, your domain registrar and your email.

These are basics. They often have not been done because they did not feel urgent. Until they are urgent and it is too late.

For founders facing GDPR, NIS2 or security questions, those are separate conversations that do not fit inside a launch check. But the basics above belong in one.

A rollback plan

What do you do if the new version turns out to be broken? How do you go back to yesterday’s version?

For an early startup this does not have to be an automated process. It does have to be a process. Write it down:

• Which button do you press, or which command do you run?
• What do you lose by rolling back (e.g. database changes)?
• Who do you inform?

A rollback plan that lives in someone’s head is not a plan. A plan in a note you can execute in ten minutes is enough.

Customer communication

Finally: an early launch usually means something somewhere breaks. That is fine. It becomes a problem when customers hear nothing about it.

A simple upfront agreement: if something breaks, who informs customers and how? A short email that says “something went wrong, we are looking at it, we will get back to you” is enough. What does not work: four days of silence followed by an excuse.

What does not have to be perfect

Many founders delay launch because something does not feel “finished”. This is what you do not have to fix before going live:

• The design is not pixel-perfect everywhere.
• Not every browser has been tested.
• Onboarding could be smarter.
• There are small inconsistencies between screens.
• The marketing site is missing a few pages.

These are things you fix better after launch with real customer data. Waiting until they are done mostly means you are not learning.

The rule of thumb: anything that protects customers, payments, security, basic error handling, has to be in before launch. Anything that makes the product nicer belongs after.

---

Facing this decision?

Send me the context or book a free call. We will look at the most sensible next step before you commit time, money or focus.

Book a free call → · Email directly: hello@yourstartup.expert