Custom website development makes sense when your design, editing process or visitor journey has requirements your current setup doesn’t meet. You don’t have to rebuild everything. An adapted theme, a separate integration or a clearer structure may solve the problem. This guide takes you from that decision to a defined brief, a delivery you can assess and workable support arrangements. For the technical routes, read our comparison of WordPress, custom development and headless.
What makes a website custom-built?
A custom website has elements designed and built for your situation. That might mean the visual design, the way editors assemble pages or a booking journey connected to other systems. The term alone says little about price, performance or ownership. You need to assess and agree those separately.
An original design doesn’t automatically require a bespoke CMS. Nor do you need to replace a working booking system just because you want a new website around it. Name what needs to change and what you can keep. That makes a proposal easier to assess than a promise that the whole website will be ‘unique’.
Ownership doesn’t follow from the label either. Ask which parts are being created for you, which existing software you’ll use and what happens if you later change suppliers.
When is custom development worth considering?
Start with a problem you can demonstrate. Visitors can’t tell which service suits them. Your team enters the same opening hours in several places. Or customers can’t complete a booking on their phone. Each problem needs a diagnosis first; the answer may fit within your current website.
| Situation | Investigate first | Custom work becomes interesting when |
|---|---|---|
| The site doesn’t reflect your brand | Copy, photography and changes to the current design | The presentation you need doesn’t fit the available building blocks |
| Staff enter the same information repeatedly | Existing integrations and a clearer source for shared information | Available tools don’t cover your process |
| You serve different audiences or languages | Content structure and editorial responsibilities | You need distinct visitor journeys or editing functions |
| The site responds slowly | Measurements on real pages and causes in images, scripts or hosting | You can’t reasonably resolve the restrictions within the current setup |
Multiple languages, search visibility and a recognisable identity don’t prove you need everything built from scratch. Ask an agency to demonstrate the difficult requirement. Can an editor publish a service page in another language without carrying across the wrong contact details, for example?
Weigh the extra development and support costs against the problem you’re solving. If nobody can explain what a visitor or colleague will be able to do better, the brief is still too vague. Our comparison of WordPress, Webflow, Wix and Shopify helps you consider existing platforms too.
What belongs in a useful brief?
Write down who uses the website, what they need to know and which action should follow. ‘More enquiries’ is a goal, but it doesn’t yet describe the website. Which enquiry do you want, what information does a visitor need, and who deals with the request internally?
Then take stock of the pages you already have. Mark which content is current, which should go and where new material is needed. Include files and forms outside the main menu. You don’t want to discover a missing brochure or campaign page after the move.
A useful brief also includes:
- The functions that must work at the first release, with an example of a normal action and a failed one.
- The people who edit content and the permissions they need.
- The systems sending or receiving data, with a contact who can arrange access.
- The person approving copy and design, and when they’re available.
- The boundaries of the work, such as translation, photography or a customer portal planned for later.
A screen saying ‘thanks for your enquiry’ isn’t enough if the message never arrives. Specify where it should go, who notices a failure and what the visitor sees if submission doesn’t work.
How do you compare quotes and costs?
A page count doesn’t tell you how much work a website involves. Many pages can share a design, while a single form can involve several systems and awkward exceptions. Ask for a breakdown covering design, content, development, integrations, migration and testing. Make your own team’s responsibilities visible too.
Compare costs over the same period of use. Include the build, hosting, paid components, support and expected changes. Record which costs are fixed and which change with traffic, usage or extra editors. Ask whether figures include VAT and work by other suppliers.
A fixed price gives you clarity about an agreed package. New requests may fall outside it. Hourly work can suit an investigation whose outcome is still uncertain, provided you agree when to review progress and spending. Neither model replaces a clear description of the work.
Where a function is uncertain, consider a small investigation before committing to the whole build. Specify what it should produce: a working trial, an evidenced decision or a revised estimate. Our guide to website development costs covers the cost structure in more detail.
How do design, development and content fit together?
Work towards decisions you can assess. Start with the content and visitor journey, then a design using real copy and images, followed by a working version. This needn’t be a rigid sequence: an early technical trial may be necessary to test a design decision.
Don’t use an empty sample page as your only design test. A long heading, a missing photograph and a paragraph that takes more space in English will show whether the layout works in practice. Look beyond the homepage too. Search results can take people straight to a service, news item or form.
Have a future editor publish something during development. Can they choose an image, correct a mistake and identify the version that’s live? A polished demonstration by the developer doesn’t prove your team can work independently. Read about web design for the visual side of the process.
Tie the schedule to concrete handovers: system access, approved copy, translations and test results. State what happens if something arrives late. A delivery date without those dependencies gives you little to plan around.
Which technology and editing setup fit your team?
The editing process should reflect how often content changes and who changes it. A site where every article passes through a marketer and a legal reviewer has different needs from a company page updated occasionally. Discuss examples of publishing, reverting and translating content before choosing a CMS.
WordPress and headless aren’t mutually exclusive: the WordPress REST API can supply content to a separate front end. That makes the separation possible, but it isn’t a reason to choose it. Ask what the extra components give your team and who will maintain them.
The same applies to frameworks. A name on a quote doesn’t prove speed or low maintenance costs. Ask which parts run on a server, which external services are needed and how a change reaches visitors. Our comparison of Astro, Next.js and WordPress covers the technical choices.
For hosting, agree who performs updates, receives incident alerts and handles recovery. A hosting subscription and a maintenance agreement are different things. Ask whether you’ll have a test environment and how a failed change can be reversed.
What should you check before launch?
Agree an acceptance checklist of tasks that must work. Submit an enquiry on a phone, check it arrives and try invalid input too. Test search, menus and language switching with the final content. An integration that only works in the demonstration isn’t ready for handover.
Include accessibility in that review. W3C’s first accessibility checks cover areas such as keyboard use, text alternatives and contrast. These initial checks aren’t a full accessibility assessment; agree separately what evaluation your project needs.
For performance, Google uses measures including Core Web Vitals. The good thresholds are LCP at most 2.5 seconds, INP at most 200 milliseconds and CLS at most 0.1, assessed at the 75th percentile, separately for mobile and desktop. A pre-launch lab test doesn’t replace measurements from real visitors. See the official Web Vitals explanation.
Ask for results on representative pages with real images and scripts, and agree what will be measured after launch. Good scores don’t guarantee a high search position, as Google’s page experience guidance explains. Neither does a custom-built label.
How do you move existing content without surprises?
Decide which existing pages to keep, combine or remove. Where addresses change, record the destinations and test the redirects. Update internal links too. Google’s website migration guidance recommends mapping old URLs to new ones and using permanent redirects where needed. Rankings can fluctuate while changes are processed.
Agree when content will be copied and what happens to edits made on the old site afterwards. Check downloads, images and forms separately. They may use different storage or settings from ordinary pages.
Before launch, establish who decides whether the move goes ahead, who is available during an incident and when to roll back. For forms or booking systems, you also need to know what happens to data received in the meantime. Keeping the old files alone isn’t a complete plan.
What should you agree about ownership and handover?
Specify which custom code will be handed over and which terms apply to existing components. ‘The code is and remains yours’ needs to match the actual agreement. A CMS, font, photograph licence or subscription can have its own terms; don’t present those parts as though you automatically acquire every right to them.
Access is a separate issue. List domain registration, hosting, content editing and connected services, with a named owner for each account. Document how another maintainer can change and release the website, and how content and files will be made available if you leave.
Put the handover into practice: can your team log in and complete an editing task, and can the maintainer work from the documentation? You need usable access, not just a folder of files. Read our explanation of code ownership and supplier dependency for the wider considerations.
What happens after delivery?
Assign someone to collect fault reports and decide which change takes priority. Distinguish between a failure to meet the agreed delivery, necessary technical upkeep and a new request. Agree how each is handled and when support is available.
Backups also need a recovery procedure. Record which content and settings are saved, who can start a recovery and how you’ll check it works. For services from other suppliers, establish which part of recovery they handle.
After launch, look at whether visitors can complete the intended task and whether your team can process enquiries. Use those findings to make improvements. More traffic isn’t the same as better enquiries, and a new website won’t fix an unclear offer by itself.
How do you actually get started?
Collect your main pages, recurring problems and one task that should work measurably better. Then assess whether changing the existing site is enough or whether new development is needed. Ask for a proposal where you can identify the scope, dependencies and delivery checks.
Want to work through that decision with us? See our approach to custom website development or book a call. Include the person who will manage the website after delivery; that choice belongs in the brief from the start.
