Launch Checklist for an AI Side Project: Domain, Hosting, Analytics

You've built something that works on your laptop, and you want people to use it by the weekend. The order matters more than the tools: pick the name, pick where it runs, point DNS, get HTTPS working, cap what it can cost you, add analytics, then test it from outside. Skip a step and you find out in public.

This checklist is general advice plus facts I checked on 2026-10-09 against vendor docs. Where I name a plan limit, the source is cited. I wrote and ran one small smoke-test script for the last step and pasted its real output below. I did not deploy a site for this post.

What should you decide before you buy anything?

Answer these on paper first. They decide which hosting is even allowed.

• Is money involved? Charging users, showing ads or affiliate-first content changes which free plans you may use (see the hosting section).
• Does it need a server process? A static landing page plus an API is different from an app that holds long-running model calls.
• What breaks if it goes down for a day? If the answer is "nothing", you can use the cheapest option. If paying users depend on it, you need monitoring and backups.
• Who sees user input? If you send user text to an LLM provider, say so on the page. For policy wording, see the AI use policy template.

How do you choose and secure the domain?

1. Pick a name you can say aloud, then check availability at a registrar. Also search the name in the trade mark registry for your country and on search engines for confusingly similar products. A registry search is a pre-check, not legal clearance; ask a professional if the name matters commercially.
2. Compare first-year and renewal prices before paying. Introductory prices commonly differ from renewal, and I have not quoted any figure because they change. Read the checkout page, not the home page.
3. Turn on auto-renew and two-factor login on the registrar account. A lapsed domain is the cheapest way to lose a project.
4. Keep the domain and the hosting under different logins where you can. If your host account is compromised, the domain is still yours.
5. Keep a text file of your DNS records after you set them. You'll need it when you move.

I haven't made any registrar recommendation; any reputable one works. Use the one whose renewal price and support you've checked.

Where should it run: managed static host, PaaS or a VPS?

Fairness matters here, because each answer is right for someone.

A VPS is the right call when your app needs a worker that runs for minutes, a database next to it, or tools like n8n. The VPS guides on this site use Hostinger, for example the KVM 2 plan, and the setup is explained in deploying Next.js on a Hostinger VPS and reviewing Hostinger VPS in India. Some links on this page are affiliate links; they cost you nothing and I only link tools I'd mention anyway. If you're unsure, a managed host is less work, and Hetzner or DigitalOcean give you the same Ubuntu image with nothing to relearn.

Decision rule: if you need no background process and no money flows, start on a managed static host. If you need a worker or a database, or you take payments and want a flat cost, start on a VPS. If you can't decide, pick the one you can set up in an afternoon, because you can move later (keep your DNS records written down).

How do you point DNS and get HTTPS right?

1. Lower the TTL on any existing records a day before you move them, if you're replacing a live site.
2. Add an A record (or CNAME for a managed host) for the root and for www. Pick one as canonical and redirect the other.
3. Wait for DNS to resolve from outside your network, not just your laptop. Test with dig +short yourdomain.com or an online DNS checker.
4. Get a certificate. Caddy and most managed hosts issue one automatically once DNS points at them.
5. Redirect HTTP to HTTPS.
6. If you front the site with Cloudflare, set SSL mode to Full (strict) after the origin has a certificate. Limits that matter for AI apps, such as the proxy read timeout, are in the Cloudflare free plan post.
7. If the app sends email (receipts, password resets), set up SPF, DKIM and DMARC records with your sending provider's instructions before the first real send. The transactional email comparison covers free caps, prices and the DNS records.

What do you secure before strangers arrive?

This is the AI-specific part. Everything in the hardening checklist applies to a VPS; the items below apply everywhere.

• API keys server-side only. Never ship a key in front-end code. Search your repository history for keys before making it public.
• One key per project, with a provider-side monthly spend limit. Then trigger the limit on purpose with a tiny cap so you know what users will see.
• Per-user daily caps and a max output token setting in your own code. See rate limiting a free-tier AI app.
• Estimate your cost per 1,000 requests before launch, using your real prompt sizes. This worked-examples post shows the arithmetic.
• Treat anything the model reads as untrusted if it can call tools. Prompt injection for tool-using agents covers it.
• A privacy line and a terms line on the site. If you take payments, see the refund and chargeback policy template. Legal wording should be reviewed by a professional.

For the wider production readiness list, use the AI agent production checklist.

Which analytics should you add, and when?

Add analytics last, so your own testing doesn't pollute the numbers, and restrict the script to your production hostname. Three honest options: a free hosted tier, a paid cookie-free tool, or self-hosting. I wrote up the self-hosted route, including a compose file I validated, in cookie-free analytics with Umami or Plausible. Decide what you'd actually act on first. For a launch, three numbers are usually enough: visits by referrer, how many reach the main action (a sign-up or a first prompt), and where they drop off.

Also add error tracking or at least a log you check daily, and an uptime ping. A free uptime monitor emailing you is better than finding out from a user.

How do you smoke-test the launch from outside?

Before you share the link, check the boring things that make a site look unfinished. I wrote this script (Python standard library only) and ran it against a tiny local test site I made for the purpose, so the output shows what a failing run looks like:

import sys
import urllib.request
import urllib.error
from urllib.parse import urlparse


class NoRedirect(urllib.request.HTTPRedirectHandler):
    def redirect_request(self, *a, **k):
        return None


opener = urllib.request.build_opener(NoRedirect)


def get(url):
    req = urllib.request.Request(url, headers={"User-Agent": "prelaunch-check/1.0"})
    try:
        r = opener.open(req, timeout=10)
        return r.status, dict(r.headers), r.read(200000)
    except urllib.error.HTTPError as e:
        return e.code, dict(e.headers), b""
    except Exception as e:
        return None, {"error": str(e)}, b""


def main(base):
    base = base.rstrip("/")
    host = urlparse(base).hostname
    fails = 0

    def check(ok, label, detail=""):
        nonlocal fails
        print(("PASS " if ok else "FAIL ") + label + (f"  [{detail}]" if detail else ""))
        if not ok:
            fails += 1

    s, h, body = get(base + "/")
    check(s == 200, "home returns 200", str(s))
    check(b"<title>" in body.lower(), "home has a <title>")
    check(b'name="description"' in body.lower(), "home has a meta description")
    check(b'property="og:image"' in body.lower(), "home has an og:image tag")
    check(b'rel="canonical"' in body.lower(), "home has a canonical link")

    s, h, _ = get(base + "/definitely-not-a-page-xyz")
    check(s == 404, "missing page returns a real 404", str(s))
    s, h, _ = get(base + "/robots.txt")
    check(s == 200, "robots.txt exists", str(s))
    s, h, _ = get(base + "/sitemap.xml")
    check(s == 200, "sitemap.xml exists", str(s))

    if base.startswith("https://"):
        s, h, _ = get("http://" + host + "/")
        loc = h.get("Location", "")
        check(s in (301, 302, 307, 308) and loc.startswith("https://"), "http redirects to https", f"{s} {loc}")
        check("strict-transport-security" in {k.lower() for k in h}, "HSTS header present")
    else:
        print("SKIP https checks (base is not https)")
    print(f"{fails} failing check(s)")
    return 1 if fails else 0


if __name__ == "__main__":
    sys.exit(main(sys.argv[1]))

Save it as prelaunch.py, then run python3 prelaunch.py https://yourdomain.com. Real output from my local run against a page with a title, description, canonical link and robots.txt, but no og:image tag and no sitemap:

PASS home returns 200  [200]
PASS home has a <title>
PASS home has a meta description
FAIL home has an og:image tag
PASS home has a canonical link
PASS missing page returns a real 404  [404]
PASS robots.txt exists  [200]
FAIL sitemap.xml exists  [404]
SKIP https checks (base is not https)
2 failing check(s)

The HTTPS branch is untested: my attempt to point the script at a public HTTPS site failed because the sandbox's network proxy closed the connection, which is a limit of my environment, not a result about that site. The version printed above is also trimmed slightly from the one I ran (fewer title checks), so treat it as a starting point. Run it yourself and read each FAIL. A missing og:image means your link preview in chat apps will look bare.

Then do the manual checks a script can't:

• Open the site on a phone, on mobile data, in a private window.
• Run a signup, a payment (in test mode) and a password reset end to end.
• Paste the URL into a chat app and see the preview card.
• Submit a long prompt and an empty one, and confirm both fail gracefully.
• Confirm your spend limit, an error alert and your backup restore actually work.

What goes in the launch-day order?

1. Smoke test passes, spend caps verified, analytics showing one real visit.
2. Take a snapshot or backup, and note the previous version so you can roll back.
3. Announce to a small group first. Watch logs and spend for an hour.
4. Fix what they hit, then post publicly. If you're planning a bigger public launch, the Product Hunt and Hacker News playbook covers each platform's rules and what a launch cannot do.
5. Next morning: check cost, errors and the three analytics numbers. Write down what you will change this week.

Printable checklist

• Name chosen, trade mark pre-check done, domain bought with auto-renew and 2FA
• Hosting matches your commercial use (Vercel Hobby is non-commercial only)
• DNS set, www and root redirect to one canonical host
• HTTPS works, HTTP redirects, Cloudflare mode (if used) is Full (strict)
• Keys server-side, one per project, provider spend limit tested
• Per-user caps and output token limits in code
• Privacy and terms pages live; refund policy if you charge
• Analytics restricted to production domain, one real visit seen
• Uptime check and an error log or alert
• Smoke test run, manual phone test done, backup and rollback plan noted