I have seen the same thing happen after a website launches.
The project is described as flexible. It has a CMS, reusable components, and an editing interface. The team can update the copy and replace images.
Then a new service needs a different kind of page. The existing components cannot accommodate it, and the team has to bring the developer back in.
There will always be changes that require specialist support. But when everyday work repeatedly becomes a development task, it is worth asking whether the website was designed around the people responsible for it.
That question belongs at the beginning of the project.
Start with the team who will use it
Every designer, developer, and agency has preferred tools. Familiarity can lead to better implementation and a more efficient process. It can also narrow the options before the client’s needs are understood.
I love working with Webflow. For many of the brand and marketing websites I design and build, it offers a useful balance of visual control, structured content, and ease of management.
But preference is not a strategy.
Before recommending a platform, I want to understand:
- Purpose: What role does the website play in the business?
- Ownership: Who will manage it, and what technical experience do they have?
- Content: What will they publish or update, and how often?
- Independence: Which changes should they be able to make without support?
- Connections: Which business systems must the website work with?
- Growth: What new content, services, or markets might it need to accommodate?
A founder managing a small website independently has different needs from a marketing department publishing across several markets. Those differences should shape the recommendation before design begins.
Match the platform to the work
These requirements give you a basis for evaluating the options. Start with the website’s main job, then consider the team’s capacity to operate it.
Brand and marketing websites
For a website built around positioning, services and enquiries, consider visual control, content structure and how easily the team can create pages.
Webflow, Framer and Squarespace may all belong on the shortlist. The useful comparison is how each supports your actual designs, publishing needs and editing workflow. A small portfolio and a growing company website can require very different systems.
Content-led websites
If publishing is central to the organisation, look closely at approvals, permissions, categorisation, localisation and relationships between content.
WordPress, a marketing platform such as HubSpot, or a headless CMS may be worth evaluating. Test the full publishing process, including who writes, reviews, translates and maintains the content.
Commerce websites
When product sales are the website’s main purpose, evaluate the commerce operation first: catalogue management, payments, inventory, shipping and returns.
A commerce-focused platform such as Shopify is a natural starting point. Confirm that it supports the way the business sells, including any required integrations or market-specific needs.
Digital products and custom functionality
User accounts, specialised workflows and complex data may justify custom development. A headless CMS can form part of that setup when content needs to be managed separately from its presentation.
Be clear about who will maintain the system. Additional technical control brings ongoing responsibility, and the organisation needs the capacity or support to manage it.
These are starting points for a shortlist. Before deciding, verify current capabilities, plan limits and integrations against your requirements.
Test the promise of flexibility
A platform’s feature list will only tell you so much. The way the website is built determines how useful those features become.
Before committing, ask the designer or developer to demonstrate how the proposed setup would handle three tasks your team expects to perform. For example:
- Publishing a case study with images and related work.
- Creating a service page from the available components.
- Updating the navigation when you add a new section.
Ask who can perform each task, what permissions or training they need, and where specialist help would become necessary.
This makes “easy to manage” something you can evaluate.
The aim is enough freedom for the team to work confidently within a coherent design system. Content fields should make sense to the people filling them in. Components should support likely page variations. Editing controls should make routine changes straightforward while protecting the wider design.
Understand the commitment beyond launch
The build quote is only part of the cost.
Compare subscriptions, paid extensions, integrations, maintenance, training, and likely development support. A lower initial price may come with more ongoing work; a higher subscription may include services the team would otherwise need to manage separately.
Ask what happens if you change providers, too. Who controls the domain, hosting, and platform account? Can another specialist take over? What content can be exported, and what would need to be rebuilt?
A clear recommendation should explain these trade-offs in terms the client can use to make a decision.
Choose with the next chapter in mind
You cannot predict every future requirement. You can identify the changes already on the horizon and make sure the website has room for them.
The final decision should leave you clear on three things: what your team can manage, where support will be needed, and what the system will cost to operate.
That clarity gives the project a stronger brief and the working relationship a better foundation. Future collaboration can focus on work that benefits from creative and technical expertise, with everyday publishing already in the team’s hands.
If you are planning a new website and need help choosing the right platform or setup, I can help define the requirements and direction before design and development begin.
