The person who estimates it is the person who builds it

Before any number is agreed I read what you already have — the codebase, the data, the integrations, the things that will fight us. Where there is nothing yet, this is instead about what the site has to do and who it has to do it for. It is short, it is paid, and it is the difference between a quote and a guess.

If you have a designer, I work with them and flag early where something will be expensive to build or awkward on mobile — while it is still cheap to change. If you do not, I will bring one in rather than pretend I am one. What I will not do is invent a design and hope you like it.

How the data is shaped, where things live, what is a post and what belongs in its own table, which integrations run on a schedule and which fire on an event. Plus what the site should be hosted on and roughly what that costs to run. Decided before building, because these are the choices that are expensive to reverse.

Once the architecture is clear I can say which parts of your list are cheap, which are expensive, and which are expensive for reasons you might not expect. You decide what stays. I would rather cut scope early than discover the money has gone on something you cared about less.

Design to markup — Figma or PSD into semantic HTML and CSS that matches the intent rather than approximating it. Responsive properly, accessible by default, fast because of how it is built rather than because a plugin was added afterwards.

Templates, custom blocks, the data model, the admin your editors will actually live in, business logic, and the integrations. This is the longest phase and the one where being the same person who did the front end pays for itself, because there is no interface between us to get wrong.

Functional testing across browsers and devices, the edge cases in whatever handles money, and load where volume matters. Then a staging environment where the people who will use it every day try to break it — which they will, in ways I would not have thought of.

Server configured, caching layers set up, cron running properly, SSL, redirects mapped if there is an old site, and a rollback that exists before it is needed. Launches planned around your trading rather than around my calendar.

Written throughout, not assembled at the end. How it is put together, why the awkward decisions were made, how to deploy it, and what to be careful with. Enough that another developer can pick it up — which is the only real test of whether a build was done properly.

Some clients take it in-house, some keep me on a retainer, some call once a year. All three are fine, and the build is done the same way regardless — I am not going to make it hard to leave.