The Website Stack I Would Bet the Next Ten Years On

Key takeaways

• Plan for growth: Do not choose a website platform only for what the business needs today. Choose one that can still adapt when the business becomes 2x, 5x, or 10x more complex.
• Constraint Ceiling: Every platform has a Constraint Ceiling. The features that make a platform easier in the beginning can become the limitations that make growth harder later.
• Architecture and AI: AI does not make architecture less important. If building new features becomes cheaper, businesses will attempt more of them, which means the underlying system needs to tolerate more change.
• Architect for replacement: Do not look for technology you will never have to replace. Build so one layer can change without forcing everything else to change with it.
• Own the content layer: Treat case studies, products, testimonials, locations, resources, and SEO information as structured business data rather than content trapped inside individual pages.
• Choose the frontend for the job: Use Next.js when the experience behaves like software and Astro when it mostly behaves like a website.
• Reusable components: Build reusable components, not endless custom pages. Give marketing enough flexibility to move quickly without sacrificing consistency or creating a new development ticket for every campaign.
• Integrations: Treat integrations as part of the architecture. Your website will eventually need to communicate with CRMs, analytics, automation, internal APIs, and other systems, so build for that reality from the beginning.
• The exit door: Always consider the exit door. If you cannot easily move your content, code, data, or integrations elsewhere, convenience today may become lock-in tomorrow.
• The real bet: The real ten-year bet is not Payload, Next.js, or Astro. It is an architecture that gives you control, ownership, and the freedom to change when the business does.

Which website stack should you bet the next ten years on?

Webflow? Squarespace? WordPress? Next.js? Claude? Whatever new platform launches next month?

We justified this endless stream of website tools as progress, but then failed to ask whether all this progress is actually helping businesses make better decisions. Every few months, there is another platform, another framework, another AI website builder promising to make everything faster, easier, cheaper, better. And we feel compelled to follow along.

Businesses rebuild their websites because the old one suddenly feels outdated. Developers move to new frameworks because everyone else seems to be talking about them. Marketing teams adopt new platforms because they promise more control without developers. Then AI arrives and tells us that perhaps we do not need platforms, designers, or developers at all.

Do this. Try that. Migrate here. Rebuild there.

And yet, hardly anyone stops to consider the more important question:

What happens when the business itself changes?

A website with twenty pages, a blog, and a contact form may work perfectly today. But what happens when the company becomes twice its current size? What happens at five times the size? Or ten?

Suddenly, marketing needs fifty landing pages instead of five. SEO becomes an actual acquisition channel. Different teams need different permissions. The CRM needs to communicate with the website. Content needs to appear in multiple places without being copied manually. You need localisation, personalisation, customer portals, internal APIs, calculators, search, automation, or functionality nobody thought about when the website was first built.

The original website may well have been built properly for the business that existed at the time.

As the company grew, the assumptions underneath that website stopped matching the company.

And this is where a convenient technology decision can quietly become an expensive business decision.

We spend too much time asking which platform is the best today and too little time asking what happens when that platform is no longer the best tomorrow.

WordPress solved much of this problem for an earlier generation of the web. It gave businesses ownership, extensibility, a CMS their teams could use, and an enormous ecosystem around it. But over time, the same system can accumulate themes, plugins, database conventions, maintenance requirements, and technical dependencies that make change increasingly difficult.

The answer, however, is not to abandon WordPress simply because something newer exists.

That would be repeating the same mistake.

Payload CMS, Next.js, and Astro will change too. Ten years from now, we may be discussing technologies that do not even exist today.

So I would not bet the next ten years of a business on a framework.

I would bet them on an architecture.

An architecture where you own your content. Where your CMS does not dictate your frontend. Where your frontend does not dictate your business logic. Where integrations can be added as the company becomes more sophisticated. And, perhaps most importantly, where one part can eventually be replaced without forcing you to tear everything else down with it.

That is why, if I were building a serious business website today, I would build around Payload CMS, with Next.js or Astro depending on what the frontend actually needs.

Not because I believe these tools will remain fashionable for the next ten years.

But because the website you build today should not decide what your business is allowed to become tomorrow.

You're Not Choosing a Website Builder. You're Choosing Your Constraints.

"Should I use WordPress, Webflow, Squarespace, Shopify, Next.js…?"

This is usually one of the first questions businesses ask when they decide to build or rebuild their website. And understandably so. These are the names we know. These are the platforms people recommend. These are the tools we see compared in articles, YouTube videos, Reddit threads, and increasingly, conversations with AI.

But I think the question itself is wrong.

Because when you choose a website platform, you are not simply choosing what you can build.

You are also choosing what will become difficult to build later.

Most businesses make this decision based almost entirely on what they need today.

• Can our team edit the pages?
• Can we publish blogs?
• Does it give us control over SEO?
• Can we build this particular design?
• How quickly can we launch?
• How much will it cost?

These are all reasonable questions. In fact, they are questions you should ask.

The problem is that we tend to stop there.

Hardly anyone asks what happens when the website succeeds.

Because a successful website rarely remains the website that was originally built.

More pages are added. More people need access to the CMS. Traffic increases. The company enters new countries and suddenly needs multiple languages. Marketing wants hundreds or thousands of SEO pages. Sales wants the website connected to the CRM. Content needs to become more structured. Different visitors need to see different things. Forms become workflows. Workflows become automations. Internal systems need to exchange data with the website.

And eventually, something that began as a collection of pages starts behaving more like software.

This is where I think every website platform eventually encounters what I call the Constraint Ceiling.

Every platform makes certain decisions on your behalf.

That is precisely what makes these platforms useful.

Webflow does not hand you an empty server and ask you to figure everything out yourself. Squarespace does not expect a local business owner to design a database architecture before publishing an About page. Shopify does not require every store owner to build a commerce engine from scratch.

They reduce possibilities so that the remaining possibilities become easier.

And for many businesses, this is exactly what they need.

But there is another side to that convenience.

Every possibility removed for simplicity today is a possibility you may discover you need tomorrow.

You do not notice the Constraint Ceiling while your requirements remain underneath it.

You notice it when marketing asks for something the CMS was never designed to model. When an integration requires an awkward workaround. When a page needs functionality that does not fit neatly into the builder. When content needs to be shared across several systems. When the website needs to consume data from your own application.

Then something that once made your website wonderfully simple begins making the next stage of the business surprisingly complicated.

WordPress approaches the problem differently.

Rather than severely limiting what you can do, WordPress became successful partly because you can make it do almost anything.

Need a feature?

There is probably a plugin for it.

Need another feature?

There is probably another plugin for that too.

And this extensibility is one of the reasons WordPress became such an important part of the web. Businesses could own their websites, manage their content, install functionality, customise themes, optimise for search, and continue extending the same system for years.

But this creates a different kind of Constraint Ceiling.

A theme depends on a plugin. The plugin depends on another plugin. Another plugin stores important information according to its own database conventions. Custom functionality is added around all of this. PHP versions change. Plugins need updates. Security needs maintenance. Something that appears to be one website gradually becomes a collection of systems that happen to be running inside WordPress.

Again, the pattern applies to any system that takes on too much.

When too many responsibilities become inseparable from one system, every change begins to touch all of them.

And now AI has entered the conversation.

We are told that perhaps these architectural concerns matter less because AI can simply build whatever we need.

Describe the website.

Generate the component.

Create the API.

Build the feature.

Fix the bug.

Do this. Change that. Ship it.

And yes, AI can make development dramatically faster.

But generating code faster is not the same thing as deciding where that code should live, what it should depend on, how the data should be structured, or what happens when the requirement changes three years from now.

In fact, I think the opposite is happening.

AI makes architecture more important, not less important.

Because if the cost of producing new functionality falls, businesses will produce more functionality.

A marketing team that previously could afford five custom landing pages may now want fifty. A company that could not justify building an internal customer portal may suddenly be able to. Personalisation, automation, interactive tools, integrations, calculators, dynamic content: all become easier to attempt.

Which means the underlying website will be asked to change more often, not less.

Consider a fairly ordinary B2B company.

It begins with twenty pages.

A homepage. A few service pages. About. Contact. Some case studies. A blog. Maybe a form connected to someone's inbox.

Almost any respectable website platform can handle this.

Then the business grows.

Two years later, marketing wants programmatic SEO pages.

They want gated resources connected to HubSpot.

The company is expanding internationally, so now the content needs localisation.

Sales wants certain content for certain customer segments.

Someone wants an ROI calculator.

Customers need to log in and access private resources.

The website needs to pull information from an internal API.

And suddenly everyone is frustrated with the website.

But was the original website badly built?

Not necessarily.

Each demand came from the business becoming more sophisticated than the assumptions underneath its website.

This is why I do not think the goal should be to find a platform that can somehow predict every requirement your business will have over the next ten years.

Nobody can do that.

Your developers cannot.

Your CTO cannot.

WordPress cannot.

Payload cannot.

And certainly the latest AI website builder cannot.

Instead, we should build around a much simpler principle:

Architect for replacement.

Assume things will change.

Assume today's frontend framework may not be the frontend framework you want seven years from now.

Assume your marketing stack will change.

Assume your integrations will change.

Assume your business model itself may change.

Then build the website so those changes do not require everything else to change with them.

Your content should not have to disappear because you changed the frontend.

Your frontend should not have to be rebuilt because you changed your CRM.

Your database should not become inaccessible because you stopped paying for a particular page builder.

Your entire website should not need another six-month rebuild simply because one part of the system has reached the end of its useful life.

Think of two businesses starting from exactly the same place.

Both have the same twenty-page website.

The first builds everything around one tightly connected platform. Content, presentation, plugins, forms, integrations, and custom functionality gradually accumulate inside it.

Every few years, the business outgrows some important assumption underneath that platform.

So it rebuilds.

Then it rebuilds again.

The second company separates these responsibilities from the beginning.

Its CMS manages content.

Its frontend presents that content.

Its integrations connect external systems.

Its custom functionality lives where that functionality actually belongs.

As the business changes, individual parts can become more sophisticated without forcing every other part to follow.

Both companies will still change technology.

That is unavoidable.

But one treats technological change as a migration of the entire website.

The other treats it as the replacement of a component.

And this distinction is what eventually led me toward Payload.

Payload keeps many of the things that made systems like WordPress attractive in the first place.

There is an actual CMS that non-developers can use. Content can be properly structured. You can define access controls. You have APIs. You can manage authentication and files. You can extend the system when the business needs something that did not exist in the original requirements.

But instead of building all of this around a traditional WordPress architecture, Payload lives inside a modern TypeScript ecosystem and gives developers direct control over the code and underlying data.

That difference matters.

Not because TypeScript is fashionable.

Not because Next.js is fashionable.

And not because Payload happens to be the newer thing.

If that were the argument, we would simply be replacing one form of technology chasing with another.

Payload itself will evolve. Next.js will evolve. Astro will evolve. Some of the tools we use today will eventually be replaced by better ones.

And that is precisely the point.

The advantage is not that Payload, Next.js, or Astro can predict what your business will need ten years from now.

They cannot.

The advantage is that they leave you room to respond when those needs finally arrive.

The 5-Layer Website Stack Built For Change

Don't build a website. Build five replaceable layers that happen to produce a website.

We have become accustomed to building websites as one complete system, and for understandable reasons. It seems easier to keep the content, frontend, forms, integrations, and functionality together when one platform is capable of handling all of them. There are fewer decisions to make, fewer systems to connect, and, at least in the beginning, fewer things that appear capable of going wrong.

But this simplicity can become deceptive as the business grows.

A system that keeps everything together also makes everything increasingly dependent on everything else. The content becomes dependent on the CMS, the frontend becomes dependent on how that CMS expects pages to be built, integrations become dependent on plugins or platform-specific functionality, and custom features are gradually built around assumptions that were made years earlier.

And yet, hardly anyone stops to consider this: what happens when just one part of that system needs to change?

What happens when the frontend that made perfect sense today no longer makes sense five years from now? What happens when the company needs functionality the original platform was never designed to provide? What happens when the business wants to move its content somewhere else, connect it to another application, or replace an integration without rebuilding everything that has accumulated around it?

A monolithic system can often keep growing.

Many of them do.

The cost appears later: the more responsibilities we allow one system to assume, the more expensive it becomes to eventually separate those responsibilities again.

This is why I would rather build a website as five distinct layers: content, frontend, components, integrations, and infrastructure. They may work together to produce what the visitor experiences as one website, but they should not become so inseparable that changing one requires us to reconsider all the others.

A modular architecture may require us to make more decisions in the beginning, but those decisions are precisely what give us more freedom later.

Ten years from now, we should be able to replace a component.

We should not have to replace the entire system around it.

Step 1: Own The Content Layer

Payload CMS

We have traditionally treated website content as though it belongs to the pages on which it appears. A case study belongs to the case study page. A testimonial belongs to the homepage. A team member belongs to the About page. Product information belongs to the product page.

This seems perfectly reasonable when the website is small.

But then the same case study needs to appear on an industry page. The testimonial needs to appear on three service pages. Product information needs to be used somewhere else. A customer story that marketing originally created for the website suddenly becomes useful inside a sales resource, a campaign, a customer portal, or another application entirely.

So we copy it.

Then we copy it again.

And eventually, instead of maintaining the company's information, we find ourselves maintaining several different copies of the same information scattered across different pages and systems.

This is where I think we need to change how we think about content.

A case study is not a webpage. It is business data.

The same is true of products, team members, locations, resources, testimonials, SEO information, and much of the other content a business creates.

A website is merely one place where that information happens to be presented.

And yet, we often structure our entire content system around the assumption that the website, and sometimes one particular version of that website, is the only place this information will ever need to exist.

But what happens when it isn't?

What happens when the same customer story needs to appear on an industry page, a product page, the homepage, and inside a sales resource? Should four people copy and maintain four versions of it? What happens when the customer's logo changes, a statistic is corrected, or the company wants to use that same story inside an entirely different application?

This is why I prefer Payload CMS for the content layer.

Payload allows us to treat these things as structured collections rather than information permanently trapped inside individual pages. A customer story can exist once, with its customer, industry, product, testimonial, results, images, and other relevant information attached to it. The website can then decide where that story should appear without requiring marketing to recreate it every time.

The distinction is important.

The CMS should be responsible for what the content is.

The frontend should be responsible for how and where that content is presented.

We often combine these two responsibilities because doing so feels convenient, but then discover much later that the convenience came at the cost of portability.

Your content should therefore be treated like inventory in a warehouse, not furniture bolted to one house.

Inventory can be moved wherever it is needed. It can supply one store today and another tomorrow. The warehouse does not need to know every place an individual item will eventually go; its responsibility is to store and organise that inventory properly so it remains available when the business needs it.

Content should work in much the same way.

A customer story created today may only appear on one page. Tomorrow, it may appear across ten pages. Years from now, it may be consumed by a customer portal, an application, a campaign site, an internal sales tool, or something the company has not even thought about yet.

We cannot know where all of that content will eventually be needed.

But we can decide whether it will still belong to us when that need arrives.

Payload gives marketers an interface through which they can manage content without requiring that content to become inseparable from the frontend through which visitors happen to see it. Developers can structure the content according to the needs of the business, expose it through APIs, extend it when requirements become more sophisticated, and allow different experiences to consume the same underlying information.

And this is the larger point.

We should not own our content merely in the legal sense that we can export a database or download a file.

We should own it architecturally.

It should remain useful independently of the page builder, independently of the frontend, and, as far as reasonably possible, independently of the particular experience for which it was originally created.

Because if changing the way your website looks also forces you to reconstruct the information your business has spent years creating, then you never really separated your content from your website in the first place.

And once we separate those two things, another decision immediately follows:

If Payload is responsible for managing the content, what should be responsible for presenting it?

Step 2: Choose The Frontend For The Job

Next.js when the website behaves like software. Astro when it mostly behaves like a website.

We have become too comfortable choosing frontend frameworks by popularity rather than by purpose. A framework becomes fashionable, developers get used to it, agencies standardise around it, and suddenly the same tool is used for everything: marketing websites, SaaS applications, portals, documentation, ecommerce, all of it.

But a content-heavy website and an application are not the same thing.

One primarily needs to deliver information quickly, rank in search, publish content, and convert visitors. The other may need authentication, dashboards, personalised data, complex interactions, and application logic.

And yet, we often force both through the same frontend.

If a website mostly behaves like a website, Astro often makes more sense. It keeps things simpler and avoids shipping unnecessary complexity where it is not needed.

If the experience behaves more like software, Next.js is usually the better fit.

The contradiction is that we often choose the framework first and only later ask whether the website actually needed everything that framework brought with it.

So the better question is not, "Which framework is best?"

It is:

What is this frontend actually supposed to do?

Will users mostly read content?

Will they log in?

Will pages depend on personalised data?

Will the experience become increasingly interactive?

Will the website eventually behave more like an application?

And what happens if those answers change three years from now?

This is why separating the frontend from the CMS matters.

Payload can remain responsible for the content while Astro powers a marketing site and Next.js powers a customer portal. Both can use the same underlying content without forcing the business into one frontend forever.

Don't take a moving truck to buy groceries, and don't move houses in a hatchback.

The tool should match the job.

And more importantly, the architecture should leave you free to choose a different tool when the job changes.

Step 3: Build A Component System, Not A Collection Of Pages

We often say we want marketers to move faster, but then build websites where every new landing page still depends on a developer.

A new campaign needs a page. A new offer needs a different layout. A new case study needs another variation. So the development team keeps rebuilding the same kinds of sections again and again, while marketing waits for changes that should have been simple.

The contradiction is obvious.

We want flexibility, but we achieve it by creating more custom work.

A better approach is to build a controlled component system: reusable heroes, proof sections, testimonials, comparison blocks, FAQs, forms, pricing sections, and calls to action that marketing can combine without rebuilding the design each time.

Give the team LEGO, not wet cement.

The goal is not to let everyone design whatever they want.

It is to create enough flexibility that the website can change without becoming inconsistent.

Because what happens when marketing needs twenty campaign pages instead of two?

What happens when the company enters new markets, launches new products, or starts testing different messages every week?

Should every variation require another development ticket?

Or should the website already contain the building blocks needed to create those experiences safely?

A good component system turns the website from a collection of finished pages into a reusable system for producing new ones.

And as the business grows, that difference becomes enormous.

Step 4: Make Integrations First-Class Citizens

We often build websites as though they will remain isolated from the rest of the business, and then gradually connect everything through whatever plugin, extension, or workaround happens to be available.

The contact form starts by sending an email. Then it needs to create a lead in HubSpot. Later, that lead needs enrichment, routing, analytics, automation, and perhaps information from an internal system.

So we keep attaching things.

And yet, the more important the website becomes to the business, the less isolated it actually is.

The website eventually becomes part of the company's infrastructure.

This is why integrations should not be treated as additions we will somehow deal with later. They should be expected from the beginning, with clear interfaces between the website and the CRM, analytics, search, payments, marketing automation, internal APIs, and whatever systems eventually follow.

Build doors before you need to knock holes through the walls.

Because what happens when one simple form becomes five business processes?

What happens when customer data needs to move between several systems?

What happens when HubSpot is replaced, an internal API changes, or tomorrow's AI workflows need access to information nobody expected them to need today?

The goal is not to predict every integration.

We cannot.

The goal is to build a website that does not need to be torn apart every time another system needs to enter it.

Step 5: Optimise For The Exit Door

We spend enormous amounts of time deciding which technology to adopt, but almost none considering what happens when we eventually need to leave it. We compare features, pricing, performance, integrations, and ease of use, then build years of content and functionality around a system without seriously considering how much of it we actually control.

And yet, no technology remains the right choice forever.

The contradiction is that we choose platforms for flexibility, but often become less flexible the longer we use them. Our content becomes tied to their structure, our functionality to their ecosystem, our integrations to their APIs, and eventually something that once gave us freedom becomes the very reason we cannot easily change.

This is why one of the most important questions I ask about any technology is also one of the simplest:

How difficult will it be to leave?

Can we export the content? Do we own the database and code? Can another development team understand the system? Can the frontend be replaced without rebuilding the CMS? Can an integration disappear without breaking everything around it?

And what happens five years from now when the technology we chose today is no longer the best option? What happens when pricing changes, the product changes direction, a better framework appears, or the business simply develops requirements nobody could have predicted?

We cannot prevent those changes.

But we can prevent ourselves from becoming trapped by them.

Good infrastructure gives you leverage while you use it and freedom when you stop using it.

This is why Payload, Next.js, and Astro are not the real ten-year bet.

They may change. They may be replaced. Something significantly better may emerge.

The real bet is on owning enough of the system that when change inevitably arrives, we can replace what no longer works without throwing away everything that still does.

The Stack Is Not The Bet

We have developed a habit of treating technology decisions as permanent commitments. We search for the best CMS, the best framework, the best hosting platform, and now the best AI tools, hoping that if we choose correctly today, we will not have to reconsider those decisions tomorrow.

But technology does not work that way.

The contradiction is that we try to future-proof our websites by predicting the future, when the only thing we can predict with any confidence is that the future will change.

Payload will change.

Next.js will change.

Astro will change.

And ten years from now, some of the tools we consider essential today may have been replaced by technologies we have not even heard of yet.

So what happens if we build our entire website around the assumption that today's stack must remain tomorrow's stack?

What happens when the business becomes ten times larger, when marketing needs something we never anticipated, when customers expect entirely different experiences, or when a better technology finally arrives?

Do we rebuild everything again?

Or do we replace only what has stopped serving us?

This is why the website stack I would bet the next ten years on is not really Payload, Next.js, or Astro.

It is an architecture built for change.

Payload is the CMS I would choose today because it gives us structured content, ownership, extensibility, and room to build around the needs of the business. Next.js is what I would choose when the experience behaves like software. Astro is what I would choose when it mostly behaves like a website.

But none of them should become more important than the architecture itself.

Because businesses will still need the same fundamental things ten years from now: control over their content, freedom to build new experiences, the ability to connect new systems, and the flexibility to replace technology without rebuilding everything around it.

We cannot know what the best website stack will be in 2036.

But we can build today so that when we find out, changing to it does not require starting over.

If your website is already starting to feel constrained by the platform it was built on, rebuilding immediately is not always the answer.

Sometimes the better first step is simply understanding where the real limitations are.

That is why I would start with a plan.

We can look at your current website, the systems around it, what your team needs today, and what is likely to become difficult as the business grows. From there, we can map out what should stay, what should change, and whether a more flexible stack like Payload with Next.js or Astro actually makes sense for you.

And if it does, we can build it.

If you want, send me your current website and I will help you map out the right path forward.