Bespoke websitesYour questions, answered.

A bespoke website is designed or developed around specific requirements rather than relying entirely on a standard theme. Clarify which elements are custom and which are existing products. Bespoke does not automatically mean faster, more accessible or easier to maintain.

Next step: Ask for a breakdown of custom features, platform components and third-party services.

Custom development can make sense when essential workflows or integrations cannot be supported reliably by an existing platform. Compare the ongoing maintenance burden as well as the initial build. Avoid custom complexity where a supported product already meets the need.

Next step: List requirements that standard platforms cannot meet and prioritise the essential ones.

Describe audiences, tasks, content, integrations and operational constraints. Include accessibility, performance, ownership and support expectations. Separate essential requirements from preferences so suppliers can propose sensible trade-offs rather than guessing what matters.

Next step: Create a prioritised brief and name who approves scope and content.

Ownership and licences depend on the contract and the assets involved. Payment alone should not be assumed to grant every reuse right. Clarify source access, third-party licences, design rights and whether another supplier can maintain the site; get legal advice where appropriate.

Next step: Specify intellectual property, repository access and supplier exit arrangements in writing.

A content management system lets authorised people update content through an editing interface. Systems differ in permissions, preview, publishing and maintenance. Choose based on real editing tasks rather than a feature list or the assumption that every CMS suits every business.

Next step: Ask the future editors to try publishing a realistic page.

A headless setup separates content management from presentation, often delivering content through an API. It can support several channels but adds work around preview, deployment and maintenance. It is not automatically faster or simpler than a conventional site.

Next step: Map the editorial workflow and support requirements before choosing the architecture.

Define the data moving between systems, direction, timing and access requirements. Plan for authentication, rate limits and service failures. An integration that works in a demonstration can still lose requests or create duplicates under real conditions.

Next step: Draw the data flow and agree failure alerts and recovery responsibilities.

Map fields, validate submissions and record them reliably before showing success. Consider duplicates and temporary CRM failures. Restrict access to collected data and keep service requests separate from unrelated marketing permissions. A connection does not automatically guarantee clean sales data.

Next step: Test successful, duplicate and failed submissions through the entire journey.

Security is ongoing: maintain supported dependencies, protect credentials, restrict privileges and validate inputs. HTTPS protects transmission but not every application vulnerability. Controls should reflect the sensitivity of data and the consequences of failure.

Next step: Agree an update, access review and incident-response plan with your developer.

HTTPS encrypts traffic between browser and website and helps prevent interception and tampering in transit. It does not establish that a business is trustworthy or eliminate application vulnerabilities. Check certificates, redirects and mixed-content warnings after deployment.

Next step: Open key pages and confirm all resources load securely without browser warnings.

A restore may need content, files, database records and configuration, not just a copy of visible pages. Set retention and access controls and test recovery. A backup that exists but cannot be restored offers little practical protection.

Next step: Ask for a demonstrated restore and a record of backup ownership.

Test important journeys, redirects, forms, accessibility, analytics, metadata and device behaviour. Confirm domain access, backups and rollback arrangements. Visual approval is not proof that forms deliver or payments work under real conditions.

Next step: Assign an owner and pass-or-fail result to every critical launch check.

Maintainability depends on understandable code, supported dependencies and documentation. Overly complex architecture creates costs long after launch. Ensure someone other than the original developer can understand deployment, external services and recovery procedures.

Next step: Request a handover pack covering deployment, dependencies and routine changes.

Retain control of essential accounts and clarify source access, licences and handover assistance. Some platforms remain specialised, so portability is not unlimited. An exit plan should describe the practical work and costs of moving rather than simply promise ownership.

Next step: Inventory domain, hosting, repository and service-account owners.

An API is a defined way for software to exchange data or request actions. APIs vary in authentication, limits and availability. Using one requires error handling and a plan for changes; secret credentials should never be exposed in browser code.

Next step: Request current documentation and clarify permissions, rate limits and failure behaviour.

Build accessibility into requirements, design and testing rather than adding it after visual approval. Semantic controls, keyboard operation and understandable errors matter. Automated checks find only some issues; important journeys need manual and assistive-technology testing.

Next step: Specify an appropriate WCAG target and test key journeys with a keyboard.

Collect only what is needed for explained purposes, restrict access and set retention. Map suppliers and transfers before integrating services. Applicable UK obligations depend on circumstances and require appropriate privacy assessment rather than a generic checklist.

Next step: Document how each personal-data field moves from collection to deletion.

Staging is an environment for reviewing changes before they reach the live site. It is not private just because it is unlinked. Protect access and avoid unnecessary real customer data, while keeping test conditions close enough to production to expose issues.

Next step: Check access restrictions and replace live personal data with test data.

Match hosting to application requirements, traffic patterns, support and recovery needs. Clarify who updates software and handles incidents. Capacity alone cannot make inefficient code fast; assess the whole system and whether export and migration are practical.

Next step: Create a responsibility matrix for hosting, backups, updates and migration.

Progressive enhancement provides usable core content and adds richer features where supported. It improves resilience when scripts fail or device capabilities differ. It does not prohibit modern technology; it prevents unnecessary dependence on enhancements for essential information.

Next step: Check what visitors can understand and do if a nonessential script fails.

Discovery should clarify user needs, scope, risks and decisions requiring further investigation. Useful outputs include journeys, requirements and integration assumptions. It should reduce uncertainty rather than merely produce a presentation or commit to a build before feasibility is understood.

Next step: Agree the decisions and practical deliverables expected from discovery.

Separate essential customer and operational needs from preferences and future possibilities. Include the consequence of omitting each feature. Priorities should reflect value and dependencies rather than the order suggestions arrived or the seniority of their author.

Next step: Mark requirements as essential, useful or later and assign an owner.

A minimum viable website delivers a coherent core journey with enough quality to be useful and safe. It is not permission to skip essential security or accessibility. Defer optional features while keeping the primary task complete.

Next step: Define the smallest complete customer journey you can responsibly launch.

Group work into deliverable stages with clear acceptance criteria and dependencies. Early stages should resolve high-risk assumptions and establish a usable foundation. Phasing only helps when later features can be added without undoing fundamental decisions or misleading users.

Next step: Agree stage outcomes, approvals and what remains out of scope.

An acceptance criterion describes observable behaviour needed for a requirement to pass. It makes review less subjective and helps testing. Include errors and permissions as well as successful actions so approval does not rest solely on a happy-path demonstration.

Next step: Write pass-or-fail checks for each essential feature.

Record the requested change, its reason and effects on cost, timing and dependencies before approval. A small visual request can affect content or integrations. Keep a current agreed scope so neither party relies on conflicting conversations.

Next step: Use a written change record with an authorised decision-maker.

A specification describes behaviour, data, dependencies and constraints needed to build and maintain the agreed service. It need not list every implementation detail. Focus on consequential decisions and interfaces so different people can understand what must remain true.

Next step: Document data flows and critical behaviour before development begins.

A decision record explains a significant technical choice, alternatives considered and the reason for it. It helps future maintainers understand trade-offs without reconstructing old discussions. Update or supersede it when circumstances change rather than treating it as permanent truth.

Next step: Record the reason behind your most consequential platform choice.

Test business rules, permissions, data handling and important customer flows likely to break. Visual checks can complement these but do not prove correct logic. Select a practical mix and run it as changes are made rather than only at launch.

Next step: Add tests for enquiry receipt, access restrictions and critical integrations.

An end-to-end test follows a complete journey across the relevant parts of the system, such as enquiry submission and receipt. It exposes failures that isolated checks miss. Use realistic conditions and confirm the result can be read back.

Next step: Test one critical journey from input through its final stored outcome.

Review correctness, security, maintainability and alignment with requirements, not formatting alone. Another developer or a structured review process can identify risky assumptions. Automated tools help but cannot independently approve every design or business-rule decision.

Next step: Require review of permissions, validation and failure handling before release.

A deployment pipeline applies repeatable checks and publishes an approved version to an environment. It can reduce manual mistakes but depends on correct configuration and permissions. Keep a recovery plan because passing automated checks does not eliminate production risk.

Next step: Document release checks, approval responsibility and rollback steps.

Plan how to restore a known working version and handle any data changes made during the release. Code rollback alone may not reverse migrations or external actions. Test recovery before a high-risk change and clearly assign authority to use it.

Next step: Rehearse rollback with attention to database and integration compatibility.

Monitor availability, important errors and failure of critical business flows. A homepage responding successfully does not prove forms or payments work. Keep alerts actionable and avoid recording secrets or unnecessary personal information in diagnostic logs.

Next step: Set alerts for failed enquiries and the availability of essential services.

Explain the impact, available alternatives and the next update without guessing an unverified recovery time. Keep staff informed and use a channel that does not depend entirely on the failed system. Afterwards, document causes and prevention work accurately.

Next step: Prepare a simple incident communication plan and alternative contact route.

An agreement should distinguish availability targets, support hours, response priorities and recovery expectations. Specify exclusions and each party's responsibilities. A response target is not automatically a resolution guarantee, and infrastructure promises may differ from application support.

Next step: Review realistic incident scenarios against the proposed agreement.

Identify likely bottlenecks in data access, processing and third-party limits, then test representative load. Scaling is not just buying larger hosting. Capacity changes should preserve correctness and control costs while keeping sensitive data appropriately protected.

Next step: Load-test the busiest expected journey and define capacity alerts.

Caching reuses previously prepared content or results to reduce repeated work. It can improve performance but risks showing stale or inappropriate information if rules are wrong. Personalised and private content needs particular care to avoid cross-user exposure.

Next step: Identify which results can be cached and when they must be refreshed.

A content delivery network serves eligible content from distributed locations closer to users. It can reduce latency and origin workload. It does not automatically fix inefficient application code or safely cache every page, especially authenticated or personalised responses.

Next step: Review which assets and public responses should use distributed caching.

Define the actions each role needs and enforce those permissions where data is read or changed. Hiding a button alone is not access control. Review privileged access regularly and avoid letting users assign themselves administrative rights.

Next step: Create a role-action matrix and test attempts outside each role's permissions.

Least privilege gives users and services only the access needed for their job. It reduces the consequences of mistakes or compromised accounts. Permissions should change when responsibilities change, with sensitive actions protected and access decisions enforced reliably.

Next step: Review administrator and service permissions and remove unused access.

Private credentials belong in protected server-side configuration, not public code, downloads or logs. Limit access and rotate credentials when exposure is suspected. Public configuration must be distinguished from secrets before sharing a repository or connecting an external service.

Next step: Inventory private credentials and confirm none are shipped to browsers.

A webhook sends an event notification from one service to another. Verify the sender and handle duplicates, delays and retries. Receiving an event is not proof that every related business action completed successfully or in the expected order.

Next step: Define verification, event deduplication and recovery for the integration.

Provide clear feedback and a safe recovery path without losing essential requests where possible. Use controlled retries and alerts rather than repeatedly overwhelming the failing service. Decide which tasks can continue and which require confirmation before showing success.

Next step: Test a simulated outage for your most important external connection.

An idempotent operation can be repeated without creating an unintended extra effect. It matters when networks retry enquiries, orders or payments. A unique request identifier and stored outcome can help, but the design must cover the full action being repeated.

Next step: Test the same request twice and confirm only the intended outcome occurs.

Distinguish accidental retries from genuine new requests using appropriate identifiers and business rules. Disabling a button can help usability but is not sufficient protection. Avoid overly aggressive matching that silently discards a legitimate second enquiry.

Next step: Test repeated clicks, network retries and a genuine follow-up submission.

Reconcile counts, important fields and relationships using representative records before replacing the original system. Keep a secure recovery copy and assess data that should not migrate. An import-complete message does not establish accuracy or suitable retention.

Next step: Trial a migration and compare totals plus a sample of complete records.

Include account ownership, source access where agreed, release instructions, dependencies and operational responsibilities. Explain routine editing and incident recovery. A collection of passwords is neither a safe nor a sufficient handover pack.

Next step: Ask another maintainer to follow the documented deployment and recovery process.

Assess security exposure, compatibility and replacement options before support ends where possible. Unsupported does not mean immediate failure, but it increases maintenance uncertainty. Plan an upgrade or replacement with testing rather than indefinitely ignoring alerts.

Next step: Maintain a dependency inventory and schedule supported-version reviews.

Register the domain under the appropriate business control with current contacts and secure account access. Renewal and recovery should not depend on one supplier or employee. Clarify ownership separately from who manages DNS or hosts the website.

Next step: Check registrant control, renewal settings and authorised account access.

DNS connects a domain name to services such as websites and email. Changes can affect several systems and may take time to propagate. Record existing settings and consider verification and mail records before replacing values during a launch.

Next step: Review the full DNS record set before changing website hosting.

Identify whether mail depends on the domain's current provider and preserve relevant DNS and account settings. Website hosting and email hosting may be separate. A website migration should not accidentally remove mail routing or authentication records.

Next step: Confirm email dependencies and test inbound and outbound mail after the move.

Server-side rendering produces page content before sending it to the browser. It can help initial access to content but adds operational considerations. It is not an automatic guarantee of speed, indexing or accessibility; implementation and delivered content still matter.

Next step: Check the actual initial response and performance rather than relying on a framework label.

A static website serves prebuilt content rather than generating every page per request. It can simplify delivery, while forms and dynamic features may still use services. Suitability depends on editing, personalisation and workflow requirements rather than the size of the business alone.

Next step: Map which features need live processing before choosing a delivery approach.

A database is useful when structured information must be stored, queried or updated reliably. Simple public pages may not need one. Once personal or operational data is stored, access control, recovery and retention become part of the website's responsibilities.

Next step: List the data that must persist and who should read or change it.

Enforce authenticated access and per-user or per-organisation permissions on every relevant data operation. Do not rely on obscure URLs or hidden menus. Test cross-account access and minimise information returned to each role.

Next step: Attempt to read one customer's records while signed in as another.

Integration may be possible through supported APIs, exports or carefully managed intermediary services. Confirm permissions, reliability and vendor terms. Lack of an API does not justify insecure credential sharing or an assumption that browser automation will remain dependable.

Next step: Ask the vendor about supported access and test a limited data exchange.

Include updates, monitoring, hosting, licences and expected change work, distinguishing routine support from new features. Costs depend on complexity and responsibility. A low initial build price can conceal higher ongoing obligations or unsupported dependencies.

Next step: Request an itemised ongoing-cost estimate and exclusions.

Technical debt is future work caused by shortcuts or design decisions that make later changes harder. Some trade-offs are deliberate, but hidden debt can increase failure risk and cost. Record consequential shortcuts and prioritise repayment against business impact.

Next step: Ask for a short list of known debt and its practical consequences.

Identify users, data, links and integrations affected before removing a feature. Provide suitable alternatives and preserve required records securely. Retirement should also remove obsolete access and dependencies rather than only hiding the feature from navigation.

Next step: Create a removal checklist covering users, data, redirects and service access.