Websites

Yes. Mosaic is built on WordPress, which has broad integration capability. We’ve connected Mosaic sites to CRMs, marketing automation platforms, analytics stacks, and bespoke back-office systems. Integration requirements are mapped during the discovery phase so they’re designed in from the start, not retrofitted later. If you have a specific platform in mind, we’re happy to discuss what’s involved.

What this means for you: Bring your list of systems to the first conversation. Integration feasibility is usually clear early, and it shapes a lot of what follows.

It can work well, and there are genuine advantages – the brand and digital expression are developed together, which can produce more coherent results than handing a finished brand to a separate web team later. But it requires careful sequencing and discipline.

The risk is that the web project starts before the brand is stable. If you begin building pages before the identity is signed off, you'll either have to rework them later or lock the brand too early to avoid that rework. Either way you lose something. A combined programme needs a clear checkpoint between brand completion and web build commencement.

For financial services specifically, there's an additional consideration: brand assets and website copy will both go through compliance review, and it helps to sequence that so you're not getting sign-off on two major pieces of work simultaneously if your compliance function has limited bandwidth.

What this means for you: If you're running brand and web together, agree on the sequencing upfront. Brand strategy and identity should be complete and approved before the web design phase begins. Web copy can often run in parallel with identity work, but the final visual treatment needs to be stable before the site design is locked. Build that checkpoint into the project plan explicitly.

Absolutely. Whether it’s your CRM, marketing automation platform, analytics tools, or back-office systems, we build seamless integrations that make your website work harder.

We’ll map out what you need during discovery and ensure everything connects smoothly, so your teams have the data they need, and your customers get a frictionless experience.

What this means for you: Integrations are usually the part of a build that surprises people on both cost and timeline. List every system you’d want connected before asking anyone for a quote.

A CMS makes sense when people who aren't developers need to update the site regularly. If you're a marketing team publishing blog posts, updating team pages, or changing event listings, a CMS gives you the ability to do that without raising a ticket with your agency or developer. That independence has real value.

Static sites – where content is baked into the files at build time rather than pulled from a database – are faster, simpler, and more secure by default. They work well for sites that don't change often, or where all content updates are made by developers anyway. They're increasingly popular for product documentation and technical sites. The build process can be a bit more involved when you do need to make changes, though modern static site generators have improved significantly on this.

For most businesses with any meaningful marketing function, a CMS is the right call. The freedom to publish and update without a developer is worth the added complexity. For a simple corporate site that changes once a quarter and whose content is always reviewed by the same two people, a static approach is worth considering.

What this means for you: Think about who will update the site after launch, how often, and what kind of changes they'll need to make. If the honest answer is 'it'll probably be a developer or the agency doing most changes,' a static site might be cleaner. If marketing own the content roadmap, get a CMS.

A staging environment is a copy of your live website hosted somewhere that isn't public-facing. It's where you test changes before they go live – code updates, CMS upgrades, design changes, new integrations. Changes are tested on staging, verified, then deployed to production.

If you're making any significant changes to your website – even plugin updates on a WordPress site – you should be doing it on staging first. The consequences of updating something on a live site and breaking it are real: downtime, lost conversions, potential data issues. The consequences of breaking staging are nothing.

Some hosting environments include staging as a feature. Others require it to be set up separately. It's not expensive, and it's a standard part of how professional web teams work. If your agency or hosting provider doesn't offer staging, or hasn't mentioned it, ask about it.

What this means for you: If you don't currently have a staging environment, ask your agency or hosting provider to set one up. If you're on a basic shared hosting plan, you may need to move to a more capable setup. The cost of this is almost always justified by the first time it prevents a live-site incident.

Yes. The FCA's definition of a financial promotion includes 'any communication in the course of business.' That covers your website, your email marketing, your social media accounts, and any paid advertising. The fact that something is on Instagram or X rather than a printed brochure doesn't place it outside the regime.

The rules apply to the substance of the communication, not the channel. A paid social ad that doesn't include appropriate risk warnings, or a LinkedIn post by a firm employee that could be interpreted as encouraging investment, can each constitute a non-compliant financial promotion.

There are some exemptions – one-to-one communications, for example, are treated differently to broadcast communications. But anything published to an audience, on any channel, that relates to a regulated activity should be treated as in scope until you have a clear basis for why it isn't.

What this means for you: Build a review process for all externally published content, not just formal campaign materials. That includes social media, blog posts, and website copy updates. The effort required to comply doesn't have to be enormous if the process is well-designed – a light-touch compliance check that takes ten minutes per piece of content is manageable and significantly reduces risk.

Compliance is baked into everything we do. We know FCA guidelines, accessibility standards, and data protection requirements inside out – because in financial services, getting it wrong isn’t an option.

From risk warnings to cookie consent and clear customer communications, we build compliance into the user journey without compromising on design or experience. You get a website that protects your customers and your reputation.

What this means for you: Compliance is far cheaper designed in than retrofitted. Bring your compliance team into the project at discovery, not at sign-off.

Automated tooling first – a scan gives a top-level sweep of a page or component, flagging where problems are and what’s causing them. Then the checks automation handles badly: whether the page can be navigated by keyboard alone, whether colour contrast holds up across the palette, and whether images carry useful alternative text rather than filenames or decorative clutter.

But automated tools reliably catch only a portion of WCAG failures – broadly the machine-checkable ones. Whether alt text is helpful, whether focus order makes sense, whether an interaction is comprehensible through a screen reader: none of that is answered by a scanner returning green.

So for a proper audit we work with a specialist partner whose testing is carried out by people who use assistive technology day to day, on sites like yours. That’s a fundamentally different exercise from a developer running a checker. It surfaces the problems that matter to real users – the journey that technically passes every automated test and is still unusable in practice.

We offer that as a service, and we’d recommend it for any site where accessibility carries regulatory weight or where your customers include a significant number of people with access needs. Which, in financial services, is all of them.

What this means for you: If a supplier tells you a site is accessible because an automated scan came back clean, push harder. That’s a starting point, not a conclusion – and it’s not what a regulator or an ombudsman would accept either.

A straightforward brochure website redesign for a small-to-medium business – ten to twenty pages, standard functionality, an established brand – typically takes three to five months from kick-off to launch. More complex projects, or ones involving significant content production, user research, or phased rollouts, will take longer.

Where timelines go wrong is usually in the content phase and the review cycle. Agencies can build faster than most clients can produce, approve, or supply content. If you're going into a redesign without a clear plan for who's writing copy, who's signing it off, and when – you'll hit delays. Similarly, if you have multiple stakeholders with sign-off authority who aren't aligned on the brief, you'll end up cycling through rounds of amends that nobody anticipated.

Agencies that quote very short timelines – 'six weeks to launch' for a substantial site – are either cutting things out or setting expectations they won't meet. It's worth asking what specifically would be delivered in that timeframe and what would follow in a second phase.

What this means for you: Build the content plan before you start the design process, not after. It's the single biggest variable most clients underestimate. If you don't have internal resource to handle copy, factor content production into the agency scope and budget from the start.

There's no rule. The 'redesign every three years' thing you'll sometimes hear is more a product of agency business development cycles than any genuine insight about website lifecycles. Some sites look and perform perfectly well at five years old. Others are a liability at two.

The triggers that warrant a redesign are more useful than a calendar. If the site is no longer converting, if the brand has changed significantly, if competitors have moved on while you haven't, if it's technically difficult to update, or if the user experience has been generating complaints – those are real reasons. 'We haven't done anything in a while' isn't.

That said, regular investment in your website is usually more cost-effective than periodic large-scale redesigns. Iterating based on user feedback and performance data – improving key pages, testing different approaches – tends to produce better results than waiting until the site is bad enough to justify starting again.

What this means for you: Set up at least basic analytics and review them quarterly. If you can see where users are dropping off, which pages have high exit rates, or what search terms are bringing people to the wrong place, you have a basis for making targeted improvements. That data also makes the case for budget much easier to build than a vague 'we need a new site.'

Our recommendation is selective rather than all-or-nothing, because the crawlers are not all doing the same job.

Some fetch a page in order to answer a live question and cite you – the search-and-answer bots behind ChatGPT search, Perplexity and similar. Blocking those removes you from the answer entirely. If someone asks an assistant which providers do what you do, you simply aren’t a candidate. For most clients that’s a straightforward loss with no compensating benefit.

Others crawl to build training corpora. There’s no citation, no referral, and no direct return to you. Whether to allow that is a judgement call rather than an obvious yes, and it’s reasonable to decide differently about it.

One detail worth knowing, because it catches people out: the control governing Google’s AI training is separate from Google Search indexing. Opting out of the former does not harm your search rankings. A number of firms have blocked more than they intended by assuming otherwise.

This landscape shifts – bots get renamed, new ones appear, and what a given crawler does changes. It’s worth reviewing periodically rather than setting a robots.txt in 2026 and forgetting it.

What this means for you: Look at your robots.txt and check what you’re currently blocking and why. A surprising number of organisations are invisible to AI answers because of a blanket rule somebody added defensively without understanding what it covered.

The right answer depends on why you're considering it. If your current platform is working – content editors can update it without help, it performs well, it's maintained – the case for migration is weaker than it might seem. Migrations carry risk and cost, and 'WordPress is popular' isn't a reason to move if what you have is functional.

Reasons that might actually justify migration: the current platform is end-of-life or no longer supported; it requires significant developer involvement for content updates that should be self-service; it's poorly performing technically; or the agency that built it is now your only viable route for maintenance. Any of those is a reasonable basis for considering a move.

WordPress makes sense as the destination when you need a large content editing team, a rich plugin ecosystem, or a platform with a very wide pool of developer support. It's not always the right answer – there are platforms that are simpler, faster, or more appropriate depending on your needs.

What this means for you: Before committing to any migration, document what's wrong with the current setup and check whether those problems could be solved without migrating. Sometimes a CMS upgrade, a caching layer, or a different hosting environment fixes what seemed like a platform problem. Migration should be a last resort, not a default recommendation.

We build to WCAG AA as a minimum across the components we produce. That’s our default standard rather than an upgrade you have to ask for.

AA is the level most regulatory and procurement frameworks reference, and for financial services it’s the sensible baseline – your customers include people using screen readers, keyboard navigation, magnification and voice control, and a meaningful proportion of them are managing money in ways where a broken journey has real consequences.

Accessibility is confirmed as a requirement during discovery, including the WCAG level you need and any regulatory driver behind it, so it shapes design and build rather than being assessed at the end.

What this means for you: Decide your target level before design starts. Retrofitting accessibility into a finished design is expensive and usually produces a worse result than designing for it from the outset.

Websites can cost anywhere from a few thousand pounds to several hundred thousand, and both ends of that range can be the right answer depending on what you need. The variation isn't random – it reflects differences in scope, complexity, and how much strategic and creative thinking is involved.

A brochure site with five to ten pages, a CMS, and a standard set of templates will typically sit in the £10,000-£25,000 range at a competent agency. Add e-commerce, a complex integration with a CRM or data feed, a bespoke design system, or significant content production, and that number climbs quickly. Enterprise-scale builds – the ones involving multiple stakeholders, phased delivery, custom functionality, and accessibility auditing – can run to £100,000 or more.

Where agencies tend to differ is in how much thinking sits behind the build. A low-cost provider might deliver a functional website with a purchased theme and light customisation. A full-service agency working on the same brief might spend weeks on user research, information architecture, and design iterations before a line of code is written. Whether that additional work is worth paying for depends on your business, your users, and how much the website has to do.

What this means for you: Be specific about what you need before you ask for quotes. 'A new website' is too vague to price accurately – you'll get wildly different numbers because agencies will be guessing at your scope. The more clearly you can describe the functionality, user types, volume of content, and existing integrations, the more useful the quotes will be.

A standard WordPress build gives you a blank canvas – flexible, but with no guardrails. Mosaic replaces that with a structured set of branded components specific to your organisation, so your team can update and build pages without breaking layouts or drifting off-brand. On top of that, you get a full audit trail, structured asset management, accessibility checks in the editor, and centralised security patching across the platform. It’s the difference between a website you launch and a website you can confidently run.

What this means for you: Flexibility and governance pull against each other. Decide which your team needs more of before you choose a platform, not after.

We don’t just hand you a website and walk away. We combine strategic UX/UI design with robust development and ongoing hosting and management. Plus, we build sites on Mosaic™– our re-engineered WordPress CMS designed specifically for financial services. 

It gives your marketing team intuitive visual editing, custom branded blocks, and the ability to update content in minutes without breaking layouts or relying on developers. That means your site stays fresh, on-brand, and working hard for your business.

What this means for you: Ask any agency what happens after launch. The answer tells you whether you’re buying a project or a working relationship.

The answer varies by agency, which is one of the reasons website quotes are hard to compare. A baseline redesign typically includes discovery and scoping, information architecture, UX wireframes or prototypes, visual design, front-end build, CMS integration, basic on-page SEO setup, and browser and device testing. Some agencies include content migration; others don't. Most don't include content writing.

What commonly falls outside scope: copy and content creation, photography, video production, complex third-party integrations, ongoing hosting and maintenance, accessibility auditing beyond basic checks, analytics configuration, and performance optimisation beyond standard practice. Those aren't unreasonable exclusions – they're each a body of work in their own right – but you need to know they're not in the baseline before you compare quotes.

The things most likely to cause unexpected costs mid-project: content that arrives late or in a different format than expected, feedback from stakeholders who weren't involved in the original brief, requests to add functionality that wasn't mentioned upfront, and integrations that turn out to be more complex than originally assumed.

What this means for you: Ask for an itemised scope of work, not just a total figure. Then check it against your actual needs: do you have copy? Do you have photography? Will you need to connect to a CRM or data feed? Each gap between what's included and what you need is a cost you'll need to plan for.

A CMS migration involves moving your content from one platform to another – and depending on how different the platforms are, it can range from a well-structured process with limited risk to a complex, time-consuming exercise with plenty of opportunities for things to go wrong.

The main areas of risk are: content loss or formatting issues during migration; changes to URL structures that break existing inbound links and search rankings; integration failures when connecting the new CMS to third-party systems; and the time required to train content editors on a new interface. None of these are unavoidable, but they all need to be planned for.

A professional migration includes a URL redirect mapping exercise, so that your existing search rankings aren't lost because pages moved. It includes a thorough content audit to identify what's worth migrating versus what should be archived. And it includes a testing phase before the new site goes live, not just after.

What this means for you: If you're considering a migration, ask the agency specifically about URL redirect mapping and how they'll handle SEO continuity. That's the area where the most damage tends to happen when it's not planned for. Also ask whether there'll be a period of running both sites in parallel before the old one is switched off – that's usually worth the extra hosting cost.

A redesign changes how the site looks and how users move through it, while keeping – or largely keeping – the underlying technology. A rebuild replaces the technical foundation: the CMS, the hosting setup, the code architecture. The two can happen together, but they don't have to.

You might want a redesign without a rebuild if your current platform is fine but the site has become visually dated or the user experience has drifted. You might want a rebuild without a full redesign if the existing visual identity is broadly right but the site is built on something fragile, outdated, or unsupported.

Doing both at once is common, and it can make sense from a cost perspective – there are efficiencies when the same team is handling both simultaneously. The risk is that combining a technical migration with a full design overhaul increases the number of things that can go wrong. Separating them, with the technical migration happening first, sometimes produces better outcomes even if it means two projects rather than one.

What this means for you: Before scoping any project, work out what problem you're trying to solve. If the main issue is 'users can't find what they need,' that's a UX and information architecture problem – you may not need a full rebuild. If the main issue is 'our site runs on a platform that's no longer supported,' that's a technical problem that might not need a redesign. Being specific about the problem keeps the scope proportionate.