Most web development enquiries in Nottingham begin with an inherited site
The common situation is not a blank page. It is a site built years ago by a supplier who has since moved on, changed direction or stopped answering email. It still works, more or less. Nobody in the building knows what it runs on, where it is hosted or who pays for the domain, and the first person asked to change something discovers that nothing is documented.
Taking that over is a specific kind of web development engagement, and it should be priced and planned as one. A firm that responds to an inherited site by quoting a rebuild has skipped the only step that tells you whether a rebuild is necessary.
Recover the access before planning anything
Start with an inventory of credentials, not of features. Who holds the domain registration and when does it renew. Who receives the invoice for hosting. Where the code lives and does anyone outside the previous supplier have it. Which email addresses are attached to the analytics, the payment account, the certificate, the search console and the mail service.
This exercise is dull and it is the highest value hour of the whole project. Organisations regularly find that a critical account is registered to a personal address belonging to someone who left, or that renewal notices go to a mailbox nobody reads. Fix the ownership first, because every other decision depends on being able to act.
Find out what the site is actually made of
Ask a prospective supplier for a short paid assessment rather than an opinion. It should tell you which platform and version is running, which extensions and libraries are installed and how far behind they are, whether the code is under version control, whether there is a staging environment, how deployment happens, and whether anything has been edited directly on the live server.
That last point decides a great deal. A site that has been patched live for years has no reliable source of truth, and the first job of any new web development partner is to establish one. Ask for the assessment as a written document you keep, so that you can show it to a second opinion without paying for the work twice.
Security debt is the part that will not wait
Unmaintained sites accumulate risk quietly. Outdated components with published vulnerabilities, abandoned plugins, administrator accounts belonging to former staff and contractors, form endpoints being used to send spam, backups that have never been restored to check that they work.
Separate the findings into what must be fixed now, what can wait for the next release, and what only matters if you keep the platform. Then agree who applies security updates from this point forward, how quickly, and how you will be told. A support arrangement that does not name a response time for security fixes is not a support arrangement.
Repairing and replacing are both legitimate answers
The instinct after a poor assessment is to start again. Sometimes that is right. Often it is not, because a rebuild resets your search visibility, your integrations and your editors' familiarity at the same time, and it takes months during which nothing improves.
Judge it on three things: whether the platform still receives security updates, whether your content model can express what you now need to publish, and how much of the remaining cost is one time cleanup rather than permanent friction. If two of the three are fine, staged web development work usually beats starting again. If the platform is unsupported, the decision is made for you and the argument is only about timing.
What a takeover engagement should look like in its first weeks
Expect the new supplier to put the code under version control, stand up a staging environment, document how to deploy, take a restorable backup and verify it, then make one small visible improvement. That sequence proves control before it spends your budget on features.
Agree in advance what the deliverable is. Not a redesign, but a site somebody else could pick up: a repository you own, a written description of the environment, and a list of every external service the site depends on with the account that owns it. Nottingham buyers who ask for this at the start rarely find themselves in the same position again.
Support agreements that mean something
Ongoing work is usually sold as a monthly fee, and the fee alone tells you nothing. What matters is what is included, what counts as a fault against what counts as a change request, how quickly someone responds, whether the hours roll over, and whether unused time can be spent on improvement rather than lost.
Ask what the supplier does proactively without being asked: updates, backup checks, uptime monitoring, certificate renewals, error log review. Ask for a short written report each month. A retainer with no visible output is the easiest thing in web development to keep paying for and the hardest to value.
Comparing web development companies in Nottingham
Give two or three candidates the same access, the same assessment document and the same list of things you want to be able to do in a year, then ask each for a plan rather than a price list. The plans will differ more than the numbers, and the differences are the information.
Ask each for a client whose site they inherited from another firm, and ask that client how the first quarter went. Ask to meet whoever would actually do the work. You can review verified web development companies in Nottingham, compare them across the wider directory of build partners, and request proposals through our offer request form. Where the work also touches interface decisions, custom systems or visibility, see web design agencies, software companies and SEO agencies working with the same buyers.