Vercel, Render, and the client held hostage

More and more companies suddenly start paying a subscription in dollars for a website that ran perfectly on hosting they had already paid for. Usually not because they have to - but because someone picked the only tool they know. Here is how to tell a sensible migration from incompetence, and what to ask before you hand anyone access to your DNS.

I get an email. Short, polite, written by someone who genuinely means well:

„We specifically need access to manage the DNS records so we can repoint the domain, because we host on Render."

Everything in that sentence is fine except one thing: nobody ever asked why Render. The company website ran on shared hosting that was already paid for. That hosting is paid a year in advance. The company email lives on the same domain. And yet suddenly there is new infrastructure, a new subscription, a new invoice in dollars, and a request for the keys to the most critical asset the company has online.

This is not a piece against Vercel or Render. Both are excellent. This is a piece about what happens when a tool is chosen not because it is right, but because it is the only one someone knows.

Where this skills gap came from

The path used to look like this: FTP, the public_html folder, the hosting panel, an A record, MX, an .htaccess file, a database backup through phpMyAdmin. Boring, manual, but it forced you to understand how the internet is glued together.

Today the path looks like this: git push. The deploy happens on its own. The SSL certificate appears on its own. The domain connects through a wizard that says „add this record". Everything works, so why understand it.

The result is predictable: we have a generation of capable front-end developers who can build a great product and never had a reason to learn the difference between an A record and a CNAME, why a domain apex is a different problem from a subdomain, and what happens to email if you repoint the name servers.

This is not stupidity. It is a gap in experience. The problem only starts when the client begins to fund that gap - with a subscription, downtime, or lost email.

What actually breaks

1. Email dies on Friday afternoon

The most common migration disaster does not affect the website, it affects email. The scenario: instead of adding two records, the developer repoints the domain's name servers (NS) to the app hosting provider, because that is what the tutorial said. The new DNS zone starts empty. The MX, SPF, DKIM and DMARC records - which existed in the old zone - cease to exist.

The website works. The company inbox goes silent. The client finds out on Monday, when a business partner calls asking why nobody replies to their offers. The messages from that weekend never arrive - the senders got a bounce.

The rule: when you move only the website, you do NOT touch the name servers. You change the A record (or ALIAS/ANAME for the apex) and the CNAME for www. That's it. And if you really must move the NS, first export the full zone and recreate it record by record.

2. The domain apex is not the same as a subdomain

www.company.com can be pointed with a CNAME, and that is a standard, trouble-free operation. company.com - the apex - cannot be pointed with a CNAME, because the DNS standard does not allow it (it would collide with MX and NS). What is left is an A record to a fixed IP address, or an ALIAS/ANAME/CNAME flattening mechanism, if your DNS operator offers one.

This is exactly the moment when „please give us the IP addresses to point the A records at" turns out to be a question the other side cannot answer - because the PaaS provider shows a CNAME value in the panel and nothing else.

3. Subdomains disappear quietly

The company has orders.company.com - a B2B panel, a form, an integration, whatever. The migration is about „the website", so nobody thought about the subdomain. If the operation is limited to changing two records, the subdomain survives. If it involves repointing the NS - it vanishes along with the email.

Before every migration: export the entire DNS zone to a file and list every record with an answer for what happens to each one. One paragraph of work, saves a week of firefighting.

4. Analytics and SEO reset to zero

GA4 is not tied to the server, only to a tag in the code. A new site without the migrated measurement ID means a new, empty history. On top of that comes mapping old URLs to new ones, 301 redirects, the sitemap.xml file, re-verifying in Search Console, and checking that the new build does not accidentally ship a noindex tag from the staging configuration.

The site looks better, and traffic drops by 40%. Nobody connects those two facts for three months.

5. The bill that was never supposed to appear

This is where it gets concrete. Shared hosting for a company website with email is typically a few hundred zloty a year in Poland. Paid a year upfront, in the local currency, with an invoice and local support.

Render and Vercel are excellent, but their models start somewhere else. Render's free plan puts the service to sleep after a period of inactivity - the first visitor after a quiet night waits tens of seconds for the container to start. For a company website that is disqualifying, so in practice you move to a paid plan, per service, in dollars. The database is a separate line item. Vercel Pro is billed per user per month, plus limits on transfer and function calls above the package.

The total: a company that paid a few hundred zloty a year starts paying a few hundred zloty a month, for a site with the same functionality. And it still pays for the old hosting, because that is where the email stayed.

6. Who actually owns the account

The most underrated risk. If the project runs on Vercel or Render on the agency's account, on its payment card, in its repository - then the client does not have infrastructure. They have a relationship with the agency.

Parting ways with the contractor stops being a conversation about the final invoice and becomes a rescue operation. I have seen it up close during audits: a company cannot deploy its own website, because all the knowledge and all the access are on the other side.

When Vercel and Render make full sense

To be clear - I am not on the „everything on shared hosting" side.

A PaaS is the right choice when:

• the application is Next.js, Nuxt or SvelteKit with server-side rendering, ISR, edge functions - things shared hosting simply will not run;
• you need CI/CD, preview deployments on every pull request, one-click rollback;
• traffic is variable and scaling genuinely matters;
• several people work on one codebase and need staging environments;
• the application needs queues, cron jobs, workers, separate services.

Shared hosting is perfectly sufficient when:

• it is a brochure site, a catalogue, a blog, a landing page;
• the content changes once a quarter;
• traffic is predictable and local;
• and - this is the key part - Next.js can be exported statically. The output: 'export' option produces a clean set of HTML, CSS and JS files that you upload to any hosting over FTP, and which runs faster than a rendering server, because it renders nothing.

That last point is the one almost nobody mentions. A modern stack does not require a modern subscription. It only requires the knowledge of how to build it.

Questions the client should ask before handing over DNS access

Print it out, pin it above your desk, send it to the contractor:

1. Why this particular platform? What technical feature is missing on the hosting we already pay for?
2. What will the monthly cost of this infrastructure be in the first year, and after exceeding the free plan limits?
3. Whose account and whose card will the service run on? Can we have it on our own billing account?
4. Do you plan to change the domain's name servers, or only the A and CNAME records?
5. What happens to email on this domain? Who will confirm that the MX, SPF, DKIM and DMARC records stay untouched?
6. Which subdomains exist today, and what happens to each of them?
7. Do we have an export of the entire DNS zone before the change?
8. Does the GA4 ID and Search Console verification carry over to the new site?
9. Is there a 301 redirect map from the old URLs to the new ones?
10. What is the rollback plan if something does not work after the switch?
11. Is the code repository ours, and do we have access to it?
12. Who has access to the domain panel, and is that not changing?

If more than three of these get the answer „I'll check", that alone is reason enough to hold the switch until it is checked. There is no rush worth a week without company email.

A short brief for the contractor

Because half the problem is on this side, and it can be removed with a single ritual:

• 48 hours before the migration, lower the TTL of the records you are changing to 300 seconds. Raise it back after a successful migration. This way a rollback works in minutes, not a whole day.
• Export the DNS zone and paste it into an email to the client along with the list of changes: record by record, before and after.
• Do not touch the NS if you are moving only the website.
• Launch the new site under a temporary address and test everything before the domain starts pointing to it.
• Do the switch on Tuesday morning, not Friday at five.
• Offer the client an account in their own name and on the company card. It builds trust and protects you from becoming the other side's hostage.
• Calculate the cost and present it in writing before the client sees it on a statement. A surprise invoice costs more reputation than the amount itself.

The bottom line

The problem is never the technology. The problem is a choice made without an alternative - because the only environment someone knows automatically becomes the answer to every question.

The client cannot verify it, because there is no way for them to. They see a nice website, they hear „we host on Render", they trust and they click. A year later they pay a subscription in dollars for something they had paid for in local currency, and they cannot update the footer on their own.

That is why the only question worth asking at the start of every project is: what exactly does this architecture give this business that the one it already pays for does not?

If the answer is substantive - great, let's migrate, a PaaS can be worth it. If the answer is „because that's how it's done now" - that is not an architectural decision. It is a habit that someone else is paying for.

Run a company and not sure whether your infrastructure is set up sensibly and whether the access is genuinely yours? A DNS, hosting and cost audit is usually a few hours of work and a concrete list of things to fix. Get in touch.