When AI Can Build the Website You Need, Is Your Platform Holding You Back?

For most of the time I’ve been building websites, the business adapted to the software. You picked a platform, learned what it did well, and shaped your plans around what it would allow. If you needed something it couldn’t do, you found a workaround, lived without it, or got a quote from a development firm that usually settled the argument.

That was a sensible way to operate. Custom software was expensive to build and expensive again to maintain, and a good platform took most of that cost and risk off the table. The compromises it imposed were almost always cheaper than the alternative.

Two things are changing now, and they’re changing together. AI-mediated discovery is asking more of the website. AI-assisted development is making it cheaper to build around those new requirements. Either would be worth paying attention to. Together they reopen a question most businesses settled years ago and haven’t looked at since.

AI Visibility Is Asking More of the Website

Most websites were built for two readers: the person visiting and the search engine deciding where each page should rank. Both still matter.

But a growing number of buyers now start by asking an AI system, and the answer they get depends on how well that system can work out who the business is and what it’s actually known for. That takes more than reading what any single page says. It means working out who did the work, which service it relates to, what kind of client it was for, and what evidence supports the claim being made.

On a lot of websites, that information exists only as copy scattered across pages. A patient reader can piece it together. Leaving an AI system to reconstruct those relationships from scattered page copy is a weaker bet, and keeping all of it accurate as the business changes is harder still.

So the questions start to change. What pages to publish is still one of them. Alongside it: what does the business know, what can it prove, and how are those things connected? And can the system underneath the site actually hold them?

What Platform Constraints Now Cost

Competitive analysis made this harder to ignore. We were seeing businesses in the same markets take very different approaches to their websites. Some were working within the conventions of established platforms. Others had built far more purpose-specific systems around their information, content and relationships. The difference wasn’t mainly visual. It was architectural.

We keep running into the same problem. The architecture we want is clear. The platform makes it awkward.

A fact that should live in one place has to be updated by hand on a dozen pages. Relationships that should come from a single source get maintained manually, and over time they drift. Structured data gets bolted on through a plugin because the markup the platform produces can’t easily be changed. Information that’s really relational, like which person worked on which project for which kind of client, ends up flattened into a paragraph because a paragraph is the only container the CMS offers.

The workarounds also accumulate. Each one is a small piece of logic living somewhere the platform never intended: a plugin that generates markup you can only partly configure, a spreadsheet someone checks before publishing, a template edited so heavily that nobody wants to touch it again. Individually they work. Together they make the site harder to change, and that matters most exactly when the requirements are moving.

None of this is dramatic on its own. Most of it would once have been filed under developer irritations. But these are exactly the places where an AI visibility strategy gets implemented. If the system can’t hold a relationship, the relationship doesn’t get expressed. If an update depends on someone remembering to make it in twelve places, the information goes stale in ways that can affect whether it keeps being cited.

Ten years ago the workaround was usually cheaper than changing the system. That calculation is changing.

When the architecture is under your control, the conversation changes too. You stop asking what the platform will let you do and start asking what the system should do.

Those are very different meetings to sit in.

Visual Flexibility Is Not Architectural Flexibility

Most platforms now offer a great deal of visual freedom. You can change layouts, typography and templates, move components around, and end up with something that looks entirely bespoke. Platforms have become very good at this, and it’s what every demo shows. Nobody demos how a fact propagates.

Architectural flexibility is a different thing. It’s control over how information is modeled, related, reused and exposed. A case study might connect to a service, a client type, a person and a particular claim. Build those relationships into the system and they can appear wherever they’re needed without anyone maintaining them by hand. Leave them in the copy and someone has to keep every one of them straight.

A site can be completely flexible in how it looks and quite rigid in what it can represent.

When a business tells me its site is custom, it usually means the first kind of flexibility. For AI visibility, the second one matters more.

AI Changes the Economics of the Constraint

Accepting a platform’s limits made sense when the alternative was a development team, a large budget and months of work. The workaround was the cheaper option, usually by a wide margin.

AI-assisted development is narrowing that gap. Prototypes that used to take weeks can take days. Changes that once needed a scoped project can often be made in an afternoon.

In our own work, a new content type with its own relationships or a sitewide change to structured data might once have been scoped as a separate project. Now that work can often take days rather than a budget cycle. The point at which it becomes worth building around your own requirements, fully or in part, is moving, and it’s moving at the same time AI visibility is asking more of the architecture underneath.

Engineering judgment still matters. Someone still has to own security, reliability and maintenance, and cheaper code doesn’t make those responsibilities disappear. Custom work that nobody properly looks after is its own kind of constraint.

What has shifted is where the difficulty sits. When building gets easier, deciding what’s worth building becomes the harder part: which facts should have a single source, which relationships should be explicit, what should be automated and what should stay as editorial writing. Those turn out to be questions about the business as much as the technology.

Is the Platform Actually the Constraint?

The useful question isn’t whether your platform is old, or fashionable, or what your competitors happen to use. It’s whether it supports the architecture your strategy requires.

A few questions usually make that clear. Can important facts be maintained in one place and reused, or do they get copied and slowly drift apart? Can the relationships between your people, services, projects and outcomes be represented directly, or only described in text? Do you control the structured data the site produces? Can you add a new type of content without fighting the system? And when requirements change, as they will, how long does it take to change how the site behaves?

Whoever maintains the site can usually answer these quickly. The answers just rarely reach the people setting strategy.

If the answers are mostly straightforward, the platform is probably doing its job. If they’re mostly workarounds, that deserves more weight now than it would have a few years ago.

It’s also worth being honest about what a better platform can’t fix. Architecture can expose authority. It can’t invent it. If there’s little real experience or evidence behind the business, rebuilding the website will make a thin case very easy to read, and not much more.

The Strategy Shouldn’t Have to Shrink

Your platform may have been exactly the right choice when you made it. What’s changed is that AI visibility is asking more of the system underneath, and AI is making it cheaper to build differently. That makes it worth judging the platform against the strategy you have now, and judging whatever you decide by whether it changes anything that matters commercially.

The platform should support the strategy. The strategy shouldn’t have to shrink to fit the platform.