Where a website will live changes how it should be built. It affects which framework features are safe to use, how content is updated, where secrets are stored, what deployment looks like, how backups work, and who receives the bill after launch. That is why I no longer treat hosting as the final task waiting at the bottom of a project checklist. I want to understand it during the first week, alongside the content, users, and technical requirements. This matters especially with client work in Nepal. A client may already have a Hostinger or cPanel plan, a domain bought years ago, several email accounts attached to it, and one person in the office who needs to update a phone number. Moving everything to the platform I prefer could create a cleaner developer experience while giving the client a more confusing business system. The technically nicest answer is not automatically the most responsible one.

The four places a client website usually ends up

I usually think in four practical categories. A managed platform such as Vercel gives a modern application an excellent deployment workflow with previews, rollbacks, HTTPS, and infrastructure handled for me. AWS Amplify offers a similar Git-connected path inside the wider AWS ecosystem and can host static and server-rendered applications. A VPS, including Amazon Lightsail or a server from another provider, gives me a persistent machine where I control the runtime, reverse proxy, processes, storage, and deployment. Shared hosting gives the client a familiar control panel, file storage, databases, email, and often WordPress in one subscription. These categories overlap, but the responsibilities are different. The important question is not which logo looks most professional. It is which environment matches the application while leaving ownership, cost, and maintenance understandable after I hand it over.

What just putting it on Vercel quietly assumes

Vercel is often my fastest route for a Next.js project. Connecting a Git repository can create automatic production deployments, preview URLs for branches, useful logs, environment separation, and straightforward rollbacks. That convenience is real, but it sits on top of assumptions that are easy to ignore. Someone must own the Vercel team and the connected Git account. Someone must understand usage-based billing, receive alerts, keep a valid payment method when the project requires a commercial plan, and know what to do if a deployment stops. The application must also fit the platform model: local persistent files are not a database, long-running processes need a different design, and external services still need owners. Vercel removes a large amount of infrastructure work; it does not remove operational responsibility. I use it when the product benefits from that workflow and the client can inherit the accounts around it, not simply because the framework and platform belong naturally in the same sentence.

AWS can mean a platform or a server

AWS belongs in this decision, but saying hosted on AWS is not specific enough to be useful. AWS Amplify Hosting is the closer comparison to a managed frontend platform: it connects to a Git repository, supports continuous deployment, serves through a content delivery network, and can run supported server-rendered Next.js applications. Amazon Lightsail is closer to a VPS: it provides a virtual server with a defined bundle of compute, memory, storage, and transfer, and I remain responsible for the operating system, Node process, web server, updates, monitoring, and backups I configure. Beyond those are services such as S3, CloudFront, EC2, RDS, and Lambda, which can form a powerful architecture but also multiply the number of decisions and permissions a small client must own. I choose AWS when its ecosystem, control, regional architecture, or connection to other AWS services solves a real requirement. Using more infrastructure than the project needs is not future-proofing; it is transferring complexity into the future.

When shared hosting is the honest answer

Shared hosting is easy for developers to dismiss because it offers less control and does not always match a modern JavaScript workflow. For a brochure site, a WordPress build, or a frontend that can be exported as static files, it may still be the most honest answer. The client may already pay for it, recognize the billing portal, depend on email accounts attached to the plan, and have another local technician who understands the setup. Some cPanel providers enable a Node.js Application Manager, and some Hostinger plans support Node applications directly, but that support must be verified for the exact plan instead of assumed. A static Next.js export can work on much simpler hosting, but it gives up server-dependent features, so that choice has to be made while designing the site. I will not force a server-rendered architecture onto shared hosting through fragile workarounds. I will either shape the build for the environment or recommend an environment that genuinely supports the build.

The domain and DNS conversation nobody wants to have

The domain is often more operationally important than the web server. Before changing DNS, I find out who registered the domain, which email addresses receive renewal notices, where the authoritative nameservers live, and whether the same DNS zone controls business email. A careless nameserver change can launch the new website while quietly breaking mail. I prefer changing only the records the deployment requires, documenting the previous values, lowering time to live before a planned migration when appropriate, and confirming both the root domain and the www version. I also decide whether DNS should remain with the registrar, move to a service such as Cloudflare, or stay inside the hosting account the client already manages. There is no prize for moving it. The goal is a clear source of truth, working email, automatic certificate renewal, and credentials the client can recover without needing access to my personal account.

What I automate and what I deliberately leave manual

Automation is valuable when it removes a repeated, error-prone action. A push to the production branch can trigger Vercel or Amplify automatically. GitHub Actions can build a static site and transfer the output to shared hosting. A VPS deployment can pull a tagged release, install locked dependencies, run migrations, restart the process, and keep the previous version available for rollback. I still avoid automation that only I can understand. If a small site changes twice a year, a documented manual deployment may be safer than a complicated pipeline with expiring tokens and several hidden services. The test I use is simple: does automation reduce the number of things the next responsible person must remember, or does it hide those things inside a script? A short repeatable checklist can be an operational tool too. The best deployment process is not the one with the most YAML. It is the one that produces the same safe result and can be recovered when I am unavailable.

Environments, secrets, and the handoff problem

A production website usually depends on more than its source code. It may need database credentials, CMS secrets, email keys, analytics identifiers, storage access, webhook URLs, and different values for local, preview, and production environments. Managed platforms make environment variables convenient, but the values still need a documented owner. On a VPS, I keep secrets outside the repository, restrict access, and make the process manager or service definition reproducible. On shared hosting, I work within the provider's environment controls and avoid leaving secrets inside public files or deployment archives. During handoff, I create client-owned accounts wherever practical, verify recovery email and multi-factor authentication, and document where each secret is used without copying sensitive values into a general project document. The handoff is complete only when the client can grant or remove access, recover the important accounts, and identify which integration will fail if a credential expires.

Backups and who is responsible on day 400

A successful launch proves that the system worked once. Hosting decisions should also account for day 400, after content has changed, certificates have renewed, dependencies have aged, and the original project chat has disappeared from view. Source code in Git is not a complete backup when the live system includes a database, uploaded media, CMS content, DNS records, or email. I check what the provider backs up, how long it keeps copies, whether restoration is included, and whether anyone has tested that restoration path. A VPS gives me freedom to design backups, but it also gives me the responsibility to monitor them and store copies away from the same machine. Shared plans may include automatic backups, but the retention and restore process vary. Managed platforms protect deployment artifacts, not every external service the application uses. I write down who checks failures, who approves updates, and what support continues after launch. Otherwise everyone assumes someone else is watching.

Cost is a design constraint, not a footnote

Hosting cost is not only the monthly number on a pricing page. It includes developer time, monitoring, backups, paid seats, bandwidth or compute usage, email, database services, and the cost of recovering from a failure. A managed platform can cost more in direct fees while saving hours of server maintenance. A small Lightsail instance or another VPS can have predictable base pricing, but someone must patch it and respond when the process runs out of memory. Shared hosting can be inexpensive and sufficient when the site fits its limits, especially if the client already uses the plan for several business services. AWS can be economical when its services are composed carefully and unexpectedly expensive when resources are left running without budgets or alerts. I explain the likely normal cost, what makes it increase, and which person receives the notification. Budget changes architecture. Pretending otherwise only delays the decision until the first invoice.

Choose for the client you will actually have

My preferred hosting choice begins with the application, but it ends with the people responsible for it. I use Vercel when a Next.js project benefits from previews and managed deployment and the client can own the platform workflow. I consider AWS Amplify when a similar workflow belongs naturally inside an AWS environment, and Lightsail or another VPS when the application needs a persistent server and there is a real plan for maintenance. I keep or recommend shared hosting when WordPress, static output, existing services, budget, and local familiarity make it the more durable option. Sometimes I split the system: the domain and email remain where the client knows them, while the application points to a different host. The goal is not to demonstrate how much infrastructure I can operate. It is to leave behind a website whose hosting, accounts, costs, updates, and recovery path still make sense after the developer has stepped away.