Most business websites run well on a theme and a few plugins. Custom web development is for the part that will not: a booking flow that has to check a real diary, a quote calculator built on your own pricing rules, a client area where customers download their documents, or a link between the website and the CRM your sales team already uses. This page explains how I approach that work for UK businesses, and when I would advise against it.
What custom development fixes
The usual trigger is a workaround that has quietly become part of someone’s job. Every web enquiry is retyped into another system. A customer fills in a form, then waits for a call to hear a price the website could have worked out. Three booking tools have been tried and none of them understands that a home visit in Croydon needs more travel time than one in Clapham.
Each of these costs staff hours every week, and some cost enquiries as well, because people leave when a site cannot answer them. A well-scoped custom feature removes the workaround: data goes where it is needed without being copied by hand, the customer gets an answer on the page, and you stop paying for several add-ons that each do part of the job.
What custom code does not do is make a site rank or convert by itself. A calculator nobody can find is a calculator nobody uses, so I plan the search and measurement side alongside the build.
Who it suits, and who it does not
It suits UK businesses whose way of working is specific enough that off-the-shelf tools keep getting in the way: clinics and salons with complicated appointment rules, installers and trades who price by measurement, B2B suppliers with trade accounts and customer-specific price lists, training providers selling courses with limited places, and professional firms that want a secure place to swap documents with clients.
It is the wrong answer more often than people expect. If a maintained plugin or a hosted booking platform covers nearly everything you need, changing your process to suit the tool is usually cheaper than building and owning your own. Custom code also needs looking after for as long as it runs, because server software is upgraded, third-party connections are retired and unpatched code becomes a security risk. Without a budget for that upkeep, I would rather point you to a paid tool with a support desk.
If the real complaint is that the site is slow, dated or hard to edit, a redesign of the website you already have is probably the better job. My article on whether to fix your current website or start again walks through that decision.
What the work can cover
Booking and enquiry flows
Multi-step booking that checks live availability, takes a deposit through a UK payment provider such as Stripe or GoCardless, and sends confirmations and reminders. The valuable part is usually the rules: gaps between appointments, staff who only offer certain services, and the postcodes you cover.
Quote calculators and configurators
A calculator that turns your pricing rules into an instant estimate. For consumer sales, UK pricing rules expect the figure shown to include VAT and any fee the buyer cannot avoid, so that goes into the logic rather than the small print. For trade customers, prices can be shown before VAT and labelled as such.
Client portals and logged-in areas
Secure areas where customers download reports, upload files, follow an order or manage a subscription. These hold personal data, so who can see what, how long it is kept and how it is deleted are designed in from the first sketch, in line with UK GDPR.
Integrations with the systems you already use
Connecting the website to a CRM, an accounting package such as Xero, a stock system or an email platform through its API, so leads, orders and contacts arrive without anyone retyping them. Sometimes a no-code connector does this well enough for much less, and I will say so when it does.
Custom functionality for WordPress
On a WordPress site, bespoke features belong in a small, documented plugin of their own rather than inside the theme, so they survive the next redesign. Editors get content blocks that fit what they publish, instead of a page builder that lets anyone break the layout.
How I run a custom build
- Map the process as it runs today. Before any code, I write down who does what, which systems hold which data and where things go wrong. This often shows that part of the problem is a process change rather than a feature.
- Write a specification you can read. In plain English: what the feature does, the rules it follows, what happens when something fails, and what it deliberately leaves out. You sign it off, and the quote is based on it.
- Plan search, measurement and consent. Which parts need to appear in Google, which events show the feature is being used, and which scripts must wait for cookie consent.
- Build on a copy of the site. Development happens on a staging site with the code kept under version control, so your live website is never the test environment.
- Test the awkward cases. A booking made at midnight, a postcode outside your area, a declined card, a keyboard-only visitor, a weak mobile signal.
- Launch, watch and hand over. Release at a quiet time, monitor errors and enquiries closely for an agreed period, then hand over documentation and access.
Problems I see most often on UK sites
- Content Google cannot see. Calculators and filters built entirely in the browser can leave a page looking empty to a crawler. Good JavaScript SEO means the useful text and links are in the HTML Google receives.
- Enquiries missing from the reports. Custom forms and multi-step flows often submit without loading a new page, so the standard analytics and ads tags never fire. Each build should send a clear completion event; here is how to check that your conversion tracking works.
- Cookies set before consent. Embedded booking widgets and chat tools often drop non-essential cookies as the page loads, which PECR does not allow until the visitor agrees.
- Leads stuck in one inbox. Submissions emailed to a single person, with no record in the CRM, go unanswered the week that person is away.
- Code only one person understands. No documentation, no repository, and the developer has moved on, leaving a feature the business owns but cannot change.
These are the same faults a technical SEO review finds on existing websites, and they cost far less to avoid at the specification stage than to repair later.
Decisions worth making early
- Who owns the code. The agreement should state that the code is yours and that the repository sits in your account, or moves there at handover.
- Where it runs. Cheap shared hosting is fine for a brochure site; a portal with logged-in users and stored files usually needs more.
- Who maintains it. Agree who updates the feature when the server software, WordPress or a connected service changes, and what that costs each year.
- Where personal data goes. Decide what the feature stores, for how long and which suppliers process it, so your privacy notice and supplier contracts match what the site really does.
- Accessibility. Build to WCAG 2.2 level AA from the start. Adding it to a finished booking flow is slow and expensive.
What you receive
- The signed-off specification, updated whenever the scope changes.
- The working feature on your live site, tested on staging first.
- Source code in a repository you control, with a short setup note.
- A measurement note listing each event the feature sends and where it shows in GA4.
- Admin instructions written for the person who will use the feature every day.
- A list of every external service involved, with the account owner and renewal date.
What it costs
The price depends on the rules more than the number of screens. A calculator with a handful of inputs and one price table is a small job; a portal with accounts, payments and a CRM sync is a project. Each quote is written in pounds against the signed-off specification and agreed in writing before work starts, with ongoing maintenance agreed separately.
Next step
Write a few lines on what the website needs to do, which systems it has to talk to and the workaround you rely on today, then send them to me through the contact page. I will tell you whether it calls for custom code, a configured off-the-shelf tool or a change of process, before anyone is paid to write code.