Answered plainly

Hosting a small website costs nothing. Not a introductory nothing that becomes forty dollars in month four. Vercel, Netlify and Cloudflare Pages all host personal and small business sites on free plans that are genuinely free, and they do it because a tiny fraction of people eventually need something large enough to pay for.

The thing you do pay for is the name. A domain runs about twelve dollars a year, sometimes nine, sometimes fifteen if the word is popular. That is the entire bill for a working website with your own name on it: roughly one pound a month, or about the same as leaving a light on.

Here is where the confusion comes from. The hosting industry spent two decades selling shared servers at five to twenty dollars a month, because in 2005 that was a real cost with real hardware behind it. That pricing survived long after the cost did. If you search for hosting today you will still find companies quoting monthly plans with words like bandwidth and cPanel, and you can safely walk past all of it.

Costs only reappear when your site starts doing things rather than showing things. A database with real users on it starts free and stays free for a long time. Sending email costs fractions of a cent. Taking payments costs a percentage of money you have already received, which is a very different feeling from a bill. None of that arrives until you go looking for it.

A freelance developer will usually quote between $1,500 and $8,000 for a small business website, and an agency will usually start around $10,000. Rates run roughly $50 to $90 an hour in Eastern Europe and South Asia, $75 to $150 in the UK and Australia, and $100 to $250 in the United States.

What you are paying for at the low end is time, and what you are paying for at the high end is judgement. A $2,000 site and a $20,000 site often use the same tools. The difference is how many decisions were made deliberately rather than by default, and how much thought went into the parts a visitor never consciously notices.

The number that surprises people is the second one. Websites are not finished objects. Prices change, a service gets added, a photo needs replacing, and every one of those is either an email to somebody with an hourly rate or a retainer of $50 to $300 a month. Over three years the maintenance often costs more than the build.

That second number is the real argument for doing the first version yourself. Not to save the build fee, which is a one-off, but so that changing your own opening hours on a Tuesday evening is a thing you do rather than a thing you request.

Not until you have run out of things you can fix yourself, and most small businesses have not. A competent SEO consultant charges $500 to $2,500 a month and earns it on sites that already have traffic to improve. On a site with no traffic yet, most of the first three months will be spent doing things you could have done in an afternoon.

The things that move a small local business are unglamorous and largely free. A page title that says what you do and where you do it. A description under 155 characters. A Google Business Profile that is filled in properly and has recent photographs. Consistent name, address and phone number wherever you appear. A page that loads in under two seconds. That list is most of local SEO, and none of it needs a retainer.

Hiring makes sense in three situations. You are in a genuinely competitive market where everyone has already done the basics. Your traffic dropped and you do not know why, which is a diagnostic job and worth paying for. Or your time is worth more per hour than theirs, which is a perfectly good reason and the one nobody says out loud.

Be suspicious of anyone who guarantees a position. Nobody controls Google's results, and the people who claim to are describing a service they cannot deliver.

Expect $500 to $2,500 a month for an ongoing retainer, $1,000 to $5,000 for a one-off audit, and $75 to $200 an hour for consulting. Agencies at the top of that range are usually pricing for competitive national markets, not for a plumber in a town of forty thousand people.

The pricing model matters more than the number. A retainer buys ongoing work and makes sense once there is ongoing work to do. An audit buys a document, and a good audit document is worth having, because it is a list you can work through yourself over six weekends. Hourly consulting is the cheapest way to buy the thing you actually want, which is usually forty minutes of someone experienced telling you which three of your twenty problems matter.

Be careful with anything priced per link or per article. Cheap links are the fastest way to acquire a penalty, and cheap articles are the fastest way to acquire forty pages nobody reads. Volume pricing exists because volume is easy to sell, not because volume works.

One honest observation. If a quote is under $300 a month, the work is almost certainly automated, and the automated work is the work you can do yourself for nothing in an afternoon with a checklist.

Build the first version yourself, then hire from a position of knowing what you want. This is not a compromise answer. It is the order that produces the best result for the least money, and the reason has nothing to do with saving the build fee.

The expensive part of hiring is not the invoice, it is the brief. Most bad website projects fail because the person paying could not describe what they wanted, so they described what they had seen, and the developer built that instead. Three rounds of revisions later everyone is tired and the site is a compromise nobody chose.

Building the first version changes that completely. You find out that the booking form is the only part anyone uses. You find out your prices need updating twice a month and that matters more than the hero image. You find out you do not need the blog. Those discoveries cost you a weekend and they are the difference between a $3,000 brief and a $12,000 one.

Hire when the thing you need is genuinely outside what you can describe: a custom booking system with staff calendars, an integration with software you already pay for, an accessibility audit for a legal requirement. Do not hire because the site needs to exist. The site existing is now an afternoon.

A useful test: if you can write down what every page does and what every button does, in plain sentences, you are ready to hire and will get good value. If you cannot, hiring will cost you roughly double and you will get something you did not want, through nobody's fault.

The questions worth asking are about ownership, maintenance and exit, not about design. Design you can judge by looking at their previous work. The other three are where projects go wrong, and they are exactly the questions nervous clients avoid.

Ask these, in this order:

• Who owns the domain, and whose name is on the registration? It should be yours, on your account, on your card. This is the single most common way people lose control of their own business name.
• Where will the site be hosted, and whose account is it under? Same reason.
• What can I change myself without calling you? Get specifics. Prices, opening hours and photographs should all be on that list.
• What happens if I want to move to someone else? A good answer is a shrug and a handover. A bad answer is vague.
• Is this built on something standard, or something of your own? Custom systems are fine until the person who wrote it stops answering email.
• What does year two cost? Get the hosting, maintenance and support numbers in writing before you sign anything.
• Can I see a site you built three years ago that is still running? Portfolios show launch day. This shows what happens after.

You will notice that none of these are technical. You do not need to evaluate their code. You need to establish that when this relationship ends, and every relationship ends, you walk away with your own business.

Ask what they will actually do this month, and ask to see the same answer for another client. Vagueness is the tell. Real SEO work is boring and specific and easy to describe, so anyone who cannot describe it is selling you a dashboard.

• What are the first five things you would change on my site? A competent answer arrives within a day and is specific. A bad answer is a proposal deck.
• How do you measure success, and over what period? Rankings alone are a vanity answer. Enquiries and calls are the real one.
• Do you build links, and if so, from where? If the answer is a network, a package, or a number per month, walk away.
• Who writes the content, and do they know my industry? Generated filler is worse than no content, because now you have forty pages diluting the four that matter.
• What access do you need, and what will you change without asking? Get this in writing. People have had their sites restructured overnight.
• What happens to the work if I leave? Content and structure should stay yours. Rented links vanish and take your rankings with them.
• Can I talk to a client you fired, or who fired you? Nobody asks this. The reaction tells you more than the reference would.

One more thing. Ask them to explain what they would do in language you understand. Anyone genuinely good at this can, and the ones who hide behind vocabulary are usually hiding something less interesting than you would think.

For an author site the honest ranking is: a single page you control, then Ghost, then Squarespace, then WordPress, and website builders aimed specifically at authors are usually the worst value on the list. An author site has an unusual shape. It needs to do four things, it needs to do them for a decade, and it needs to cost almost nothing between books.

The four things: who you are, what you have written, where to buy it, and how to reach you. That is a page. Occasionally two. The reason author platforms disappoint is that they are priced for a content operation and you are running a business card that gets updated every eighteen months.

The argument for the first row is not the price, it is the decade. Author sites outlive platforms. Every writer who has been publishing for fifteen years has migrated at least twice, usually in a panic, usually losing the URLs that other people linked to. A plain page on your own domain does not have that failure mode, because there is no company in the middle of it to change its pricing or close.

Add the mailing list the day you launch, whatever else you decide. It is the only asset in publishing that no platform can take back.

Yes, and for a reason that has nothing to do with people browsing it. Almost nobody finds a plumber by reading their website. They find you in Google Maps, or on a recommendation, and then they check your website to decide whether you are real.

That check takes about four seconds and it is a trust test. A site with your actual phone number, your actual hours, your prices and a photograph of your actual van passes it. A Facebook page with the last post from 2023 fails it. Not because Facebook is bad, but because it signals that the business may not still exist.

There is a second reason, and it is the one that quietly matters more. Your Google Business Profile, your social pages and the directory listings are all rented. Rules change, accounts get suspended by an automated system on a Tuesday for a reason nobody explains, and the appeal takes eleven days. The website is the one place a customer can always reach you, and it is the address you put on the van.

What you need is genuinely small. One page. What you do, where you do it, what it costs roughly, how to reach you, and hours. No blog. No portfolio carousel. A phone number that is a tappable link on a phone, which is a detail that converts better than any design decision on the page.

For local search, your Google Business Profile does most of the work and your website confirms it. The map results that appear above everything else are drawn from Business Profiles, not from websites, which is why a beautiful site can sit invisible while a competitor with no site at all takes the calls.

The order that works, and it is short:

• Claim and complete the Business Profile. Every field. Hours, service area, categories, a description, and at least ten real photographs taken on a phone. Completeness is a ranking factor and most profiles are half empty.
• Get reviews, steadily. Ask every satisfied customer, by text, with the link. Twenty reviews spread over a year beats forty in one week, which looks purchased because it usually is.
• Make your name, address and phone number identical everywhere. Website, profile, Facebook, directories. Street versus St is enough to cause a mismatch.
• Put the town in your page title. Emergency Plumber in Norwich beats Welcome to Our Website, which is still, remarkably, the title of thousands of live pages.
• Add a page per service if you offer several. One page for boiler repair, one for bathroom fitting. Google matches pages to questions, not businesses to questions.
• Make it fast and make it work on a phone. Most local searches happen on a phone, frequently by someone standing next to a problem.

None of that requires a specialist and all of it is a weekend. The results take six to twelve weeks, which is the genuinely difficult part, because nothing appears to happen for a month and the temptation to change everything is enormous.

Google Business Profile first, by about a week, then the website. The profile is free, takes an hour, and is what actually surfaces you in local searches. If you are choosing what to do this evening, do that.

But the answer changes at the point where you notice the profile has a field for a website URL, and that businesses with one get more clicks than businesses without. The two are not alternatives. The profile gets you seen and the website gets you believed.

There is also a limit to the profile that arrives sooner than people expect. You cannot explain a complicated service in it. You cannot set out pricing properly. You cannot take a booking on your own terms. And you do not control it, which is fine right up until the morning it is suspended and you discover the entire business ran through a page you were borrowing.

The practical sequence: profile on Monday, one-page site by the weekend, put the site link in the profile, then spend the following three months collecting reviews rather than redesigning anything. That order matches how the customer actually moves, which is search, glance, phone.

Because nothing links to it and nobody knows it exists, and both of those are normal for a site under three months old. A new website is not a shop on a high street. It is a shop in a field, and the field is large.

Three things are usually true at once. Google has not indexed it yet, which takes days to weeks and can be nudged by submitting a sitemap in Search Console. Nothing anywhere else links to it, so there is no path to the field. And you have not told anyone, because telling people feels like bragging and building felt like progress.

The third one is the actual problem and it is the one nobody wants to hear. Most people who build a first website tell nobody about it, wait, and conclude the website failed. It did not fail. It was never shown to anyone.

The fix is unromantic. Send it to ten people individually, not as a post. Put it in every profile, every email signature, every invoice and the side of the van. Submit it to Search Console. Answer three questions somewhere your customers already are, with your site as the place that explains more. That is a week of work and it will beat six months of adjusting the spacing.

You can build the product. Whether you can run it as a business is a different question, and it is the one that decides this. The software is now the easy part, which is genuinely new and still surprises people who last looked at this five years ago.

A working SaaS is four things: a page that explains it, a login, somewhere to keep the data, and a way to charge. Every one of those is a solved problem with a service behind it, and an AI will assemble a working version of all four in a weekend. That is not a toy. People are charging money for exactly that.

Here is the part nobody puts in the launch post. The moment you hold other people's data and take their money, a set of obligations arrives whether or not you know the vocabulary. A database left on its default settings is readable by anyone who finds the address. An API key in the wrong file is spendable by anyone who opens the browser tools. Neither produces an error message. Both work perfectly, including for people who are not you.

The realistic failure mode is not that the code is bad. It is support. Customers email at inconvenient times, expect answers, and want their password reset at 11pm on a Sunday. Ten paying customers is a real obligation, and it arrives long before the revenue is interesting. Most abandoned solo SaaS projects died of that rather than of a technical problem.

So the honest answer is yes, with one condition. Learn what happens to data and keys before you accept your first customer, not after. That is an evening of reading, and it is the difference between a small business and an apology email to everyone who trusted you.

A clickable prototype in an afternoon, something real people can use in a week or two of evenings, and a product you would charge for in about a month. Those numbers are real, and the gap between the first and the last is where most of the surprise lives.

The first version is genuinely fast, and that speed is not an illusion. Describe what you want, get a working page, put it online. Twenty minutes to a draft, another hour to make it yours. If you have watched someone demo this and thought it looked too quick to be true, it was not. That part is exactly as fast as it appears.

What the demo leaves out is that the last ten percent takes as long as the first ninety. The AI produces the happy path, where the user does the expected thing in the expected order. Real users do not. They submit the form empty, arrive on a phone in landscape, paste an emoji into the name field, lose signal halfway through the payment, and hit back at the worst possible moment. Every one of those is a small fix, and there are more of them than anyone expects.

Two things reliably destroy the estimate, and neither is coding. The first is waiting on something outside your control, usually a domain propagating or a payment account being verified, which is hours to days and no amount of skill speeds it up. The second is being stuck without knowing the name of what you are stuck on, which turns a ten-minute problem into a lost Saturday. That second one is the entire reason to read something short and specific before you start rather than after you are stuck.

Not under that job title, and yes in practice. No company is advertising for a vibe coder, and if one did you should probably examine it closely. But people are being hired, right now, on the strength of things they built with AI assistance and could not have built two years ago, and nobody in the interview asks how the first draft was written.

The distinction that matters is between building and shipping. A generated prototype is worth very little in a hiring conversation, because everyone in the room can generate one. A thing that is live, that handles real users, that has not leaked anything, and that you can explain the failure modes of, is worth a great deal, because it demonstrates the judgement that AI does not supply.

Where this genuinely converts to work: small companies and agencies who need someone able to turn a request into a working page by Thursday. Internal tools nobody has time to build. Contract work in the two to eight thousand dollar band, where the client wants the problem gone rather than an architecture. Marketing roles where being able to ship a landing page yourself makes you twice as useful as the person who files a ticket for it.

Where it does not: anything advertised as a software engineering role at a company with a real interview process. Those still test data structures, systems design and the ability to work in a codebase you did not write. That is a different job and it always was.

The unglamorous truth is that the portfolio does the hiring. Three live things you can talk about honestly, including what broke, will beat a certificate every time.

It is a legitimate capability and a shaky job title. The skill of describing a problem precisely enough for a machine to solve it, then checking the result properly, is real and increasingly valuable. Building a career identity around the current name for it is riskier, because the name is about eighteen months old and industry vocabulary moves faster than that.

The historical rhyme is worth noticing. In 1996 people described themselves as webmasters and it was a real job with a real salary. The work did not disappear. It split into six specialisms and the word became slightly embarrassing. The people who did well were the ones who kept learning the thing under the label.

What holds its value regardless of vocabulary: knowing what happens when a thousand people arrive at once, knowing what should never be in a browser, knowing what to do when something breaks at three in the morning, and knowing when the correct answer is that this needs an actual engineer. None of that is generated for you, and all of it is learnable in the order these books are in.

The honest risk is a ceiling. There is a level of problem where the bottleneck stops being the writing and starts being the understanding, and no amount of prompting gets you past it. Plenty of good careers sit below that ceiling and always have. Just do not let anyone tell you the ceiling is not there.

Companies want the problem gone, and they have never once cared how. The framing of the question is a developer framing. A business owner with a broken booking form wants a working booking form by Friday.

Where it stops being true is maintenance. The reason companies employ engineers is not that code is hard to write. It is that code is hard to keep working for four years while six people change it and the requirements shift underneath. That is the actual product of a traditional developer and it is not what AI is currently good at.

So the split, in practice: for anything self-contained, short-lived or urgent, speed wins and the tooling does not matter. For anything that has to survive being handed to someone else, or that holds other people's money or data, employers want someone who can explain why every decision was made. Those are different jobs and both are real.

The most employable position right now is neither end. It is the person who can move fast with AI and knows precisely where their own understanding stops. That person gets a working thing out on Tuesday and says, clearly, that the payment flow needs review by someone who has done it before. That combination is rarer than either extreme and companies notice it immediately.

Companies hire the outcome, and they are hiring it constantly. Nobody posts a role called vibe coder, so searching for that job title returns nothing and people conclude the market does not exist. It does. It is listed under other names.

The titles that describe this work in practice are things like marketing engineer, growth engineer, technical marketer, founding designer, solutions engineer, automation specialist, and the enormous unglamorous category of internal tools. All of those are real postings with real salaries, and all of them are fundamentally about turning a request into a working thing quickly. How you produced the first draft is not a question anyone asks.

Who hires for it splits fairly cleanly. Small companies and agencies hire it because they need a landing page by Thursday and cannot justify an engineer. Marketing teams inside larger companies hire it because filing a ticket with engineering takes three weeks for something worth two hours. Founders hire it early because someone has to build the thing before there is a team. Contract work in the two to eight thousand dollar band is steady, because the client wants the problem gone and does not care about the architecture.

Where it does not work is any company with a structured engineering interview. Those still test data structures, systems design and reading a codebase you did not write, and no amount of shipping gets you through them. That is a different job, it always was, and it is not a judgement on either one.

The practical route in is not a certificate and not the phrase on your CV. It is three live things you can send a link to and talk about honestly, including what broke and what you would do differently. That is a stronger application than most degrees, and it is the one thing the tooling cannot generate for you.

No, and the honest version of that answer is more interesting than the marketing version. You do not need to write the code. You do need to understand what it is doing, because that is what stands between a page that works and a page that leaks your customers' phone numbers.

What you actually need is closer to being able to read a recipe than to being able to cook. You need to know that a website is a file, that a domain is a name pointing at a computer, that some things are safe in a browser and some are absolutely not, and what to do when something goes red. Each of those is one concept and none of them takes an evening.

The failure mode is not that people cannot write code. It is that they ship something working without ever being told which parts were dangerous, because the machine that wrote it was not asked and does not volunteer. Nobody asks whether row level security is on, because nobody has ever heard the phrase.

So: no code, yes vocabulary. The vocabulary is small, and it is most of the difference between a hobby and a business.

Because it is not on the internet yet. It is a file on your machine, and your browser is opening it directly. Look at the address bar: if it starts with the word file rather than https, nobody else on earth can see that page, including you on your phone.

This catches almost everyone once, and it is not a mistake so much as a missing step. Making the file and publishing the file are two separate jobs, and AI tools do the first one so quickly that people assume the second one happened too.

Publishing means putting a copy of your file on a computer that never turns off. On modern hosts that is a drag and drop and takes under a minute. You get back an address starting with https, and that address works from anywhere.

The related surprise arrives immediately afterwards: changing the file on your computer does not change the live site. You published a copy. Until you set up automatic updating, every change means publishing again. Mildly annoying, and knowing it in advance saves an hour of refreshing a page that was never going to change.

The code is usually fine. The configuration around it is where things go wrong, and AI will not raise it unless you ask. A generated single page with no database and no login is about as risky as a printed leaflet.

Risk arrives with three specific features, and it arrives quietly. The moment you add a database, the default settings on most services allow anyone who finds the address to read everything in it. The moment you add a key for any paid service, it can end up in a file the browser downloads, where anyone can read it and spend your money. The moment you add logins, you are storing other people's information and a different set of rules applies to you.

None of those are hard to secure. Each is a setting, or a short list of settings, and each takes under an hour once someone has told you it exists. The danger is not difficulty, it is silence. There is no error message for a public database. It works perfectly. It just also works perfectly for everyone else.

So the practical rule: a page that only shows things, publish it today without a second thought. Anything that stores or charges, learn the three settings first. It is one evening and it is the difference between a website and an incident.

An afternoon for a page that is live on your own domain, and about four evenings for something that stores information and takes payments. That is not an optimistic estimate, it is what the steps add up to when nobody is stuck.

Roughly: twenty minutes to get a first version out of an AI, ten to save it and look at it, ten to publish it, and thirty to buy a domain and point it. Then a variable stretch of waiting for the domain to start working, which is between four minutes and a few hours and is entirely out of your hands.

The rest of the afternoon goes on the words. It always does. The layout arrives finished and the sentences do not, and rewriting your own about section takes longer than everything technical put together.

What turns an afternoon into three weeks is getting stuck without knowing the name of the thing you are stuck on. That is the entire reason these books are short and specific rather than comprehensive. Being told in advance that your computer hides file extensions is worth more than forty pages on the history of HTML.