Web Development

It depends on whether the site has to do anything beyond present information. A brochure site of a few pages is a small piece of work. A site with a booking flow, a quote calculator or a product list pulled from your stock system is a build, and the price follows the number of those things and how much they have to talk to systems you already run. We scope in writing before anything starts, so the number you get is against a list you can read rather than a guess.

The honest answer is that the build is rarely what sets the date. A straightforward marketing site is a matter of weeks once the content exists, and the content is usually what it waits on: photography, product copy, and the sign off of people who are busy doing their actual jobs. An application with integrations runs longer because each system it talks to has its own access, its own quirks and its own owner to get time from. We give you a date against a written scope, and we tell you which parts of it depend on you rather than on us.

You do, from the first day rather than at handover. Every domain, DNS record, hosting account and code repository we set up goes in your name and your billing details. We are added as a user to accounts you own. It matters more than it sounds: the most common reason a business cannot move its own website is that a previous agency registered everything in its own name and treats the code as its property.

That is the point of the content model we build. Your marketing team gets reusable blocks, a preview of the change before it goes live, and a revision history to undo it. Price changes, new pages, a swapped photograph and a new blog post are all editing jobs, not tickets. What still needs a developer is a new kind of page or a new integration, which is the correct line to draw.

It keeps them if the redirects are right, and loses them quietly if they are not. Before launch we take the real URL list from the current site and the search console data, map every old URL to its closest new one, and test that map against the live addresses rather than against a spreadsheet. Titles and descriptions come off the content rather than being retyped, and we watch search console through the first weeks after launch to fix what real traffic exposes.

Yes, and it is usually the cheaper path. If you have a brand guide, a design system or even a set of recent artwork, we build to it and tell you where it does not survive contact with a browser: a colour pair that fails contrast, a typeface that costs too much to load on a phone, a layout that has no sensible narrow version. If there is no design to work from we design the templates, which is a smaller job than designing every page and is what keeps the site consistent as it grows.

Somebody has to patch it, watch that it is up, renew the certificate, and make the small changes that come out of the first months of real use. We will do that on a support arrangement, and the first weeks after a launch are included in the build because that is when the problems surface. If you would rather your own team took it over, that is a legitimate answer and the documentation is written for it rather than being an export nobody can read.

It is built to, and it is checked as the pages are built rather than audited after somebody complains. In practice that means a sensible heading order, a keyboard path through every flow including the ones behind a menu, form fields with real labels, images described where they carry meaning and ignored where they are decoration, and colour pairs that meet contrast rather than nearly meeting it. It is also worth saying plainly: this overlaps almost entirely with what makes a site work well on a bad connection on an old phone.