"If you see me or any other artist paint an image more than once, it is not because we have run out of ideas. It is because the image is full of ideas".
<div anchor>Introduction</div>
There’s a joy and satisfaction that comes from building in the same space for over a decade. Each time you return to a problem, you bring more knowledge, better tools, and a sharper instinct for what the moment actually requires. I've lost count of the iterations we've made trying to solve for access control and monetization. Each one was the right answer for its time, but as the world changed, new possibilities opened up that simply weren't visible before. That's the nature of going deep on a problem. The work only gets more interesting.
When you've built exceptional products and watched a category evolve, you develop an eye for the gap between what exists and what's now possible. The change can look dramatic from the outside. From the inside, it feels like craft. And when you look back with honesty, each previous version had assumptions baked into its foundations that only became visible when the world changed around them.
<div anchor>The First Assumption</div>
For me, the most obvious assumption we’ve had, and the one that feels almost quaint now, was that users were human. Not in a naive sense. Of course we knew bots existed. But our mental model of an audience was someone who clicked, scrolled, subscribed, and cancelled. The entire access and entitlement logic was built around that person: their plan, their session, their meter. There was no real architecture for a different kind of visitor, because a different kind of visitor wasn't a realistic opportunity back then. The idea that the majority of traffic to a publisher's content might one day come from AI crawlers, that a single LLM might consume the equivalent of thousands of human visits without sending a single reader back, was firmly in the realm of science fiction. It was the Jetsons. We didn't build for it because we couldn't have imagined it.
<div anchor>The Second Assumption</div>
The second assumption is one we could have questioned earlier, and that's the one I find more instructive. We believed, quite earnestly, that powerful software should hide its complexity. The people using it on a daily basis were commercial teams, not engineers. They shouldn't need to understand how the rules worked under the hood. They should just be able to configure things, launch campaigns, set prices. The right product decision, we thought, was maximum abstraction.
What we built instead was something that served no one particularly well. The business user still found it complex, because asking someone to configure access logic is inherently technical regardless of how many layers you build over it. The developer found it too constrained, because all that abstraction had closed off the surface area they needed to extend the product, connect it to other systems, or implement use cases we hadn't anticipated. Every new use case became a feature request. Every edge case required professional services. We had built a SaaS product that needed to grow by adding more features rather than a platform that grew by enabling more possibilities.
<div anchor>The Lesson</div>
The lesson wasn't that non-technical users don't matter. They matter a lot. The lesson was that building for them by hiding the system from everyone doesn't serve anyone. It just produces something that's too complex for comfort and too locked down for capability. The better approach is to serve each persona properly: give developers the full surface area of the platform, and build the business user experience on top of that foundation so it's genuinely accessible rather than superficially simplified.
When we were building MonetizationOS, these lessons shaped almost every architectural decision. We're code-first because programmable infrastructure is the only kind that can be extended, tested, and deployed through real workflows rather than configuration screens. We run at the edge because there's no other way to do this. When every request, from every type of visitor, needs a real-time decision, latency isn't a tradeoff. It's a failure. We're explicit about observability because a system you can't see is a system you can't trust or improve. We built for machine traffic as a first-class audience because that's the world we now live in.
<div anchor>Anticpating The Future</div>
Those lessons are now baked into how we build. But they only answer for what we already knew was wrong. The harder question is what we can't see yet. How do we build in 2026 in a way that our 2030 selves will be proud of?
I don't think the answer is better prediction. The machine traffic explosion wasn't predictable a decade ago. The hybrid use cases we're starting to see now, personal agents that subscribe to things on your behalf, swarms of AI systems negotiating access autonomously, weren't predictable two years ago. Trying to anticipate every future use case and build for it in advance is a guaranteed way to produce a system that's over-engineered for a future that doesn't materialise and under-equipped for the one that does.
<div anchor>First Principles</div>
What you can do is build on principles that don't become obsolete. Composability means that new use cases can be assembled from existing components rather than requiring new ones. Extensibility means that customers can integrate with new vendors, new surfaces, and new business models without waiting for us to build the connector. Programmatic control means that the logic lives in code that can be versioned, tested, and deployed rather than configuration that ossifies over time. Performance at the edge means that the architecture doesn't become a ceiling as scale increases. These aren't features. They're the conditions under which a platform stays useful as the world changes around it.
The other thing we do, which I think matters as much as any architectural principle, is to have people whose job is to chase the art of the possible. Not in an abstract sense. Practically: people who are actively building x402 use cases, machine payment flows, hybrid monetization scenarios that our customers can't quite articulate yet. Not because those things are on the immediate roadmap, but because when you can make something tangible, when you can show someone what it actually looks like rather than describe it theoretically, the future becomes something you can buy into rather than something you have to take on faith. That's how you bring early adopters with you. That's also how you keep yourself honest about whether your principles are really working or whether they're just principles you say you have.
<div anchor>Hindsight Vs. Foresight</div>
Hindsight is perfectly clear. The assumptions that constrained us in the past are obvious now in a way they weren't when we made them. I don't think that means we were wrong to make them at the time. It means the world moved, and the software couldn't move with it.
Foresight is a different kind of discipline. You can't see the future clearly enough to build for it directly. What you can do is build in a way that keeps the aperture as wide as possible, that says yes to use cases you haven't imagined yet, that treats extensibility and composability not as features to ship but as the conditions under which everything else stays possible.
Whether our 2030 selves are satisfied won’t come down to what we predicted. It will come down to whether we built something that could change.
