The agency leaves at launch
The build ships, the team moves on, and the people who understood the component system are gone. The next small change costs more than it should because someone has to learn the site first.
A Webflow site is never finished. We hold the build after launch: same-day changes, a team that already knows how it was made, and a monthly record of everything that shipped.
The build ships, the team moves on, and the people who understood the component system are gone. The next small change costs more than it should because someone has to learn the site first.
Six months of quick edits by different hands leaves a stylesheet nobody can reason about. Eventually a change in one place breaks a page nobody was looking at.
A pricing tweak or a new landing page joins a queue behind a roadmap. Marketing works around the site rather than through it, and the site stops reflecting what the company sells.
Copy changes, a new page from existing components, a broken link, a form that stopped posting. Requested in Slack, done the same day, without a ticket system in between.
Changes go through the component system rather than around it. A new page reuses what is there, so the site is as maintainable in year two as it was at launch.
Every month closes with what was requested, what shipped and what is queued. It is the answer to the question every marketing lead eventually gets asked about the retainer.
Copy, layout, new pages built from the existing component set, CMS updates and campaign landing pages. The work most teams cannot get onto a roadmap.
Forms tested, links crawled, speed watched, and integrations checked after they update themselves. Most site breakages are silent, and the point of this is to find them before a customer does.
The component library and style system kept clean as the site grows. Without this, a year of small edits costs you the rebuild you just paid to avoid.
The people who work on your site are the people who know it. Requests go to a shared channel, not a queue, and nobody has to re-explain how the build works.
Six months in, someone senior asks what the support retainer is actually buying. The honest answer is a stream of small things, and small things are hard to remember when nobody wrote them down.
So we write them down. Every request, what it was, when it shipped. The monthly record exists specifically so that question has an answer with dates in it rather than a feeling.
It also means cancelling is a decision you can make on evidence. We would rather that than a retainer that survives because nobody looked.
Most agencies quote a response time, which is the time until someone replies. That is not the number you care about. These are turnaround times, on Irish business hours, for work requested in the shared channel.
Anything that is a change rather than a build. Requested in the morning, live in the afternoon, with no ticket in between.
A campaign landing page, a new service page, a template variation. Fast because the component system already exists, which is the whole return on having built one.
Quoted separately and scheduled. The retainer covers continuous work, and nothing large gets quietly absorbed into it and slowed down for everyone else.
dYdX has run on same-day since 2025, across a market that does not close. Blueflame has been on the same arrangement for over eighteen months.
A clean component system. Every page is built from the same parts.
A rushed campaign page adds six one-off classes. Nobody notices.
Three people have edited the same section different ways. The parts no longer match.
A change in one place breaks a page nobody was looking at. Quotes come in for a rebuild.
Nothing on that timeline is anyone's fault. Each individual change was reasonable and urgent. The damage is cumulative, which is exactly the kind of damage no single person is responsible for catching.
Support is the thing that stops it. Changes go through the component system rather than around it, and the system gets tidied as it grows.
This is the least visible part of the retainer and the part that decides whether you are rebuilding in year two.
We have held the Blueflame site since launch: changes, CMS restructuring, campaign pages and monthly reporting, on one retainer and one report format the whole way through.

Ongoing changes to a live Webflow site: copy and layout edits, new pages built from your existing components, CMS work, form and integration fixes, speed and health checks, and upkeep of the component system so the build stays maintainable. It closes each month with a record of what shipped.
Small changes the same day, in practice. Anything larger gets scoped and scheduled, and you are told which it is when you ask rather than after you have waited. Requests come through a shared Slack channel.
Yes, after a review. We look at how the build is structured first, because a site with a broken class system costs more to change and you should know that before signing rather than three months in. If it needs work before it can be supported, we scope that separately.
Entirely. Webflow supports the platform: billing, hosting, bugs in the product. This is support for your site: the changes, the pages, the CMS and the system the site is built on.
It gets scoped as a project alongside the retainer. The retainer covers the continuous work, and a new template, a section rebuild or a migration is quoted on its own. Nothing large gets quietly absorbed and slowed down.
Yes, on notice. We would rather a retainer stayed because it is earning its keep, and the monthly record exists so that is a question you can answer with evidence instead of a feeling.