We have run other people's website estates for over a decade, which changes what you consider finished. Speed, accessibility, consent and maintainability get decided in the wireframes, not in a remedial project two years later.
Green Arrow Consultancy is a UK web development agency that builds marketing sites, web applications, ecommerce stores and multi-region website estates. Because we also manage estates of more than two hundred websites, performance, accessibility, privacy and maintainability are build requirements rather than post-launch repairs. Founded 2012, based in Cardiff, working across the UK, USA and EU.
Almost every website brief describes launch day. Very few describe the third year, when the marketing team has turned over twice, the plugin that powered the campaign landing pages has been abandoned by its author, the cookie banner is listing scripts that no longer load, and the person who understood the deployment process has left.
So we ask a different question first: who will be living with this site, and for how long. Green Arrow Consultancy has spent over a decade managing website estates for global consumer brands, passing two hundred managed sites in 2022. When you are the party who has to patch, re-test and explain a site for the next eight years, performance, accessibility, privacy and maintainability stop being cleanup and become build requirements with the same standing as the design.
That shows up in unglamorous ways. Shorter dependency lists, because every dependency is a future vulnerability notice. Content models a marketer can use without raising a ticket. Consent wired into how tags load rather than bolted on afterwards. A component library that has been through keyboard and screen reader testing before it appears on a single page.
It also means we argue with briefs. A carousel nobody scrolls past the first slide of, a hero video costing two seconds of load on a mid-range Android handset, a chat widget that drags in four third-party domains: these are decisions with a price, and the place to have that conversation is the wireframe, not the measurement review a year later.
Six shapes of work. The multi-region estate work is where a decade of managing other people's sites shows up most clearly.
Brand, product and campaign sites with content models built for people who publish weekly, editorial workflow that survives a legal approval step, and templates that do not break the first time somebody pastes in a long product name.
Portals, dashboards, booking and quoting tools and member areas with real permission models. For Healey Fox we built a property management system alongside the website and integrated it with Salesforce, which is the shape a lot of this work takes.
Custom Shopify themes and WooCommerce builds, with the platform decision made on merit rather than habit. Checkout performance, product data structure, tax and consent handling, and analytics wiring that makes reporting agree with the store.
One codebase, many markets, several languages and different privacy regimes per country. Shared components, local content ownership, per-jurisdiction consent, and a release process that does not need twelve regional sign-offs for a security patch.
Moving off an ageing CMS or a proprietary platform without losing rankings. Content audit, URL and redirect mapping, structured data preservation, and a rollback plan that has been tested rather than described.
A documented set of components with defined states, contrast-checked colour, sensible focus behaviour and real content examples. The asset that makes the next four projects fast, and the one most often skipped.
The tool follows the content model and the editing behaviour. Deciding the platform before those two are understood is how organisations end up paying twice.
There is no universally correct column. There is a correct one for your size, your publishing frequency and your appetite for owning risk.
| Template or site builder | Agency build | In-house build | |
|---|---|---|---|
| Upfront cost | Lowest | Middle, quoted against a written specification | Often highest once salaried time is counted honestly |
| Time to first launch | Days to weeks | Two to four months for a marketing site | Depends on competing internal priorities |
| Accessibility risk | High. Most templates fail WCAG 2.2 AA out of the box and you cannot fix what you cannot edit | Low if specified and tested, high if treated as an audit at the end | Variable, and usually unowned |
| Performance ceiling | Capped by the platform and its script payload | High. Budgets can be enforced in the build | High, if the team has time to tune |
| Ownership and exit | You rent. Export is partial and the design does not travel | You own the code, content and hosting accounts | You own everything, including the knowledge risk when people leave |
| Ongoing cost | Low licence fee, high hidden cost when you outgrow it | Predictable retainer, or your team plus documentation | Salaries, plus the rebuild after a key developer leaves |
| Who fixes it at 2am | Nobody. You file a support ticket | A named team with an agreed response time | Whoever is on call, if anyone is |
Template platforms are a good answer for a five page site with no compliance exposure. They stop being one when a legal team asks who is responsible for the consent banner.
Core Web Vitals are three measurements: Largest Contentful Paint, how long the main content takes to appear; Interaction to Next Paint, how quickly the page responds to a tap; and Cumulative Layout Shift, how much the page jumps while loading. Google reports them from real visits on real devices, which is why a Lighthouse score of 98 on a developer's laptop can sit alongside a failing field measurement.
The same handful of things dominate in practice. Images shipped at the wrong size and format. Web fonts that block text rendering. Third-party tags, which is almost always the biggest single item we find. A tag manager container carrying six years of marketing pixels will comfortably outweigh every optimisation the developers made, and nobody owns it because it was installed for a campaign that ended in 2021.
Every tag is a request to a domain you do not control, running code you did not write, on a page where your users are identifiable. Auditing the container removes weight and reduces consent exposure in the same pass, which is why performance work and consent work tend to arrive together. Where the measurement genuinely matters, server-side tagging in Google Tag Manager moves collection off the critical path.
Optimisation projects regress. A performance budget, enforced in the build so a page exceeding its weight or blocking time fails before it ships, does not. We set budgets during specification, test on mid-range hardware and throttled connections rather than office broadband, and keep field data visible after launch so a regression is a notification rather than a discovery six months later.
An audit at the end of a project produces a bill. An accessible design system at the start produces a site. Our accessibility practice feeds straight into how we build.
Six stages. The first decides whether the other five are pleasant.
Audience, content inventory, integrations, jurisdictions, approval chain and the measure that says it worked. Fixed price, and precise enough to price a build against. If you take that document elsewhere it still works, which is deliberate.
Templates, components, fields, relationships and editing permissions decided first. Designing before the content model exists is how sites end up with eleven near-identical page types and an editor who is frightened of the CMS.
Components with defined states, contrast-checked colour and documented keyboard behaviour. Real content in the designs, including the long product name and the empty state.
Front end, CMS configuration, integrations, consent and analytics wiring. Performance budgets and accessibility checks run in the pipeline, so a regression fails the build rather than reaching a review.
Cross-browser and device testing, axe plus manual keyboard and screen reader passes, Core Web Vitals on throttled mid-range devices, consent verified per jurisdiction, and a checked redirect map.
Deployment, monitoring, analytics and search console verification, documentation written for the next team, training, and an explicit decision about who owns the site from Monday morning.
The honest answer is a range, and any agency giving you a single number before discovery is either guessing or quoting for something narrower than you asked for. The same brief, word for word, can be a six week build or a nine month programme depending on how many templates and languages exist, how many systems it has to talk to, and how many people hold approval rights.
So we price in two stages. Discovery is fixed price and short, and produces a written specification with the template count, the integration list and the acceptance criteria in it. The build is then fixed price against that specification. Change requests stay visible as changes rather than becoming an argument at the end.
Rarely into the front end. It goes into integrations with systems never designed to be talked to, into translation and approval workflow on multi-region estates, into the content nobody budgeted time to write, and into the third round of stakeholder review. Estimating those honestly at the start is most of what separates a project that lands from one that quietly doubles.
A launch is worth marketing. For Scottish Hampers we ran a promotional and social campaign that reached 191,000 people with 84,100 engaged in the first three days, which is the kind of load a site should be built to absorb rather than fall over under. The more important question is the quiet one: who patches this, who watches the vulnerability feed, who notices when the consent banner stops matching the privacy policy, and who re-tests accessibility when new campaign templates land.
Either that is your team, with documentation and training from us, or it is ours through website management. What it must not be is nobody, which is the default state of most websites we are asked to audit.
Green Arrow Consultancy has developed and managed my websites for Healey Fox for over 8 years now. I have been delighted with his online media and website knowledge and skills, the great value they offer and the high level of customer service and care they have offered us.
A working website, and the less visible things that decide whether it still works in five years: a content model your marketers can use without raising a ticket, a component library that has passed keyboard and screen reader testing, a deployment setup you can take elsewhere, a consent and analytics configuration that matches what your privacy policy claims, and documentation written for the next team. An agency that hands over a design and a login has done about half the job.
The honest answer is a range, because the same brief can be a six week build or a nine month programme depending on how many templates, languages, integrations and approvers are involved. A small marketing site on an existing design system is the cheapest thing we do. A multi-region estate with translation workflow, consent by jurisdiction and a Salesforce integration is the most expensive. We scope in two stages: fixed price discovery, then a fixed price build against the specification it produces.
A focused marketing site usually runs eight to fourteen weeks from kick-off to launch. Web applications and multi-region estates run longer and are released in stages. The schedule is almost never limited by development. It is limited by content, by legal review, and by how quickly the people who approve the design can get in the same room.
WordPress is right when a marketing team publishes and lays out pages constantly and the site is mostly content. A headless CMS is right when the same content must appear in several places, or when regional sites share one content library. A custom application is right when the thing being built is software with a front door, not a website with a form. Most bad builds are a good tool used for the wrong one of those three jobs.
Yes, and we usually recommend it over a self-hosted store when the commerce requirement is conventional. Shopify absorbs the payment, tax, fraud and PCI burden that a WooCommerce build hands back to you, and it does not stop working because a plugin was abandoned. We build custom themes rather than buying one. Purchased themes are where most Shopify performance and accessibility debt comes from.
We build to WCAG 2.2 level AA by default, with EN 301 549 as the reference where public sector or European Accessibility Act obligations apply. Accessibility is checked at wireframe stage, designed into the component library, tested with axe and with a keyboard and screen reader, and re-tested at launch. Retrofitting costs several times what designing it in costs, which is the entire argument.
You do. Code lives in a repository you own or one transferred to you at handover, content is exportable, and hosting sits in your own accounts. We do not build on proprietary platforms that only we can maintain. If you move the work elsewhere in year three, nothing in the build is designed to make that painful.
Frequently, and it is a large share of our work. We start with an audit covering security posture, dependency and plugin health, performance, accessibility, consent and analytics accuracy, then produce a list split into fix now, schedule, and only worth doing at the next rebuild. Inheriting a site is often cheaper than replacing it, and we will say so when it is.
Either you run it, with documentation and a handover session, or we do, through our website management service. Sites decay predictably: dependencies age into vulnerabilities, third-party tags accumulate, consent configurations drift from the privacy policy, and accessibility regressions arrive with new content. The build is the beginning of the cost, not the end of it.
We will tell you what platform the requirement actually points at, what it is likely to cost as a range, and which parts of the brief are going to be expensive. Discovery is fixed price.