There is a plain text file on my computer that my coding assistant reads before it touches anything. It is the nearest thing my studio has to a manual, and it is short. A few of the lines in it, lightly translated:
- Every new site is multi-page: one indexable page per service or topic, never a single landing page with anchor links.
- Every one of those pages gets its own title, meta description, H1, clean URL and sitemap entry, plus a canonical tag, Open Graph tags and structured data.
- If the brief is vague, research two or three well-regarded brands in the same sector in the US before designing anything, and base the structure and the level of finish on them.
- Never carry text, images, styles or contact details from one project into another, however reusable they look.
- Each page gets its own photo, never repeated, and the business’s real photos come before stock.
- No emoji in any interface.
- Build deployment ZIPs for Netlify with tar, never with PowerShell’s Compress-Archive, which breaks the stylesheet paths once deployed.
None of those came from the model. Each one is a decision I made once so I wouldn’t have to make it again in every session, and together they are the most honest answer I have to the question in the title. AI changes how fast a site gets built. It doesn’t change who decides what gets built, and most of this job is deciding.
The part that got cheap
The first complete version of a site is no longer the expensive part. A multi-page build with the technical SEO already wired in, the sitemap, canonical tags, Open Graph and structured data, used to be days of careful and boring work. With a rules file and a coding assistant it is the quick part of the job. The same goes for refactors and repetitive changes: I have edited a hundred WordPress posts in one pass through the REST API, which is not something I would ever have attempted by hand.
My public price list promises delivery in one to three weeks, depending on the package. The build is no longer what decides where in that range a job lands. The material is: the photos, the list of services, the opening hours, the honest answer to “what makes you different from the place down the road”. No model can produce those, and a model that is asked to will produce plausible ones, which is worse than none.
What didn’t get cheaper is everything on either side of the build. That is where the rest of this post spends its time.
What I need to know before I can give a price
A quote is only as good as the scope behind it, and the scope comes out of a conversation that nobody can have for you. These are the things I pin down first:
- What the business actually sells, service by service. Each service gets its own page, so this is also the page count.
- Where it works. A business that serves several towns may need a page for some of them, and that changes the size of the job.
- Who supplies the photos. Real ones beat stock, and “we’ll send them later” is how a two-week job becomes a two-month one.
- How people should get in touch. A phone number, a form, WhatsApp, or all three.
- Who owns the domain and the hosting. The client does, paid directly to the provider, from the first day. I don’t want to be the reason someone cannot move their own site.
- The identifying details for the legal notice, which in Spain has to exist. More on that below.
- What happens after launch. Either nothing, or an optional maintenance plan. Both are fine, as long as it’s decided before rather than after.
Why I quote a package and not the hours
My prices are fixed and paid once: half at the start, half on delivery, with monthly maintenance as a separate and optional extra. The packages are defined by what you get, a one-page site, a multi-page site up to a set number of pages, or an online shop, and not by how long it takes me. I’m not reprinting the figures here, because the price list is being reworked as I write this and a number on this page would be out of date within weeks.
Hourly pricing makes no sense once a model can write the boilerplate in minutes. Billing by the hour either punishes me for using the tool or tempts me to pretend I didn’t, and neither is a good basis for working with someone. A package says: this is what you get, this is what it costs, and how I produce it is my problem.
The catch is that a fixed price only works if the scope is written down. “Six pages” has to mean six named pages, and “a few changes” has to mean a stated number of rounds. The model is no help there at all. That sentence in the proposal is worth more than any prompt.
Telling the buyer I use AI
I say it up front, in the proposal and not in the small print. People are going to wonder anyway, and it is a much better conversation when they don’t have to ask. I also say what it is for: writing and refactoring code, first drafts of the base texts, which I then rewrite with the owner’s real information, and research. And what it is not for: making the decisions, signing off the work, or handling their customers’ data.
Saying it out loud also moves the conversation to the right place. Nobody should be paying me for typing. They are paying for the decisions, for the checking, and for a person who answers when the contact form stops working. Where exactly that line sits, and how I price the checking, is in using AI in paid work without selling raw AI output.
The pages I owe every site, in Spain
This is the section I would most like someone to have handed me on day one. For a business site in Spain, these are not optional extras:
- A legal notice. Article 10 of Spain’s e-commerce law, the LSSI-CE, requires the provider to make its name, address, email address and tax identification number permanently and freely accessible, along with registry details where they apply.
- A privacy policy that tells people what the site collects, why, on what legal basis, for how long and what their rights are, as Article 13 of the GDPR requires.
- A cookie policy, and a consent banner if the site uses anything beyond strictly necessary cookies. Article 22.2 of the LSSI-CE requires consent, and the Spanish data protection authority’s cookie guide (updated May 2024) is specific: the option to reject has to be offered in the same layer and at the same level as the option to accept.
- Accessibility, depending on the business. The European Accessibility Act has applied since 28 June 2025 to certain services, e-commerce among them, and exempts microenterprises that provide services. For an online shop I check which side of that line the business falls on rather than assuming.
All four sources were read on 21 September 2026. If you work in the UK or the US, equivalents exist but they are different laws, and I only know the Spanish and EU side from doing it. I’m not a lawyer, and when a case isn’t obvious it goes to someone who is.
The site I was slowest to fix was my own. The legal pages for my studio’s website were written and sitting in a folder on my desktop while the live site linked to none of them. I had reasons, mostly a reluctance to publish my own details, and none of them were good ones. If you are starting out, do your own site’s legal pages before anyone else’s. It is the page a careful buyer checks, and it is the one you are least likely to be reminded about.
Four things the model doesn’t get to decide
Anything involving customers’ data. I don’t paste anyone’s personal data into a prompt: not a customer list, not form submissions, not an email thread. If a task needs real data, I do it by hand, or I give the model made-up data of the same shape.
Legal text. A model can lay out a privacy policy in seconds. It cannot know what the site actually collects, which third parties load on the page, or whether the contact form stores anything. Every legal page is checked line by line against the site as built, and the identifying details come from the owner, confirmed in writing.
Design direction. The model proposes and I choose. When a brief is thin, the references come from the research step in my rules file, not from whatever the model considers a typical site for that trade, which is how every plumber ends up with the same blue hero image.
Whether it’s finished. The last pass is mine: every page on a phone, every link and form tested, and a deliberate hunt for leftovers. That hunt exists for a reason. In September I found a tracking snippet on my own studio site still carrying a placeholder where the real ID should have been. Nothing broke, and nothing was tracked either, for weeks. How I review generated code in general is in my notes on the coding assistant I use every day, and where the tool itself goes wrong is in my review of Claude after building sites with it.
After launch, the routine is the same everywhere
Every site I put live goes through the same short routine in Search Console: submit the sitemap as a full URL, delete any old or broken sitemap left over from a previous version of the site, request indexing for the pages that matter, and read robots.txt as if a stranger wrote it. It is written out step by step in the checklist I run after every launch. The unglamorous operational side, renewals, certificates and where each of my own sites lives, is in my working setup.
What AI did nothing for
Finding the next buyer. Nothing in my toolchain does that, and nothing I have tried makes it faster. The build got cheaper; the conversation with a business owner who has never heard of you costs exactly what it did before. That part of the job is what I am spending my time on now, in person, with most of my side projects paused so there is room for it.
If you are thinking of starting a studio like this because AI makes the building easy, that is the part to plan for. The building was never really the constraint.
A note on this page: the previous version was a numbered “step-by-step guide” that jumped from Step 1 to Step 3, had an empty list under its main claim, and quoted monthly income figures I could not support. Nobody noticed, including me, which is its own small argument for the last of the four things above. It has been replaced in full.