This week we launched a new website for APIContext. The launch itself isn't particularly remarkable. Companies launch websites all the time. What surprised me was how much the experience made me reflect on the last twenty-five years of working with content.
I started my career as a software developer. Long before open source CMS platforms became the default answer to almost every website project, I was building proprietary content management systems and digital platforms. Every customer had unique requirements. Every workflow was custom. Publishing information at scale was a genuinely difficult technical problem.
Later, I ran a systems integration business where content management and digital experience platforms formed a significant part of what we delivered. Organisations invested heavily in solving how information was created, managed, and distributed.
Then the industry standardised. Open source matured. Platforms improved. What once required specialist developers and significant budgets became accessible to almost everyone. Content management became a solved problem. Or at least that's what we thought.
Rebuilding the Foundation
As my career evolved through customer success, product, sales leadership, and eventually founding APIContext, I naturally spent less time building software directly. Like many founders, my time became focused on customers, strategy, fundraising, partnerships, and growth.
Then, over the last few months, I found myself building again. The project started as a simple proof of concept. I wanted to explore whether there was a better way to structure and present what APIContext has become. What began as a small experiment quickly became something larger.
I built the initial concepts and framework, then handed the project over to Jamie Beckland, our Chief Product Officer. Jamie did the heavy lifting of migrating, refining, reviewing, and quality-assuring the site. Anyone who has been through a major website migration knows that's where the real work begins.
What made the project interesting was the combination of perspectives. I came from a software and systems background. Jamie came from years of agency, content, design, and digital experience work. Historically, projects like this would have required specialist teams and months of coordination. Today, a small team can move with a speed that would have seemed impossible only a few years ago.
The Shift: Content vs. Context
The technology was impressive. The speed was impressive. But neither turned out to be the most important lesson.
The real lesson was that content management is no longer the challenge. Creating content has become easier than at any point in history. The bottleneck has moved. The challenge now is context.
For most of my career, websites were built primarily for human consumption. We thought about navigation, user journeys, and search. The audience was people. Increasingly, that assumption no longer holds.
Today, machines are often the first consumers of information.
They discover it, interpret it, summarise it, reason over it, and connect it.
In many cases, machines encounter your knowledge before humans do. This fundamentally changes the role of content entirely.
Serving the New Audience
That changes the role of content entirely:
- A product page is no longer just a product page.
- A case study is no longer just a case study.
- A research paper is no longer just a research paper.
Each becomes part of a larger body of context that helps humans and machines understand who you are, what you do, and why it matters. Looking back, it's interesting how familiar this transition feels.
Twenty-five years ago, we were trying to solve content management. Today, content management is largely solved. But the most important shift is that we are moving from a world where content was created primarily for humans to one where context must serve both humans and machines.
And increasingly, the machines arrive first.