What website development involves

Website development is the work of turning a decision about what a site should do into something that runs, loads and can be changed later. The building part is usually the smallest piece of it.

This is written for someone commissioning a first build, so it covers where the money goes as well as what happens.

The parts

Front end is what loads in the browser. HTML for the structure, CSS for the appearance, JavaScript for behaviour. Everything the reader sees and touches.

Back end is what runs on a server. Handling a form submission, storing an order, checking a password, talking to another system. A site with no accounts and no transactions may need very little of this.

Content management is how someone who is not a developer changes the words. That can be a traditional CMS, a headless one, or files in a repository. The right answer depends entirely on who edits and how often.

Infrastructure is where it runs, how it is deployed, how it is backed up and what happens when it breaks at 2am.

The decision that shapes the cost

The single biggest cost driver is whether pages are built once or built per request.

A static site builds every page ahead of time and serves files. It is fast, it is close to unbreakable, it survives traffic spikes, and there is no database to be compromised. For a marketing site, documentation, or anything where the content changes a few times a day, this is usually the right answer.

A dynamic site builds pages when they are asked for. You need it when the page differs per user, when there is a live inventory, or when the content changes by the second.

A lot of expensive builds are dynamic sites for content that changes weekly. The cost shows up later, in hosting, in security patching and in the performance work needed to make a database-backed page load quickly.

What a build actually goes through

Working out what the site is for and who it is for. This is where a bad build goes wrong, and no amount of later engineering fixes a site with no clear job.

Structuring the content. What pages exist, what each one is for, what links to what. Design without this is decoration.

Design. What it looks like and how it behaves, including on a phone and for someone using a keyboard or a screen reader.

Build. The part people picture when they say development, typically a third of the time or less.

Content. Almost always the thing that delays a launch. Start it early.

Testing and launch. Across browsers, on real devices, including a check that the forms actually deliver to a real inbox.

Then maintenance, which is not optional. It is what separates a site still working in three years from one replaced in eighteen months.

Questions worth asking anyone quoting

Who owns the code and the domain when we are done. The answer should be you.

What happens when I want to change a page. If the answer is “raise a ticket”, price that in.

What is the hosting cost and what is the yearly maintenance cost. A build price with no running cost attached is an incomplete quote.

How fast will it load and how are you measuring that. A vague answer here predicts a slow site.

What happens if it breaks. Backups, restore time, who is on the end of the phone.

The part that gets skipped

Accessibility. Contrast, keyboard operation, form labels, headings in order. It is cheap to build in and expensive to retrofit, and in several jurisdictions it is a legal requirement and not a preference.

Ask for it explicitly, because a quote that does not mention it has not costed it.

If you want a site built this way, that is what we do. We will tell you when a static build is enough, and not sell you an application.