Frequently asked questions

Most projects begin with a conversation about the problem, the people affected, the current environment and the outcome you need. We then identify any discovery work required and define an appropriate scope, delivery approach and commercial arrangement before work begins.

Yes, where that is practical. We first clarify responsibilities, access, technical constraints and dependencies, then coordinate with internal teams and relevant suppliers around the agreed work. Third-party cooperation and platform limitations can affect what is possible.

Potentially. We normally review the codebase, hosting, documentation, access, dependencies and current risks before confirming the scope. That assessment helps establish whether the service can be adopted as it stands, needs stabilisation or would benefit from a more substantial change.

Yes. Some requirements suit a defined project, while others need retained delivery, managed digital capability or ongoing hosting and care. The responsibilities, capacity and boundaries are set out for the relevant engagement rather than assumed to be the same in every case.

Yes. Evoqode designs and develops websites around the organisation, its audiences, content and operational needs. The technical approach may use a suitable content management system, a custom build or another architecture where the requirements justify it. Explore Web Design & Development.

Yes. We can assess an existing website's structure, content, user journeys, accessibility, performance and technical foundations, then recommend proportionate improvements. That may lead to focused changes, a phased redesign or a replacement where the evidence supports it.

Responsive behaviour and accessibility are considered throughout design and development. The specific standards, content responsibilities, testing and acceptance criteria depend on the project, so any formal accessibility requirement should be defined clearly within the scope.

Yes, where suitable interfaces and access are available. Integrations can connect websites with platforms such as customer systems, booking tools, payments, data services or operational workflows, subject to the third party's documentation, security model and technical constraints.

Evoqode can design and engineer operational platforms, customer or partner portals, workflow systems, data-led applications, integrations and other bespoke digital products. The right form depends on the users, processes, information, controls and outcomes involved. Explore Software & Platform Development.

Yes. We first assess the current application, its users, architecture, data, dependencies and operational risks. Modernisation may involve retaining sound parts, improving or refactoring others, integrating new services, or replacing components that no longer serve the organisation well.

Yes. APIs and integrations can help systems exchange information and support connected workflows. Their design depends on data ownership, security, reliability, error handling and the capabilities of every system involved.

These concerns are treated as part of delivery rather than postponed until launch. The approach can include proportionate automated and manual testing, code review, access controls, dependency management, documentation and operational checks. No technical system is risk-free, so assurance is matched to the service and its context.

They can be useful where work involves repeatable decisions, information extraction, classification, drafting, routing, summarisation or coordination across systems. Suitability depends on the use case, data, risk and need for human judgement; sometimes conventional software or simpler automation is the better answer. Explore AI & Automation.

Yes. Provider and model selection depends on the task, quality requirements, privacy, security, integration options, cost profile and operational constraints. We do not assume that one model is appropriate for every use case.

Often, yes. An AI capability can sit within a controlled workflow rather than becoming a separate destination. The integration needs clear inputs, permissions, validation, exception handling and a defined route for human review where the consequences justify it.

We consider what data is used, where it is processed, who can access it, how outputs are checked and what happens when the system is uncertain or wrong. The controls and level of human oversight are shaped around the use case, provider and risk involved.

No. AI outputs can be incomplete, inconsistent or incorrect and may require validation or human approval. Testing and controls can improve reliability, but they cannot guarantee a particular output, operational saving or commercial result.

The work can combine technical search foundations, site and content structure, on-page optimisation, structured data, performance, authority signals, analytics and conversion insight. The appropriate mix depends on the organisation, audience, market and current digital platform. Explore SEO & Digital Growth.

Yes. Strong technical foundations, clear structure, useful content and credible signals support both traditional search and emerging AI-assisted discovery. The platforms work differently, so the approach considers both without treating AI visibility as a replacement for established SEO practice.

No. Search engines and AI platforms control what they rank, surface, cite or summarise, and their systems change over time. Optimisation can improve relevance, quality and eligibility for discovery, but it cannot guarantee a particular ranking, citation, traffic level or commercial outcome.

There is no universal timescale. Technical improvements may be implemented quickly, while discovery, competitive movement, content performance and authority usually develop over time. The starting position, market, website and pace of implementation all influence progress.

Measurement normally uses a combination of technical health, visibility, qualified traffic, engagement, conversions and other relevant actions. AI-assisted visibility may also be reviewed where dependable signals are available, while recognising that its measurement is still evolving.

Yes, where it is appropriate for the website or application. The agreed arrangement defines the environment, monitoring, maintenance responsibilities, access and dependencies. Hosting and operational controls reduce risk, but they do not make a digital service immune to faults or third-party disruption.

They can be included within an agreed hosting or care arrangement. Backup frequency, retention, restoration responsibilities and recovery expectations need to be defined for the service. Backups reduce risk but cannot remove every possibility of data loss or interruption.

Evoqode investigates and coordinates the issue according to the agreed support scope, coverage and escalation route. Resolution may also depend on access, the underlying platform and third-party providers. Response expectations are defined in the relevant service arrangement rather than assumed universally.

Continuous support should not be assumed. Support hours, escalation routes and any out-of-hours requirement depend on the agreed service arrangement. If around-the-clock coverage is important, it should be raised early so the required model and its feasibility can be confirmed explicitly.

Potentially, subject to appropriate access, documentation and a clear division of responsibilities. The provider's platform, support terms and technical limitations may affect what Evoqode can monitor, change or resolve directly.

It is an ongoing arrangement that brings relevant digital disciplines together around an agreed roadmap and improvement backlog. It can provide continuity across websites, applications, content, analytics, search, experience and automation without treating every requirement as a separate project. Explore Managed Digital Services.

Hosting, Care & Support focuses on operational continuity: environments, monitoring, maintenance, recovery and technical incidents within the agreed scope. Managed Digital Services is broader and focuses on how the wider digital estate should evolve through planned improvements and coordinated delivery.

Work is managed through an agreed roadmap or backlog and prioritised using factors such as value, evidence, urgency, dependencies, cost, risk and available capacity. A managed arrangement provides continuity, but it does not mean that every request is delivered immediately or that capacity is unlimited.

Yes, where those disciplines form part of the agreed service scope and capacity. The mix can evolve with priorities, but responsibilities and boundaries remain explicit so the engagement stays manageable and commercially clear.

It is the work of understanding how technology, information, processes and operating practices should change to support clearer organisational outcomes. The result should be a practical direction and sequence of decisions rather than a technology programme disconnected from real needs.

Not necessarily. The right decision may be to retain, improve, integrate, automate, replace or retire different parts of the estate. Those choices should be based on evidence about value, risk, cost, usability, dependencies and future requirements.

Yes. An assessment can examine platforms, workflows, data movement, suppliers, ownership, user needs, technical constraints and operational pain points. Its depth and outputs are agreed around the decisions the organisation needs to make.

Yes, and phased delivery is often more practical than wholesale change. Initiatives can be sequenced around dependencies, value, risk and organisational readiness, allowing evidence from each phase to inform what happens next.

Cost depends on the scope, complexity, content or data, integrations, assurance needs, delivery approach and ongoing responsibilities. Evoqode needs enough context to prepare a meaningful estimate or proposal, so there is no single price that applies to every project.

A fixed price may be appropriate where the scope, assumptions, responsibilities and acceptance criteria are sufficiently clear. Work with more uncertainty may be better structured through discovery, phases or an agreed capacity model. The proposal explains the commercial approach before work begins.

Ongoing hosting, care or managed digital work can be structured through a continuing arrangement where appropriate. The scope, capacity, responsibilities and commercial terms are defined explicitly; a retained service does not represent unlimited work.

Ownership, licensing, access and handover arrangements are defined clearly within the project agreement because they can vary by project, third-party technology and existing assets. The aim is to avoid unnecessary dependency on Evoqode while documenting any legitimate licensing or platform constraints.

The next step depends on the agreed engagement. It may involve handover and documentation, a defined support period, managed hosting and care, or an ongoing improvement programme. Post-launch responsibilities and coverage are confirmed rather than assumed to be automatically included.