The next website

Text to follow…

The next website framework

Although a website design refresh (look and feel) was undertaken in 2020, the bespoke framework* that underpins it is now in its 10th year, and although it continues to work perfectly, having a succession plan in place would be advisable.

Bespoke builds are especially good at going beyond their expected lifespans, but the nature of all technology is to have its time and then be superseded. The current framework could go beyond 10 years (online May 2015), which is 3 years beyond what we originally estimated, but the risk of issues will increase as the software ages out**. By issues, we don’t just mean security or maintenance, but also scalability, adding new features and so on.

At this stage, we would advise against developing it further, instead opting to keep it supported/maintained until you wish to replace it. As for when to replace, that is not our decision to make, but we would recommend starting development at least 6 months ahead of the desired live date e.g. January 2027 for June 2027.

As for what type of website to build next, a standard, bespoke developed website would offer the best mix of longevity, scalability and ROI. As with the current website, it will be mobile-first, fast loading and easy to use; as this is now the baseline expectation across all age groups. Users want instant access to relevant information, intuitive navigation, and a seamless experience whether they’re browsing on a phone, tablet, or desktop.

The alternative is a progressive web app (PWA), which is a website that behaves like an app, it offers an extra degree of engagement, but we’d need to research further to see if it would be viable long-term. However, a bespoke website could be converted to a PWA later if requested.

* Front-end (Design) = the stuff you see / Back-end (Framework) = the stuff you don’t see.

** Software has an age cycle, when a new version is released, the old one will be slowly phased out. It will be supported initially, then only security patched, before support is withdrawn completely. At this point, the software can still be used, but it will become more unstable and insecure/hackable over time.

Maintenance Schedule (Non-Content Maintenance)

Before we talk about upkeep, it helps to understand how these projects are built.

Think of your website like a well-designed property. When properties follow a standard layout and building method, any future builder can walk in and instantly understand where everything is and how it works. We do the same with software.

We follow something called Design Patterns – these are industry-standard building plans for software. They never change, and every experienced developer understands them. This ensures that any future developer can understand your system easily, even if they didn’t build it.

Three Key Concepts (Explained Simply)

Before we talk about upkeep, it helps to understand how these projects are built.

1. Frameworks – the building structure

A framework is like the foundation and structure of a building. It sets out the shape, the layout, and the rules. Developers build within that structure but do not change the structure itself.

2. Libraries – tools you use during construction

A library is like a tool or fixture used while building — for example, “installing electrics” or “fitting a boiler.” They’re optional tools used to add certain features.

3. Programming Languages – the building materials

These are the materials everything is made from. Some materials (languages) update every few years, requiring maintenance to stay secure and compatible.

Your Project Contains Three Main Parts:

Backend → the behind-the-scenes engine that runs everything (like the utilities in a property: water, power, heating).

Public Website → the part everyone sees (your shopfront).

Admin Website → your internal system (your office area).

How We Build Your System

The backend uses a framework called the AFTC Framework, built using the established “MVC” design pattern. This pattern never changes and is widely known in the industry. The goal is stability, simplicity, and long-term maintainability — meaning future developers won’t struggle to understand it. The public and admin websites also use the same design pattern. This makes the entire project predictable, consistent, and easy to work on over time.

A Caution About Modern Development Trends

Many agencies insist on using fast-moving tools like React, Angular, and similar systems. While they are popular, they update frequently – often several times a year.

Think of these like a property management system that changes its rules every few months. Even if your building hasn’t changed, you still have to bring in tradesmen repeatedly just to keep everything compatible.

Because of how fast these tools change, returning to update a project after 2+ years can be much more time-consuming and costly. The AFTC Framework avoids this problem. It only needs updates when the main programming language updates – which is far less often.

Estimated Maintenance Schedule

Backend (engine of the system):

Should be updated roughly every 3–4 years.
Updates depend on how much the underlying “building materials” (language) have changed.
You can leave it running longer, but like an old boiler, the security risk increases over time.

Frontend (public website + admin website):

The core “materials” rarely change.
The tools used during development change more often.
Suggested approach: quick annual check-up to make sure everything still runs smoothly.
If small fixes are needed, doing them early prevents large, expensive jobs later.
These updates don’t change how your website looks or works — they simply keep it healthy.

Support & Changes

Whenever you need new features, adjustments, or support, just send an email. We’ll estimate the time and work required before anything starts.