Introducing the Three-Layer Model for Intelligent Products

On a recent All-In podcast episode, David Friedberg described how his team at plant-breeding company Ohalo Genetics spent a weekend building an internal CRM using Claude Code, Cursor, and a handful of other AI coding tools. They stood it up, started using it, and it worked. 

Then the requests started. 

Can you add this feature? Can it sync with the tools we already use? What about access controls and data security? Each question was reasonable on its own, but together they added up to a roadmap nobody had planned for, competing demands for limited engineering resources, and a product the company simply wasn’t in the business of making.

Ohalo's advantage isn't its CRM. It's plant breeding. The software that sets them apart is their plant-breeding-technology platform, and the tools that put real capability in the hands of the people in the lab, in the greenhouse, and at the bench. That work is unique to Ohalo; nobody else can do it because nobody else knows what they know. 

So Friedberg's team asked a more nuanced question than "should we build this?" They asked where they get the highest return on time and dollars spent. The answer was not in rebuilding a CRM, a messaging tool, an analytics platform, or any other solution other competent companies had already spent a decade getting right.

Nothing about that story requires you to be in agriculture. Swap plant breeding for whatever your company knows better than anyone else, and it's a story about your roadmap and focusing your team’s time, talent, and tokens to build what differentiates you.

Build vs. Buy Is An Outdated Framework

Until recently, decisions like Ohalo’s were made using the traditional build vs. buy framework. The logic was clean: building was slow, expensive, and risky. Buying was faster, cheaper, and more predictable. The comparison did the work for you.

AI coding tools collapsed that logic, at least on the surface. The demos are compelling, the estimates look reasonable, and the engineers are genuinely excited to try something new. When a prototype that used to take a quarter takes a weekend, "just build it" stops sounding reckless and starts sounding obvious.

So the old question stopped being useful. And nobody replaced it, until now. In 2026, every product team is building. So the question is no longer whether you build, it's what you build.

How Accidental Analytics Companies Happen

Building embedded analytics never seems like a bad choice at first. Someone sees a text-to-SQL demo, “It's good!” So someone else says, "We could build that." And they're right, they could.

But what they don't account for are the other two layers lurking beneath the surface of every intelligent product. Six months later, the team finds itself maintaining a semantic layer, fielding complaints about numbers that don't match, and standing up multi-tenant architecture.

TL;DR: No one planned to run an analytics company, but that's the job now.

Chief Product & Technology Officer for Thrive Learning, Frankie Woodhead, perfectly described the problem: “As a CPTO or as a CTO, you always go through this dilemma: 'Do I build or do I buy?' For many, many years, we were building and building and building....Our teams were optimizing for analytics instead of optimizing for product. Engineering time was a constraint.”

Most teams misjudge the gap between the feature you intend to ship and the infrastructure you end up having to own. Every intelligent product consists of three layers, and treating them as a single build decision is the biggest product strategy mistake a leader can make.

Layer 1: Your Competitive Advantage

Layer 1 includes your core product roadmap, and it's the one you should absolutely build. It's where your business logic lives, along with your industry expertise, the AI use cases only you would think to pursue, and the workflows your customers can't get anywhere else. It's everything that makes your product irreplaceable in its market.

This is also the only layer where engineering leverage compounds. Every sprint spent here creates something a competitor can't replicate by purchasing the same vendors you bought, because what you're building isn't really technology. It's domain expertise, encoded in software.

Nobody else can build your Layer 1, which is why it belongs to your product team permanently. There's no version of this decision where handing it to someone else is the right call. The only real risk is starving it: spending so much capacity on the two layers beneath that the one setting you apart never gets the engineering attention it deserves.

Layer 2: The Intelligent Experience

Layer 2 features the AI-native analytics your customers actually see and touch. It's where they want to ask questions in plain language and get trusted answers, explore on their own instead of filing a ticket, and take personalized actions on insights without leaving your product. 

Layer 2 is the most dangerous of the three because a shallow version can now be prototyped in a week. But a conversational interface that answers correctly using demo data and a real-world scenario is not the same as one that answers correctly every single time using a customer's live, complex schema and unique edge case. The first takes a weekend to get right, while the second takes years.

This is why Layer 2 is the one you white-label. Your customers don't care who built it. They care that it works, that it's fast, and that it looks like it belongs in your product. With the right partner, all three are possible without your company owning a line of it.

Layer 3: The Analytics Foundation

Layer 3 includes the infrastructure nobody sees, but everybody depends on. It's governance, authentication, and multi-tenant security that protect customer data. It's the query optimization that keeps things fast at scale, and the monitoring and audit trails that show who accessed what, and when. And so much more.

No user has ever opened a product and admired its permissioning model. But every one of them will leave if it fails. Layer 3 is invisible when it works and catastrophic when it doesn't: a security breach, a compliance incident, or a customer discovering another's data. 

It's also the layer with no finish line. Every new tenant, schema change, SOC 2 cycle, and LLM version bump lands on your team, and the more you scale, the harder it gets. Which is why Layer 3 is the one you should never own. Not because your team can’t build it, but because once they do, you own it forever.

Which Layers Are Consuming Your Roadmap?

Because teams often approach intelligent products as a single build decision, most roadmaps contain work from all three layers. Ask these three questions to distinguish between them, and to make sure you're not treating infrastructure as differentiation:

1. If a competitor bought the exact same tools you use, could they replicate this? If yes, it isn't Layer 1. It's infrastructure that happens to be sitting in your backlog.

2. Does this encode something about your customers or your industry that only you know? If no, it isn't Layer 1 either, no matter how much of your roadmap it's currently occupying.

3. Would your customers notice and care if your version of this worked better than everyone else's? If yes, and it also cleared the first two questions, it's Layer 1. Build it, and protect the capacity to build it well.

Anything that doesn't pass all three questions is Layer 2 or Layer 3, and the split between them is simple. If your customers see it, it's Layer 2 and you should white label it. If they never see it, it's Layer 3, and you should never own it. 

Next, do the part that actually stings. Add up how your engineering capacity is currently distributed across these three buckets. For most teams, Layers 2 and 3 absorb significant resources and provide zero differentiation. 

Now calculate how much time and money offloading these to a trusted partner would allow you to reallocate to Layer 1. Our build calculator can show you in just a couple minutes.

Build What Differentiates You

The next generation of winning product teams won't be the ones who build the most. They'll be the ones who build the right things.

At ThoughtSpot, we love builders and tools that make them more powerful. Almost anything is buildable with today’s solutions, which is exactly why what you choose to build matters more now, not less. 

It's also why the old build vs. buy framework no longer holds up, and the question stopped being whether you'll build. It's whether you're building the things only you can. Building with ThoughtSpot Embedded is how you buy back the focus to do exactly that.