The money question is not whether to use AI or hire a developer. It is which parts of your website are commodity and which are genuinely yours, because you should be paying for exactly one of those.
Most of a business website is commodity. Not in a dismissive sense. In the sense that a services page, a responsive grid, a contact form and a sitemap have been built countless times, work the same way for a dentist and a law firm, and contain nothing that distinguishes your business from anyone else's.
Paying by the hour to have that part built again is where website budgets go. Not on the hard part. On the part that was already solved.
What a business website is actually made of#
Three layers, and they behave completely differently on a budget.
| Layer | What it is | What it should cost |
|---|---|---|
| The shell | Structure, layout, navigation, responsive behaviour, metadata, forms, the blog | Close to nothing. It is standardised. |
| The content | What your pages actually say about your business | Your time, mostly. AI drafts, you correct. |
| The logic | Anything driven by how your company operates | Real money, and worth it. |
Almost every unhappy website invoice comes from paying layer-three prices for layer-one work. The rest of this is about telling them apart.
The foundation AI generates#
"Foundation" is vague, so here is what it means concretely. From a description of your business, a generator produces the pages a business of that type needs, a layout for each, first-draft copy in every section, and the components those sections are made of.
- Pages. Home, services, about, contact, and one page per service rather than a single list. Knowing which pages a trade needs is well-trodden ground, and it is the part people most often get wrong on their own.
- Layouts. Section order, hierarchy, where the call to action sits. This is convention rather than invention, which is exactly why a model is good at it.
- Content. A real first draft in every section, in your language, about your trade. Not lorem ipsum, which is the thing that stalls most website projects for a month.
- Components. Cards, pricing tables, testimonial blocks, galleries, headers and footers. Assembled, styled and consistent with each other.
What comes out is a first version, not a finished site. The copy needs your facts, the claims need checking, and the photographs of your actual work are yours to supply. But you are editing something rather than commissioning it, and that changes what the whole project costs.
What you should never pay to have built from scratch#
This is the list worth reading twice, because each item is a solved problem where a hand-built version is usually worse than the standard one, not better.
- Responsive layout. Making a page work on a phone stopped being a project years ago. It is the default behaviour of every current framework and theme.
- A contact form. Fields, validation, spam handling, a notification email. Every one of those is standard, and a custom form usually means a custom bug.
- SEO plumbing. Titles, meta descriptions, canonical tags, sitemap, robots.txt, structured data. Mechanical, and mechanical is the cheapest thing in the world to automate.
- A blog. Posts, categories, tags, archives, RSS, an editor. WordPress has done this since 2003 and the version you would commission will do less.
- Image handling. Resizing, modern formats, lazy loading, art direction on small screens. Solved, standardised, and easy to get subtly wrong by hand.
- Accounts and roles. Login, password reset, permissions. This one is also a security surface, which is the strongest possible argument for not writing your own.
- A cookie banner. Consent storage, categories, the ability to withdraw. There are correct implementations to install; there is no prize for a bespoke one.
Ask whether another business in a different industry would want the same thing, built the same way. If yes, it is commodity, and paying to have it made from scratch buys you a private version of something public, with nobody else fixing its bugs. If no, it is probably yours, and worth real money.
What is worth paying a developer for#
A guide about saving money on development that never says what to spend it on is just a sales pitch with a table of contents. So, plainly: some things no generator finishes, and they are worth paying for properly.
The line is not difficulty. It is whether the requirements come from how your company operates. A booking system with real staff availability, deposits and cancellation rules. Membership tiers with gated content and renewals. A marketplace with several sellers. An integration with the system you already run your business on.
Those are not content problems, and they exist nowhere in any training data, because they are specific to you. If your project is on that list, no generator finishes it, and that is a statement about the category rather than a criticism of the tools.
When the generated site is enough#
For a large share of businesses it simply is, and the honest test is short. If your website's job is to explain what you do, look current, be findable, and make it easy to contact you, then it is a content and design problem, and those are the problems AI handles.
A visitor does not evaluate how your site was built. They evaluate whether it loads fast, looks current, says something specific, and makes the next step obvious. We went through where that holds and where it stops in an honest look at whether AI can build a professional website, and the mechanics of getting there in the step-by-step build guide.
The mindset that actually saves money#
The saving does not come from refusing to hire anyone. It comes from changing what you hand them.
A developer starting from a blank repository and a written brief has to invent the structure, wait for your copy, guess at the design, and build the entire commodity layer before touching the part you are actually paying for. Most of that invoice is layer one.
A developer starting from a working site with real content and real structure begins at the part that needs them. There is nothing to specify about the shell, because it exists and everyone can see it. The brief stops being a document and becomes a URL, and the disagreement about what was meant, which is where fixed-price projects usually go wrong, mostly disappears.
Generate first, run the business on the site, and add the custom piece when you actually need it. Paying for it up front means paying against a guess about what customers will want, made before you had any customers on the site to observe. The commonest expensive mistake in website projects is not hiring a developer. It is hiring one too early, for a specification nobody could have written yet.
One condition makes this sequence work, and it is worth checking before you start: the generated site has to be something a developer can extend later. A real WordPress installation can be, by any WordPress developer, with ordinary plugins and themes. A site locked inside a closed builder cannot, and outgrowing it means rebuilding elsewhere, which converts the money you saved into money you spend twice. We compared the two routes here.
Start from a working site, not a blank page
Describe what you do and Sitebefy builds a real WordPress site you own, with the pages, layouts, content and SEO already in place, and a developer can extend it later like any WordPress site. Look at the result before creating an account, and every plan carries a 14-day money-back guarantee.
Build my siteQuestions to ask before you approve a quote#
Five questions, in order. They are not adversarial; a good developer will answer them happily, and the answers are where the number in the quote comes from.
- Which line items are commodity? Ask for the quote split into the shell, the content and the business logic. A quote that cannot be split is a quote you cannot evaluate.
- What is being built rather than installed? For each of those, ask why the standard option does not fit. Sometimes there is a real answer. Often the question has not been asked.
- What happens to this if I leave? Ask what you own, what exports, and what stops working. Custom code you cannot take with you is rent, not an asset.
- Can this wait? For every piece of custom work, ask what breaks if it ships three months later. Anything that survives that question can wait until you have real usage to design against.
- Who maintains it? Bespoke code needs someone when WordPress or PHP updates. The standard version has a maintainer already, and that is a running cost you are choosing to take on.
Question four is the one that saves the most, and it is the one nobody asks.
What this adds up to#
Generate the commodity layer, because it is commodity and it is nearly free now. Spend your own time on the content, because only you know whether it is true. Pay a developer for the part that comes from how your business actually works, and pay them after you have a site running rather than before, so they are solving a problem you have observed instead of one you predicted.
That is the whole method. It does not require choosing a side in an argument about whether AI replaces developers, which is fortunate, because the answer to that question has never once helped anyone decide what to do on a Tuesday with a real budget and a real business.
