Early startups confuse two properties: the marketing site that explains the product and collects waitlist emails, and the product application where users log in and click the buttons you actually built. Treating those as one hosting problem creates expensive architecture theater — or a brochure trapped on an app-platform bill. This guide keeps SiteHost in the marketing lane and refuses to pretend it is application hosting.

Marketing site vs product app

Marketing site. Homepage, pricing narrative, docs entry links, careers teaser, blog if someone will write. Often static files or lightly dynamic at the edges (forms to third parties). This is file hosting territory.

Product app. Authentication, databases you design, background jobs, region pinning, uptime tied to paying-user SLAs. Belongs on app platforms, containers, or infrastructure your engineers chose on purpose.

SiteHost serves the first category: zip or GitHub upload, HTTPS preview immediately, custom domain after DNS verifies, deploy history for file rollback. No cPanel, no email hosting, no built-in CDN, no website builder. Plans run from Starter at $9/mo (1 site, 2 GB) through Pro at $30 (3 sites, 10 GB, staging), Scale at $65 (10 sites, 30 GB), and Business at $130 (30 sites, 100 GB, teams). Trial is about a day, then paid — no forever-free plan.

If an engineer asks “can we run our API here?” the answer is almost always no. Keep APIs with the app. SiteHost is for people who want a website online, not a server.

Skip this guide if you need a single platform to run multi-tenant application code. Read your app host’s docs instead, and optionally still park marketing elsewhere.

Why startups still want a boring marketing host

Decoupling pays for itself:

  • Marketing copy deploys without touching production app releases
  • A contractor can ship homepage messaging without VPC credentials
  • A framework rewrite on the product side does not force a homepage redesign
  • https://yourstartup.com appears on investor decks and job posts quickly

Preview-first workflow keeps unfinished slogans off the apex domain: how to publish a website online. Pure campaign pages: host a landing page online.

Staging, experiments, and launch weeks

Pro fits a common early pattern: public marketing site + staging slot + temporary launch microsite. Scale and Business appear when you proliferate regional landers or need team access. Do not buy Business to “look serious” while the homepage is still one HTML file — seriousness is clarity of offer, not invoice size.

Launch-week checklist:

  1. Freeze copy on HTTPS preview
  2. Click-test waitlist forms from a phone
  3. Point DNS only when preview is approved (how to point DNS to website hosting)
  4. Confirm custom domain HTTPS after verification (free SSL for a small website)
  5. Then flip ads and Product Hunt links

Rollback exists for bad file publishes. It does not undo a DNS typo — serialize those changes.

Forms, analytics, and early payments

Waitlists belong on third-party form tools embedded in HTML. Analytics scripts are optional; add them intentionally and respect consent rules in your markets. Early payments for deposits or waitlist merch can use Stripe Payment Links — your page stays a marketing page; checkout lives elsewhere.

Avoid pasting five marketing pixels “for later.” Launch day performance dies by a thousand tags (fast-loading website hosting). SiteHost has no built-in CDN; optional Cloudflare is a later growth lever, not a substitute for compressing the hero.

Failure mode: shipping the app stack as the brochure

If your “website” is a full application build with server rendering and auth, you need application hosting. Engineers can still export a static marketing build from a separate project and publish that output to SiteHost — upload the export, not the monorepo and its toolchain.

If marketing leadership demands WordPress for editorial workflow, use WordPress-oriented hosting — a WordPress CMS is a different kind of hosting. Do not wedge it into a static-only assumption.

DNS split that keeps everyone sane

A clean pattern:

  • yourstartup.com → SiteHost (marketing)
  • app.yourstartup.com → product platform
  • docs.yourstartup.com → docs host or same marketing site

Edit only the records each vendor asks for. Protect MX records so investor mail does not bounce during a website cutover. Connect a domain to your website.

Example: two-founder SaaS

Founders run the app on a platform their CTO likes. The homepage lives on SiteHost Starter as a static export from a simple design. Waitlist form posts to an email tool. When positioning pivots, the marketer publishes a new zip without touching Kubernetes. During a launch, they almost pointed ads at the apex before the custom domain certificate issued — preview saved them. Paying $9/mo beat a free host that slept during a front-page spike.

Hiring a contractor to touch only marketing

Give contractors SiteHost access appropriate to marketing sites — not production app credentials. Let them publish zips to preview, and require approval before DNS-facing production changes. Separating hosts makes that social boundary easier.

Docs and marketing boundaries

Product docs may live on a docs platform while the story homepage lives on SiteHost. Link clearly. Do not force engineers to redeploy app clusters to fix a typo in the pricing narrative. That separation is one of the quiet reasons boring marketing hosting exists.

Pricing page honesty

Your marketing host will happily serve vapor pricing. Resist. If plans are still in flux, use a waitlist lander instead of fake matrices. Publishing truthful HTML on SiteHost is easier to respect than debugging angry tweets about prices that never existed in the product.

Careers page basics

A simple HTML careers page with role summaries and a form or email beats a broken greenhouse embed you forgot to renew. If you use a hiring tool, test the embed on HTTPS preview after every redesign publish.

Status pages vs marketing pages

When the product is down, do not silently rewrite the marketing homepage into an apology novel. Link to a status page on your app platform. Keep SiteHost’s marketing story stable so recovery messaging stays somewhere intentional instead of entangled with positioning experiments.

Questions people actually ask

Can investors tell we use “simple” hosting?

They notice downtime and confusion. They do not taste your server distribution.

Should the blog live on the marketing host?

If it is flat files or a static export, yes. If editors need a CMS, pick tools that match.

Do we need Cloudflare on day one?

Optional. Fix asset weight first.

Is forever-free marketing hosting fine for a startup?

SiteHost has no forever-free plan. A clear $9 beats unexplained free-tier sleep on launch day.

How do we migrate later?

Keep file ownership and domain ownership. Point DNS elsewhere when you outgrow. Portability is a folder plus a domain.