Every small site I have built starts with a question that has nothing to do with design: who is going to edit this in March, and how often? Until that is answered, choosing a platform is guessing. It is easy to spend three weeks on typography for a site nobody will log into after launch, or to rebuild a perfectly good static site in WordPress so that one phone number can be changed without an email. Both are answers to the wrong question.
I build small sites for a living, but the only sites I am going to use as examples here are my own. There are four of them, on three kinds of hosting, and they are the ones I can open up without asking anybody’s permission. That constraint is also the reason this guide has no screenshots of somebody else’s dashboard and no case study with invented conversion numbers.
The question that decides everything else
Static or WordPress. Everything downstream — hosting, cost, maintenance, how nervous you should be about updates — follows from that one choice, and the honest way to make it is by editing frequency, not by features.
If the owner will write on the site regularly, it needs an editor, and that means WordPress or a hosted builder; if nobody wants to run a server, there is also WordPress run by someone else, a trade I weigh in WordPress.com vs WordPress.org. The editing surface is the product for those people. If the site changes three times a year — a phone number, a price list, a new photo — a static site is kinder to everyone, because there is nothing to patch, nothing to log into and no plugin that stops being maintained in 2028. The trap is the site built on a content management system because that felt professional, and then never updated again.
The domain goes first, and it goes in the owner’s account
Register the domain before anything else, in an account that belongs to whoever owns the business. Not the agency’s account, not bundled inside a builder subscription you might cancel. It is the one asset that survives every redesign and every host change, and reclaiming it later is a support ticket you do not want to open.
Two things I check on the registrar’s page before buying. First, the renewal price rather than the first-year price, which is exactly the same trap as hosting. Second, whether I am about to buy a name with a character that does not exist in ASCII, which I did with this blog and would not do again. I keep my registrar notes in the three registrars I use and where the renewal price hides.
Where the thing actually lives
Here is what I run right now, which is also the shortlist I choose from when I start something new.
| My site | Runs on | What it is | Why it is there |
|---|---|---|---|
| This blog | Hostinger shared | WordPress | I publish on it, so it needs an editor |
| My agency site | Hostinger shared, same plan | Static HTML | Changes rarely; shares a plan that is already paid for |
| A static site of mine | Cloudflare Pages, free tier | Static HTML | Changes a few times a year; nothing to patch |
| My own SaaS | Hostinger VPS KVM 1 | Node behind Caddy | It is an application, not a website |
For a WordPress site, shared hosting is still the right first answer. Hostinger’s Premium plan was $2.99 a month on the 48-month term and renews at $10.99 (Hostinger web hosting, checked 20 September 2026). Read that sentence twice: the discount requires paying four years up front, and the second-year number is the one to budget with. I go through the rest of that arithmetic in the checklist I run before putting a site on a host.
For a static site, I pay nothing for hosting. Mine sits on Cloudflare Pages’ free tier, where the first limit a five-page business site would meet is 500 builds a month, and it will not meet it (Pages limits, checked 20 September 2026).
Two caveats on the neighbours: Netlify, which I use for demos, now bills in credits rather than gigabytes, and Vercel’s free Hobby plan is for personal, non-commercial use, which rules it out for a client’s site or anything carrying ads (Netlify and Vercel pricing pages, checked 20 September 2026).
What is genuinely free, and what only looks it
The software is free. WordPress costs nothing, and so does every tool I use to check my work: Search Console, PageSpeed Insights, and curl, which is not marketed as a web tool at all and is the one I open most.
Certificates are free and automatic now, which is still worth saying because they are still sold as a feature. On 20 September I checked all five of my own sites: four run Let’s Encrypt certificates and the Cloudflare-hosted one Google Trust Services, and I bought, renewed and installed none of them.
What is never free: the domain, the hours, and the words. And the other kind of free — a subdomain on somebody else’s brand with their advertising on your page — is only worth it while nothing depends on the site. I separate the two in free hosting that is actually worth using.
Where an AI helps, and the problem it handed me
I build with Claude Code daily, so I will be specific about what that has actually done rather than talk about AI website builders in general.
Where it earns its place: bulk work against an API. When I had to go through all ninety posts on this blog, I pulled every one of them out through the WordPress REST API rather than opening ninety editor screens, and the replacements go back the same way. Same for generating a set of redirect rules and testing every one of them against the real URL list locally before pasting anything into a live .htaccess. That is the shape of the job it is good at: repetitive, verifiable, and wrong in obvious ways when it is wrong.
Where it cost me: in August 2026 the AdSense snippet went into this blog’s theme, in functions.php, during a session with my AI assistant on a day the plugin installer was not responding. It worked, and it was the wrong place. The theme came out of Hostinger’s AI site flow as a parent theme, not a child theme, so a theme update overwrites that file and takes the snippet with it. Nothing would break loudly; the ads would simply stop existing one day. I only spotted it while auditing the site for something else, and the fix is to move the code into a must-use plugin, which no update touches.
That is the pattern with generated setups generally: they produce something that works today and quietly puts your configuration somewhere it will not survive. Before you accept any automated build, find out which files are yours and which belong to the theme.
And the honest boundary: I have not used Wix’s AI builder, Squarespace’s, Framer, Webflow or any of the prompt-to-site tools that were launched this year. I am not going to rank tools I have never opened.
The order I work in
- Register the domain in the owner’s account, and write the renewal price in the notes.
- Decide static or WordPress by asking who edits it and how often.
- Pick hosting on the renewal price and on which limits are published, not on the badge.
- Install, set permalinks once, force HTTPS, and pick one canonical version of the domain.
- Write the five pages that do the work before touching fonts: what you sell, who you are, proof, contact, home.
- Add the legal pages if the site will carry ads, affiliate links or a form.
- Submit the sitemap in Search Console with its full URL, and remember the punycode spelling if the domain has one.
- Take one measurement before launch so there is a baseline to argue with later.
- Hand over: who holds the domain, who holds the hosting login, where the backups are and how to restore one.
The launch checks that have nothing to do with design
Four commands and one phone. Check that the four spellings of the address — http, https, with and without www — all end up at the same place with a 301. Check the certificate and its expiry date rather than trusting the padlock. Send mail to the address printed on the contact page and confirm it arrives from outside. Open the site on a real phone on mobile data.
for u in http://example.com/ http://www.example.com/ https://www.example.com/; do
curl -sI -o /dev/null -w "%{http_code} $u -> %{redirect_url}\n" "$u"
doneOne gap I will admit to rather than pretend I closed: none of my five sites sends a Strict-Transport-Security header, so no browser is ever told to stop trying plain HTTP on them. I checked on 20 September 2026, and it is still on my list.
Two things I would do differently
Turn on page caching the day the site goes live. When I checked my own two WordPress blogs on 20 September 2026, neither returned any page-cache header at all, and every request was being built by PHP 8.3.33. Nothing tells you. You only find out if you look.
And when you replace a site, actually remove the old one. I moved this domain from a static export to WordPress and left the old files sitting in the web root, where they stayed live and indexable for months. That is a longer story, and it is the whole of how this blog is set up and what it costs.
What goes wrong, and what I have no data on
I have never contacted support at any of these companies with a real problem, so I have nothing to say about response times or how they behave when something is broken at two in the morning. My timings are five requests from one house in Spain on one evening, measuring only the HTML of a home page: no CSS, no images, no Core Web Vitals, and nothing that a reader in Ohio would experience. And I have never run any of these sites under meaningful traffic, so anything I told you about scale would be invention.
What I can tell you is that the build is the easy part. It is the domain sitting in the wrong account, the renewal nobody budgeted for and the old site nobody deleted that cause the actual problems, and all three are decided in the first hour.