In an AI-native company your product thesis will change — probably more than once — and the teams that survive the turns are the ones whose architecture was built to be survived.
Over the last few years, the platform I lead has fundamentally changed what it sells four times.
It started as a way for colleges to onboard and run in days, instead of the long implementation cycles the incumbents forced on them. Then the thesis moved to enterprises that had no reliable way to protect the content they distribute — controlled sharing, rights enforcement, real usage tracking. Then to businesses that needed a secure way to put sensitive, high-stakes material in front of leads and customers and stay in control of it: seeing what a recipient actually does with a document, rather than flying blind through a long sales cycle. That's roughly where the product sits today. And the next turn — an enterprise RAG platform — goes live shortly.
Four different products. Four different buyers. Four different pitches. One thing did not get rebuilt between them: the core. That is not luck, and this piece is about why it wasn't.
The part that didn't move
Across every pivot, three things stayed constant — and none of them was the product.
How content is represented and structured. How identity, groups, and access are modelled. How the thing is packaged, priced, and fulfilled. Those are the least glamorous layers in any enterprise system, and the most durable. The buyers changed, the features changed, the story we told changed — but content, access, and commerce are structurally the same problem whether you're serving a university, an enterprise content team, a sales organisation, or a retrieval system. Build those once, build them properly, and you've bought yourself the right to change your mind about everything sitting above them.
I won't get into how any of that is built — that part is ours. The point isn't the implementation. It's the choice of what to treat as permanent.
Why AI-native makes this acute
In a slow market you can get away with fusing your architecture to your product, because the product doesn't move much. AI-native companies don't get that luxury. The model layer churns violently — new models, new capabilities, a new plausible thesis every couple of quarters — and if your foundation is welded to this quarter's product, every pivot becomes a teardown.
Here's the part most teams miss: the layer that changes fastest is not the layer that's hardest. Enterprises are not, in the end, buying your model. They're buying a guarantee — that their data is isolated, their access is governed, their content is controlled, and that they can prove all of it. That guarantee lives in the boring, durable substrate, not in the model. Which means the hard part and the stable part are the same part. Get it right, and you can swap the exciting layer on top as often as the market demands.
The discipline
The real work is deciding, continuously, what earns a place in the durable core and what stays in the disposable layer on top — and then holding that line when there's pressure to ship.
Most of what a product needs can and should sit on top of the core, not inside it: usage tracking, automation, delivery and communication scaffolding, the AI tooling itself. Those are additive. You layer them on without touching the foundation, and when the thesis changes, you peel them off without the foundation noticing.
The harder discipline is refusing to let expedient things fuse into the core when everyone wants to move fast. From day one the rule was that even the core is layered and segmented — never one undifferentiated blob of features. That sounds like an aesthetic preference. It's actually what made the latest pivot cheap: to move to the new thesis, we largely just stop using the parts of the core we don't need. We don't have to surgically untangle something that should never have been tangled. Rewiring is easy when nothing was fused in the first place.
Why this is a leadership call, not an architecture call
It's tempting to file all of this under engineering. It isn't.
The decision that matters gets made before you know which pivot is coming — when you choose to invest in a substrate this quarter's roadmap doesn't strictly need, and when you keep product and go-to-market from cementing something convenient into the foundation because it's faster today. That's not a diagram. It's a series of unpopular calls made on conviction, under real pressure, with the payoff invisible until a pivot arrives and the thing that would have been a nine-month rebuild turns out to be a rewire.
That's the founder-scope version of architecture: you're not optimising this product, you're protecting the company's ability to become the next one.
The principle, portable
If you're building anything AI-native, the transferable rule is simple. Identify the layer that will outlive your current thesis — for most enterprise products it's content, identity, and governance, not the model — and make that your durable asset. Build it segmented, so pieces can be dropped rather than dismantled. Keep everything the market gets excited about in a layer you can afford to throw away. Then let the product change as many times as it needs to.
The companies that die in the turns are the ones that rebuilt their foundation every time the story changed. Architect for the pivot, and the pivot stops being an existential event. It becomes a Tuesday.
← All writing