How do I put my app on my own company web address instead of a vendor subdomain?

This page may contain affiliate links from which Blur Studio earns commissions.

A vendor subdomain is a small thing that quietly costs trust. A customer who sees app.yourcompany.com assumes they're dealing with you directly. The same customer seeing yourproject.somebuilder.app has to do a double-take, wonder if it's legitimate, and that hesitation is the actual cost, not the technical inconvenience.

What moving to your own domain actually involves

At the mechanical level, there are three pieces: you need to own a domain (or already do), the platform hosting your tool needs to support pointing a custom domain at it, and you need access to change DNS records at wherever your domain is registered. None of these three pieces is hard on its own. The friction is almost always in confirming that the middle piece, platform support, actually exists on the specific plan you're paying for.

I checked this directly on Emergent's own pricing page and its public marketing pages: custom domain support isn't mentioned by name on any tier, Free, Standard, Pro, Business or Enterprise. That doesn't necessarily mean it isn't possible, platforms sometimes support features they don't advertise prominently, but it does mean you should not assume it's included just because a plan sounds comprehensive. Ask directly, in writing, before you buy a plan specifically to get this feature.

By contrast, Vercel's free Hobby tier has supported custom domains for years as a standard, well-documented feature, which is worth knowing if your tool is fully custom code rather than built on an AI platform, since it changes which option is actually cheapest for this specific need.

The step-by-step version

1. Confirm your plan supports custom domains, in writing, before paying for anything. Email support and ask directly: "Does [plan name] support pointing my own domain or subdomain at my app? What's the process?" Keep the reply.
2. Decide on a subdomain versus the root domain. Most setups use a subdomain like app.yourcompany.com or portal.yourcompany.com, which is simpler and safer than pointing your root domain (yourcompany.com itself) at a third-party tool, since the root often needs to keep serving your main website.
3. Add the DNS record at your domain registrar. This is usually a CNAME record pointing your chosen subdomain at a value the hosting platform gives you, though some setups use an A record pointing at an IP address instead. Whoever set up your tool, or your registrar's own support, can walk you through which type you need.
4. Wait for DNS propagation. This is usually fast, often minutes, but can take up to 24-48 hours in rare cases depending on your registrar and existing DNS settings. Don't panic if it's not instant.
5. Test the new address thoroughly before telling anyone to use it: load the page, submit a test form if your tool has one, and check that any login flow still works correctly on the new domain.

What the DNS panel actually looks like, in practice

If you've never touched DNS settings before, the actual experience is less intimidating than the terminology suggests. Most domain registrars (GoDaddy, Namecheap, Cloudflare and similar) present DNS management as a simple table: a record type column, a name or host column, and a value column. Adding a new record means picking the type your platform told you to use, typing the subdomain name you want (like "app" for app.yourcompany.com), and pasting in the value the platform gave you. There's no code involved, and most registrars show a save confirmation immediately, even though the actual change takes effect across the internet over the following minutes to hours. If you're nervous about getting it wrong, most registrars let you delete a record just as easily as adding one, so a mistake here is rarely permanent or hard to undo.

Two ways this actually plays out

A distributor I know built an order-status tool on an AI platform and assumed, reasonably, that a mid-tier plan would include a custom domain since it included "everything in the plan below plus more." It didn't. They found out only when they tried to configure it after already paying for a year upfront. The fix was a short support conversation and, in their case, an upgrade to a higher tier that did support it, but it cost them a wasted month and an awkward conversation about a refund for the difference.

A smaller, cleaner version: a solo consultant pointed a subdomain, book.consultantname.com, at a scheduling tool that lived on a third-party platform supporting custom domains natively and for free. The whole process, registrar DNS panel to working link, took about fifteen minutes, because the platform supported it clearly and the DNS change itself is genuinely simple once you know which record to add.

Common mistakes worth avoiding

• Buying a plan specifically for this feature without confirming it's included. Get the confirmation in writing first, always, regardless of how clearly a sales page implies it.
• Pointing your root domain instead of a subdomain when your root domain is already serving your main marketing website. This can take your whole website down if done carelessly. A subdomain is almost always the safer choice.
• Forgetting to renew the domain itself. A custom domain setup is only as reliable as the domain registration behind it. Set auto-renewal and make sure the renewal payment method is current, since a lapsed domain takes everything down, not just the tool.
• Not testing login flows specifically after the switch. Authentication systems sometimes have domain-specific configuration (cookies, redirect URLs) that needs updating separately from the basic DNS pointing. A page that loads but a login that silently fails is a worse outcome than the vendor subdomain you started with.

What this actually costs, and why it's rarely the money

The domain itself is cheap, typically $10 to $20 a year for a standard .com, and the DNS change is free. The real cost, when there is one, is the plan upgrade some platforms require to unlock custom domain support at all, which can range from a modest monthly increase to a meaningfully higher tier depending on the vendor. On Emergent specifically, since custom domain support isn't named on any published tier, the honest cost estimate is "unknown until you ask," which is itself the reason to ask before paying for any plan upgrade on the assumption it includes this.

Where businesses actually lose money on this isn't the setup, it's paying for a higher tier specifically expecting a feature that turns out not to be included, discovering it only after the annual bill has already gone through. A five-minute email to support before you pay anything avoids that entirely, and it's the single highest-leverage step in this whole process.

A second scenario: more than one tool, more than one subdomain

Businesses running several internal tools often end up wanting a consistent pattern, app.yourcompany.com for one tool, portal.yourcompany.com for another, reports.yourcompany.com for a third, each pointed at a different platform entirely. This is entirely workable and doesn't require any single platform to host everything; each subdomain gets its own DNS record pointing at whichever service actually hosts that specific tool. The planning worth doing upfront is naming them consistently and keeping a simple written list of which subdomain points where, since this is exactly the kind of small detail that becomes confusing eighteen months later when someone new joins and has to guess which address does what. A five-minute spreadsheet, updated whenever you add a new one, solves this completely and costs nothing.

How I'd approach this

When I set this up for a client, I confirm platform support in writing first, always, even when the sales page strongly implies it, because "strongly implies" has cost people real money more than once. Then I handle the DNS and login-flow testing myself, since that's the part most likely to go subtly wrong rather than obviously wrong, a page that loads fine but a login that silently breaks is the kind of issue that doesn't show up until a customer complains. If your current platform genuinely doesn't support custom domains at any price, that's useful information on its own: it tells you something about how much control you actually have over your own tool, which matters more as the tool becomes more central to the business.

When to skip this entirely

If the tool is purely internal, used only by staff who already know and trust it regardless of the address bar, a custom domain is a nice-to-have, not a priority. Spend the effort where a customer or outside party would actually judge you by the URL they see, and leave internal tools on whatever address is simplest to maintain.