More insights.
Subscribe to our newsletter.
Deep dives into design thinking, creative process, and the intersection of business and aesthetics.
The only future-proof website is one you can change safely.
"We want it to be future-proof." It turns up in a lot of briefs, and the appeal is obvious: spend enough now and you get a website that stays sound for years without much more attention. The job gets finished.
It doesn't, and a site built on that assumption is usually the one that ages fastest. Browsers and search engines change underneath you, and so does the law: the European Accessibility Act, which has applied since June 2025, added accessibility requirements for many businesses that sell to consumers online. A site designed as a finished object starts falling behind the week it launches.
So we don't try to build for permanence. We build sites that are safe to change, which is a more useful thing to pay for.
Adaptability is decided at the start of a build
Adaptability is an engineering constraint: the system is designed to take new things without breaking what's already there. You can swap the payment provider or launch a new service line without pulling up the foundations, and a change to the type hierarchy becomes a small job.
The practical test is whether you can release a change without anyone holding their breath. Ask whoever runs your site how long a new service page would take, and whether it needs a developer: the answer says more about how future-proof the site is than anything in the original proposal. When changes are routine, the big redesign every three years turns into a steady run of small, safe updates that go out every week.
Websites age from two directions
The first is technical. Plugins update and start to conflict with each other, and the APIs a site depends on get retired. None of it is dramatic, but leave it alone and the code rots.
The second is people, and it tends to do more damage. A huge uncompressed photo goes on the homepage. A manager asks for a quick pop-up. A new page is copied from an old one and adjusted by eye. Each change is small and reasonable at the time.
A slower site is the first cost. The bigger one comes when the whole thing is so cluttered that the only option is to scrap it and start again, which is the expensive rebuild the future-proof brief was meant to avoid.
Guardrails in the build, so nobody has to police it
Relying on everyone to be careful doesn't hold up for long, so we put the limits into the build itself. A performance budget sets a ceiling on how heavy a page can be. Go over it and the build fails, so the change doesn't go live until it's fixed. That can feel obstructive when you just want a new banner up, but speed has to be defended or it drains away, and it affects how many visitors stay long enough to enquire.
Component discipline does the same job for the design. If a page needs a button, it uses the button component. Nobody invents a new one because the existing one felt a bit plain that day. That keeps the design consistent and the code clean long after the launch.
The payoff of a component-based system, whether it's built in Framer or as a headless build, is that improvements travel. If we rework the "Book now" module so that more people use it, the better version appears on every service page and article that carries it, the same day. It also stops your older pages drifting visibly behind the newer ones.
Content models that expect the business to grow
A lot of sites break because content was treated as something to pour in at the end. We plan the content model around where the business might go: what happens when you open in Cork, or start a B2B arm alongside the consumer side.
A well-planned model lets you add a new location or a whole new service area without damaging the structure. Your schema stays stable and the navigation stays logical as the business grows from one offering to several.
A yearly roadmap in place of the three-yearly rebuild
Instead of saving up for a large capital project every few years, budget for steady progress. Well-run digital products work to a roadmap with no fixed end date. A typical year might look like this:
First quarter: page speed and Core Web Vitals.
Second quarter: conversion work on forms and calls to action.
Third quarter: extending the content library.
Fourth quarter: reviewing what the year changed and setting next year's themes.
Work goes out in monthly releases under each quarter's theme, and each release is measured against something. The trade-off is that you're paying for ongoing work, and someone on your side has to make decisions every month. Name that person before the build starts, because a roadmap nobody owns drifts back into the three-yearly rebuild.
Related Brainstorm services and work
Website systems and ongoing support · View scalable website case studies · Plan a maintainable website
Updated 24 September 2026. Dave Curtin, founder and Creative Director of Brainstorm, leads website strategy, brand direction and technical delivery for Brainstorm clients.
The only future-proof website is one you can change safely.
"We want it to be future-proof." It turns up in a lot of briefs, and the appeal is obvious: spend enough now and you get a website that stays sound for years without much more attention. The job gets finished.
It doesn't, and a site built on that assumption is usually the one that ages fastest. Browsers and search engines change underneath you, and so does the law: the European Accessibility Act, which has applied since June 2025, added accessibility requirements for many businesses that sell to consumers online. A site designed as a finished object starts falling behind the week it launches.
So we don't try to build for permanence. We build sites that are safe to change, which is a more useful thing to pay for.
Adaptability is decided at the start of a build
Adaptability is an engineering constraint: the system is designed to take new things without breaking what's already there. You can swap the payment provider or launch a new service line without pulling up the foundations, and a change to the type hierarchy becomes a small job.
The practical test is whether you can release a change without anyone holding their breath. Ask whoever runs your site how long a new service page would take, and whether it needs a developer: the answer says more about how future-proof the site is than anything in the original proposal. When changes are routine, the big redesign every three years turns into a steady run of small, safe updates that go out every week.
Websites age from two directions
The first is technical. Plugins update and start to conflict with each other, and the APIs a site depends on get retired. None of it is dramatic, but leave it alone and the code rots.
The second is people, and it tends to do more damage. A huge uncompressed photo goes on the homepage. A manager asks for a quick pop-up. A new page is copied from an old one and adjusted by eye. Each change is small and reasonable at the time.
A slower site is the first cost. The bigger one comes when the whole thing is so cluttered that the only option is to scrap it and start again, which is the expensive rebuild the future-proof brief was meant to avoid.
Guardrails in the build, so nobody has to police it
Relying on everyone to be careful doesn't hold up for long, so we put the limits into the build itself. A performance budget sets a ceiling on how heavy a page can be. Go over it and the build fails, so the change doesn't go live until it's fixed. That can feel obstructive when you just want a new banner up, but speed has to be defended or it drains away, and it affects how many visitors stay long enough to enquire.
Component discipline does the same job for the design. If a page needs a button, it uses the button component. Nobody invents a new one because the existing one felt a bit plain that day. That keeps the design consistent and the code clean long after the launch.
The payoff of a component-based system, whether it's built in Framer or as a headless build, is that improvements travel. If we rework the "Book now" module so that more people use it, the better version appears on every service page and article that carries it, the same day. It also stops your older pages drifting visibly behind the newer ones.
Content models that expect the business to grow
A lot of sites break because content was treated as something to pour in at the end. We plan the content model around where the business might go: what happens when you open in Cork, or start a B2B arm alongside the consumer side.
A well-planned model lets you add a new location or a whole new service area without damaging the structure. Your schema stays stable and the navigation stays logical as the business grows from one offering to several.
A yearly roadmap in place of the three-yearly rebuild
Instead of saving up for a large capital project every few years, budget for steady progress. Well-run digital products work to a roadmap with no fixed end date. A typical year might look like this:
First quarter: page speed and Core Web Vitals.
Second quarter: conversion work on forms and calls to action.
Third quarter: extending the content library.
Fourth quarter: reviewing what the year changed and setting next year's themes.
Work goes out in monthly releases under each quarter's theme, and each release is measured against something. The trade-off is that you're paying for ongoing work, and someone on your side has to make decisions every month. Name that person before the build starts, because a roadmap nobody owns drifts back into the three-yearly rebuild.
Related Brainstorm services and work
Website systems and ongoing support · View scalable website case studies · Plan a maintainable website
Updated 24 September 2026. Dave Curtin, founder and Creative Director of Brainstorm, leads website strategy, brand direction and technical delivery for Brainstorm clients.