Three pieces of production glue never make the demo: the domain, the email, and the analytics. They are unglamorous, they are where AI-built apps most often stay half-finished, and they are disproportionately what separates a project from a product in the eyes of users, inboxes, and eventually buyers. Each one is an afternoon when done deliberately. Here is the deliberate version of all three.
Quick answer: Register the domain in an account your company owns and point DNS at your hosting. Send transactional email through a sending service with SPF, DKIM, and DMARC records set, never from a personal mailbox. And track five product events that matter (signup, activation, core action, conversion, return) instead of pageviews.
Why does the domain belong in your registrar?
Because the domain is the one piece of infrastructure everything else hangs from, and it should survive every other decision: hosting moves, platform changes, developer changes. Register it (or transfer it) into a registrar account owned by the business, with company billing and recovery contacts, and treat platform-provided subdomains as scaffolding. This is the same ownership rule that governs all your accounts, and the domain is where it matters most, since losing control of it means losing the app’s identity, its email, and its search history in one stroke.
How do you connect a custom domain?
Mechanically: add the domain in your hosting platform, then create the DNS records it specifies at your registrar, and let SSL issue automatically, which every mainstream host now handles. The gotchas are consistent enough to list: propagation takes minutes to hours, so change DNS in a quiet window and keep the old destination alive meanwhile; proxied DNS settings can fight a host’s certificate issuance, so follow the host’s specific guidance; and the app’s own configuration has opinions too, since OAuth callback URLs, allowed origins, and any hardcoded links must learn the new address. When login mysteriously breaks the day after a domain move, it is the callback URLs, nearly every time.
Why is app email going to spam?
Because unauthenticated mail from an unknown domain is exactly what spam looks like, and the big inbox providers formalized that stance: bulk and transactional senders are now expected to authenticate with SPF, DKIM, and DMARC, and mail that fails increasingly disappears. The fix is standard practice. Send through a transactional service (Resend, Postmark, and SES are the usual suspects) rather than through a personal Gmail or the app server directly. Add the three DNS records the service gives you: SPF says which servers may send for your domain, DKIM signs each message so tampering and spoofing fail, and DMARC tells receivers what to do when the first two do not check out. Then send a test to a few providers and look at the headers for three passes. An hour, once, and your password resets stop dying in spam folders, which for an app with logins is a revenue repair rather than a nicety.
What analytics does an app need?
Not pageviews. Apps live and die on a handful of events, and the useful starter set is five: signup, activation (first moment of real value), the core action (whatever the app exists to do), conversion (payment or the equivalent), and return (they came back within a week). Instrument those and you can answer the questions that matter: where new users stall, whether changes help, and what usage precedes paying. Tooling can be GA4, which you likely already know from the marketing site, or a product-focused tool; the choice matters far less than the event list, and the event list fits on an index card.
How do you wire events without breaking the app?
Small and centrally: one tiny tracking helper in the code that every event calls, so the analytics tool touches the app in exactly one place, and event names live in one file instead of scattered through components. Fire events server-side where truth lives (a purchase is what the webhook confirms rather than what the button hoped), verify in the tool’s realtime or debug view, and respect consent where your audience requires it, which for public-facing apps in most markets means a consent step before analytics runs. Then leave it alone; analytics rot comes from clever additions, and the five-event card is deliberately boring.
What is the finish-line checklist?
- Domain registered in a company-owned registrar account with recovery contacts set.
- DNS pointed at hosting, SSL issued, old URLs redirecting.
- OAuth callbacks, allowed origins, and hardcoded links updated to the new domain.
- Transactional email routed through a sending service on your domain.
- SPF, DKIM, and DMARC records live, with a test send showing all three passing.
- Five product events defined, instrumented through one helper, verified in debug view.
- Consent handled where required, and the events documented in one place.
All of it is standard work, none of it requires touching what the AI built, and together with the monitoring from the operations guide it completes the boring, load-bearing layer of a real product. It is also, start to finish, part of what our production launch package does in a fixed scope.
Frequently asked questions
Can I send app email from my Gmail?
For a personal test, sure. For the app, no: personal mailboxes are neither authenticated for your domain nor built for automated volume, and providers throttle and flag exactly that pattern. A transactional service with your domain authenticated is the entire fix.
What is DMARC in one sentence?
A DNS record that tells receiving mail servers what to do with messages claiming to be from your domain that fail authentication, and where to send you reports about it. Start in monitoring mode, then tighten once your legitimate mail all passes.
Do I need a cookie consent banner?
If your audience includes regions that require consent for analytics (the EU and UK most prominently, with several other jurisdictions in the same family), yes, before analytics fires. The clean pattern is consent first, tracking second, and it is simpler to build in now than to retrofit.
Should I use GA4 or a product analytics tool?
Whichever you will look at. GA4 wins when you already live in it for the marketing site and want acquisition and product in one place; product tools tend to make funnels and retention easier to read. The five-event list is identical either way, and it is the part that matters.
How do I track users from the marketing site into the app?
Same analytics property or connected ones, consistent identifiers once someone signs up, and campaign parameters preserved through the signup flow. It is a small project worth doing when paid acquisition starts, and premature before then.
My email authentication passes and mail still lands in spam. Why?
Reputation and content, usually: a brand-new sending domain has no history, and certain phrasings trip filters. Warm up with low volume, keep transactional messages plain and expected, and check the sending service’s reputation dashboard, which will usually name the problem for you.