Launching your AI-built app: a checklist for hosting, backups and monitoring

Put every account in your own name

The first thing I check with a new client is whose name the accounts are in. Often the database runs on a freelancer’s personal account, the domain sits under an agency’s account, or the app only lives inside the AI tool. As long as everything works, you won’t notice. But when that person can’t be reached or the collaboration ends, you can no longer get to your own app.

So make sure every account is in your company’s name: the domain, the GitHub organisation that holds the code, the database (Supabase or Firebase, for example), the hosting (such as Vercel or Netlify) and your payment account, such as Stripe. Use a business email address that isn’t tied to a single employee, and turn on two-factor authentication everywhere.

If you work with a developer or agency, add them as a team member instead of letting the account be in their name. That way you always keep access to your source code and your data, and you can revoke someone’s access without your app going down.

Separate testing from production, and keep secrets secret

Many apps built with AI have just one environment. Every change goes straight to your users, and a test with fake data ends up in your real database. Set up at least two environments: a test environment where you try new things and a production environment for your users, each with its own database.

Keys and passwords, such as the API key of your payment provider or the admin key of your database, don’t belong in the code. Put them in environment variables at your hosting provider. Code gets shared, copied and sometimes made public by accident, and any key inside it is then usable by anyone.

Pay special attention to keys that end up in the browser. Anything the front end of your app uses can be seen by a visitor. Keys with admin rights belong on the server only. If you have ever put a key in your code, replace it with a new one. Deleting it isn’t enough, because it is still in the history of your code.

Backups: make them and test that they work

A database can break, and even more often someone deletes data by accident, sometimes the AI tool itself. That is when you want a backup. So find out which backups your hosting makes, how long they are kept and whether you can restore them yourself.

Take Supabase as an example. According to its documentation, Supabase makes daily backups, but for projects on the free plan Supabase itself recommends exporting your data regularly and storing it somewhere else. On the Pro plan you can restore the daily backups of the last 7 days. If you want to lose less than a day of data, Point-in-Time Recovery is a paid add-on. And files that users upload are not part of the database backup, so you need to back those up separately.

A backup you have never restored is an assumption. Restore one at least once in your test environment and check that everything works. Then you know how long it takes and what to do when you really need it.

Monitoring: know before your customer notices

Without monitoring, your customers are the ones who tell you your app is down. Uptime monitoring checks every few minutes whether your app can be reached and sends you a message when it can’t. There are free and cheap services for this, and setting one up takes about fifteen minutes.

Uptime only tells you that your app is on, not that it works. That is why you also want to track errors. An error tracking service shows which errors users run into, on which page and how often. That way you see the payment page failing before anyone complains about it.

Agree who receives those alerts. A warning in an inbox nobody reads doesn’t help. Pick one person who is responsible, and make sure they know what needs to happen next.

Does your app send email? Set up SPF, DKIM and DMARC

Password resets, confirmations and invoices: many apps send email. If those end up in spam, a new user can’t even log in. Whether your mail arrives depends largely on three settings in the DNS of your domain: SPF, DKIM and DMARC.

Google asks every sender to Gmail for at least SPF or DKIM, and senders of large volumes for all three. Other large providers have similar requirements. So send your mail through a service built for it and follow their guide for the DNS records.

Then test with a few real mailboxes, such as Gmail and Outlook, to see whether your messages land in the inbox and not in spam.

SPF

A list in your DNS of the servers that may send mail on behalf of your domain.

DKIM

A digital signature on your messages, so the recipient can check they really come from you.

DMARC

A rule that tells recipients what to do with mail that fails SPF and DKIM.

Privacy, terms and GDPR

As soon as your app stores names, email addresses or other personal data, the GDPR applies. That doesn’t mean you need a lawyer on staff, but it does mean you need a few things in order before you go live.

You need a privacy statement that says which data you process, why and how long you keep it. Terms and conditions set out what users can expect from you and where your liability ends. And if suppliers process data for you, such as your hosting, your database or your email service, you sign a data processing agreement with them. Article 28 of the GDPR requires it. Most large providers have a standard version you can request or accept.

Also check where your data lives. A database in the EU makes things a lot simpler than a server outside Europe. With most services you pick the region when you create a project, so choose it deliberately.

This article isn’t legal advice. If you are unsure what your app needs, ask a lawyer who specialises in privacy.

Costs that grow, and who you call when it breaks

The free plans of hosting, database and AI services are generous enough to build on, but not always to grow on. Costs rise with the number of users, the amount of data, the traffic and every call to an AI model. Set a budget alert or spending limit on every service, so a busy week or a bug in your code doesn’t quietly turn into a large bill.

Also decide now who you call when something goes wrong. On a quiet afternoon you might try a fix yourself with the AI tool. But when your app is down while customers are paying, you want someone who knows the code and can respond quickly. Arrange that before you need it, with clear agreements on response times.

That is where I come in. In my maintenance plans I keep an eye on your app with monitoring, check daily for known vulnerabilities in the packages your app uses, update them and take care of backups. When there is an outage, I respond within 2 hours on working days between 9:00 and 17:00.

The checklist

Go through these points before you let real users in. If you can’t tick one off, put it on your list for this week.

1. 1Domain, GitHub, database, hosting and payment account are in your company’s name, with two-factor authentication.
2. 2You have a separate test environment with its own database.
3. 3There are no keys or passwords in the code, and keys with admin rights never reach the browser.
4. 4You know which backups are made and you have restored one as a test.
5. 5Files that users upload are backed up separately.
6. 6Uptime monitoring and error tracking are on, and one person receives the alerts.
7. 7SPF, DKIM and DMARC are set up and your mail arrives in Gmail and Outlook.
8. 8Your privacy statement and terms and conditions are online.
9. 9You have data processing agreements with the suppliers that process personal data for you.
10. 10Every service has a budget alert or spending limit.
11. 11You know who to call during an outage and how fast they respond.