Startup hosting that keeps the site away from the product.
The marketing site should never be able to take the app down, and engineers should never be the reason a pricing page is a day late.
Two systems, one brand.
The marketing site and the product have opposite requirements, and running them together costs both of them.
The site cannot take the app down
Marketing sites collect plugins, tags and experiments. Keeping them off the product's infrastructure means an enthusiastic growth experiment cannot become an incident.
A launch you did not plan for
A post lands somewhere and the homepage takes a year of traffic in an afternoon. It is served from the edge, so being noticed is not an outage.
Change it without a deploy
Copy changes weekly at this stage. Marketing edits the site directly, so shipping a positioning change does not consume engineering time you do not have.
Uptime that investors and customers see
The marketing site is the public face during a raise or a launch. It is the cheapest thing to make reliable and the most visible when it is not.
Move fast, undo faster
Daily restore points mean an experiment that went wrong is reverted rather than debugged at ten at night.
Engineering time is the scarce thing.
Every hour an engineer spends on the marketing site is an hour not spent on the product. The hosting decision is really a decision about who is allowed to change what.
- Marketing site isolated from product infrastructure
- Content changes without engineering involvement
- Homepage served from the edge for unplanned spikes
- Restore points for fast experiments
The day you get noticed.
Startup traffic is not a curve. It is nothing, then a front page, then nothing again, and the site is judged entirely on the middle part.
What we change for startups
The constraint is engineering attention, and every row is about not spending it here.
| Setting | What we do | Why |
|---|---|---|
| Infrastructure separation | Marketing site kept off the product's infrastructure | Marketing sites accumulate tags, plugins and experiments, and none of that belongs anywhere it could affect the thing customers pay for. |
| Publishing access | Content changes possible without a deploy | Positioning changes weekly at this stage, and routing every copy edit through engineering is the most expensive way to change a sentence. |
| Spike handling | Homepage and posts served from the edge | Startup traffic arrives as a single unplanned event when something lands somewhere, which is exactly the day the site must not fall over. |
| Rollback | Daily restore points covering rapid changes | Moving fast means occasionally being wrong, and reverting is cheaper than diagnosing at ten at night before a demo. |
| Plan changes | Applied without a migration | Growth at this stage is unpredictable in both directions, and rebuilding infrastructure to match it is work with no product value. |
Simple, transparent pricing.
Every plan includes free migration, daily backups, SSL and 24/7 support.
- 1 WordPress site
- 10 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Support tickets
- 5 WordPress sites
- 50 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Priority support tickets
- 20 WordPress sites
- 200 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Dedicated support
Questions, answered.
Should the marketing site run on our product infrastructure?
Can non-engineers change the site?
What happens if we get on the front page of something?
What if we outgrow the plan?
Spend the engineering time elsewhere.
Move the marketing site across - migration is free, no engineering needed.