The Semantic Layer Is the Missing Architecture

Machine-generated transcript from the episode video. Speaker labels are not included and some names and product terms may be transcribed phonetically.

[0:00] 12 tools, 12 definitions of customers, zero agreement on what revenue means. The dashboards are full. The data team is underwater. The founders are making decisions gut feel. Anyway, the problem was never access to data architecture. In this episode, the co-founder of Lopeus AI explains why most analytics fail before the first query runs, why a semantic layer matters more than a better chart, and what happens when you compress the distance between question and answer to seconds. Welcome to GTM Vault, trusted by over 25,000 founders and operators building the future of revenue. Today's guest dropped out of Dartmouth to build analytics infrastructure. He went through Y Combinator's winter 2025 batch. Before Lopez was an analytics platform, it was completely different product. The pivot tells you everything about where the real pain lives. Lois AI connects CRM billing, product analytics and support into one governed workspace. No SQL, no

[1:03] data engineering, a semantic layer that locks in your definition so every query speaks the same language. Today we go deep on data fragmentation, trust architecture, AI native analytics, and what it takes to give growth teams answers they can act on. Danalo, welcome to GTM Vault. Thank you for having me. Lobus started as a generative UI product. Now it's an analytics platform. What killed the first idea? Yes. Uh well, it's very that you bring that up. Uh when we first got into YC, that was the idea that we started with. And when we when we got in and we built out the product and we were sort of talking to users as goes with a startup, we slowly started to realize that this was a very niche.

[1:47] It's it's it's sort of like we got a lot of hype on Twitter, everyone was like, "Oh, generative UI. I'm going to be able to generate all these things." But when we actually talked to users and like, "Hey, what do you want to use this for?" Nobody had any idea, right? And then so we realized like this is a pure sort of play, right? We can't exactly just like, you know, build out this this Then UI tool as if nobody wants to buy or or use it, right? And so we realized, okay, let's let's try and pivot away from that and and try something else. And that's what led us to look. What did YC force you to confront about your original product that you were avoiding? I think it's like one of the best things about YC is their very first principles based and they they apply them to sort of every company like the idea of you know making something people want talking to users being resourceful moving fast you know all these things like this is very all these things are very important for a startup and so YC was great at like we would come to them and be like hey we've built this app we show this to people you know it looks really cool and then they're like okay did you guys talk to users we're like okay let's go try and talk to users and we talk to users and then we realize okay nobody like we don't know who our

[2:49] ICP is. We don't know who our main user is. We just thought the tech was cool and then even when we put it out there um we realized that there was no real fundamental valuable use cases for this technology. So we realized okay we might just have to uh pivot away from this. And so YC really really taught us that you know it's really about the sort of motions of building a startup is really about talking to the customer and close to the person figuring out something that's valuable to them personally. And so the that first I guess pivot really taught us a lot about what it means to to build a company and the motions which you have to go through to validate and then invalidate ideas. Your background is Darth Cali lab DARPA research technical not GTM. Why build for growth teams?

[3:32] Yes, that's also a great question. So I've always seen myself as a sort of artist who who learns to code. I feel like to me personally, I know many people in Silicon Valley might disagree, but to me coding is is is a more of a means to an end. I like to learn coding and then apply it to to something else. In my experience at the Dolly Lab, I I was in game dev and and AR and VR development for 3D and VR environments. And what I wanted to apply there was like, hey, I learned programming and everything. And then from that I can make like some cool art like some cool games that people can interact with or some learning experiences that are valuable to have in in 3D. And eventually I guess as we've sort of matured and grown and pivoted away from our old ideas that led me down to to go to market because as you know this is this is um it's ironic but it's almost like a YC Canon event where a typical company would pivot away from from the original idea and then come and build a sales tool. And for us it was kind of like that because we've we were both technical founders and we've never done sales before. And then so we're like

[4:34] okay let's try and build something for sales people right as we've learned what the process is like from our own experience in our own startup. Two founders seed money San Francisco. What is the hardest constraint right now that has nothing to do with the product? I would have to say probably just hands on deck personally and being able to accumulate a lot of knowledge from a limited amount of of workforce that we have for us right now. It's very like since we're building a sort of comprehensive almost like a BI tool. It needs to be very very holistic in that sense. And that's something that we've learned as we've built this tool out in the beginning is you can't really do an MVP, right? You can't be like, oh yeah, we answer some of your questions some of the time or like we can only do some queries. It's like, okay, our consumer is like, hey, I need the eye tool that has, you know, all these features. I need dashboards, charts, uh, you know, and the the text to SQL and all that.

[5:27] So, we're like, okay, let's let's sort of build those out. But then the tricky part is being able to really talk to a lot of users, understand all of their needs and problems within their business and how they're going about building it. and then for every single user and consumer of the product be able to turn those insights into a very few constraint features that sort of work well for everybody. And so if you look behind me, my whiteboard looks a little crazy. That's because we try and write down all the feedback that we get and all the insights that we're working on and then compress those down to just like five or four fundamental features of the main product. When you onboard a new company, what is the most common data contradiction you find between their CRM and their billing system?

[6:10] I would say depends on the stage of the company, but most universally the CRM is is always a mess. Everybody kind of knows this. The CRM is a mess and and people kind of want to like even early stage and later stage founders, they always fall back on their billing data to sort of see how their business is doing. However, more interestingly than not is within their billing data, there's some textbook definitions, but they they every company always has some sort of their own quirks and definitions of MR is defined, how churn is defined. And so, you can't really get that from a from a typical billing dashboard. And when you when you start to connect your your CRM with your billing data, you start to sort of see like, hey, these leads are coming through, for example, um, from our CRM and our Salesforce and they're, you know, maybe signing some pilot contract, but then the turn obviously gets lost later down the load the the road. And then on top of that, what you start to notice is there's a much larger area of of expansion, right?

[7:08] You know, sort of land and expand into a company. you you give them some sort of easy tool, easy feature, they like it and then you know the either teams will buy or the current team will expand their contract. And so it's those things you only get from sort of joining both of those together where you're like, hey, actually these leads that come in here or have this sort of profile or of this company size actually end up expanding later down the road because for them the tool is most valuable. Whereas you know typically you can't really get that from a typical CRM or just purely from from billing. Marketing's definition of qualified and sales definition of qualified are two different numbers. who at the company defines the semantic layer and how do you resolve that?

[7:49] Yes. So, this is a very very universal problem and is one of the reasons why we sort of wanted to build out a product for for revenue teams. This is a tails all the time. Marketing brings in a couple leads and they're like, "Okay guys, we're doing our job." Sales takes over the leads and then doesn't close them. Marketing thinks the sales team is bad and they don't know how to close people. Thinks that the quality of the leads or the marketing people are bad because they're not getting closed. It's this is a never- ending battle. If you if you obviously have these not only data silos but team silos, right, where they just kind of hand one thing off to the other, you're never going to know what's actually happening in the business. And so on our end, it's our main responsibility to try and tell you, hey, you know, this definition of what a marketing qualified lead is, only 30% of those are actually, you know, end up converting as well as you think, right?

[8:38] And having that full customer 360 journey all the way from your, you know, HubSpot marketing to your billing and your customer success is what truly enables a business to look deep into the customer and understand what sort of people they should be serving instead of just like having arbitrary definitions for for you know the MQL and the SQL. No SQL required is the tagline, but RevOps wants to see the query. How do you serve both audiences? Yes. Um this is another very interesting um I guess learning that we've had is we when we're building a tool a BI tool for non-technical people. One of the biggest problems that many of them would come to me with is like hey I'm a customer experience lead. I'm a CS lead. I'm a marketing lead. Why on earth do I have to know SQL to do my job? Right? I just want to talk to customers. I want to work with them. the we've realized is they want a tool where this just enables them to do their work better, right? And we sort of follow like the lovable model. Hey, if anyone can, you know,

[9:40] build anything, then anyone should be able to work with their data and talk to their data within the company context. And so through that is what enabled us to sort of build this, I guess, non-technical approach to our technical data product. However, of course, within the go to market field, there's multiple different types of roles and RevOps specifically is very familiar with data and how the CRM works and so on and so forth. And so, what we've simply done is like, hey, we the core platform is very userfriendly for non-technical people. However, there's also like a more in-depth admin dashboard where you can track the logs, what connectors you have, what when was the last time the data was updated, and then within the query yourself like you're asking, you can just toggle the SQL and you can be like, hey, this is what's ran. And you don't see it immediately, but you can toggle a button and you can see, okay, this is the the SQL that backs it up.

[10:29] You claim 500 plus integrations at your stage. How many are deeply maintained versus the thin API pools? Well, most of them are are maintained. So we partner with TR if you're familiar is of course the world's leading uh data and ETL pipeline and airte we've tried airte before actually but airbite does not seems to be as good and their docs are a little bit outdated so we we've moved to tren and upr of course has all of these integrations and they're always up to date but the tricky part for us is not really maintaining the integrations as that's that's mostly their responsibility it's actually maintaining the upto-date data transformations and the understanding that it definitions of metrics within your data from the semantic layer. So for example, what would sometimes happen is you would come in and be like hey this is how we define MR, right? And you'll be like hey MR is defined for people who are past the free trial and they've already committed to a monthly period and they haven't turned within this month. Okay. And then you write some SQL to to understand that.

[11:29] Then suddenly stripe changes their APIs and then the underlying you know fiverr connector one of the fields gets nullified and then suddenly you cannot reference the same definition of MR within that same SQL anymore and so it's our job of our sort of self-healing semantic layer to be able to have that definition not just in SQL but also in logical plain English understanding so that when the underlying data changes it's able to adjust its own SQL on the fly without having to without a person needing to come in and then adjust it every single time whenever something breaks because the biggest problem with BI and all these data platforms is is really the maintenance having to maintain everything. Every single new view, every single new dashboard is an extra, you know, tons of hours of of maintenance that you add to the data team.

[12:19] Give me a concrete example of when Lopez told a customer not to trust an answer. What was the underlying data problem? Yes. So usually we've ponder Asian if you work with AI you should have started to understand I mean and thankfully the frontier labs have sort of realized this too. So it's gotten easier on our end to to work with this. But back in the day, they were very primed to answer anything, right? Especially in the early chip days in in 3.5, if people remember way back when now, and you would use it and it would just like hallucinate anything and just make anything up just purely to answer your question, right? And whereas now the models are a lot better at pushing back and staying grounded. And we've we follow the same methodology within our own product where our goal is not to answer your query.

[13:04] Our goal is to give you as much of a trustworthy answer as possible. So within once you sort of apply that lens to data analytics, you start to understand okay so what are the downstream effects of that? And so for us that's been hey when the query runs we ask many many clarifying questions. So it will look at the data and be like hey actually you asked me this but the data looks a little weird. So you know what do you mean by that? And then it'll just keep playing around with it until finally it reaches like a very clear consensus between what you're looking for and between what data is available and then it'll run it and then give you the answer. And with an example of like when you ask something that's not possible is is a query that I always try and run and test myself is like hey can you connect all of my you know mixed channel data with with with my Salesforce records and then see which leads are coming in and then I I think I have like some super complex addition to that like which ones are the power users of this feature. And then the funny part there is we never actually connect the users between the two deliberately and so the AI then comes in and before writing any SQL realizes hey actually I

[14:07] have access to to both tables access to all the data from both however I'm not able to join them so I cannot provide you with an answer and so that gives me the peace of mind like okay that's great because with any other of these Texas SQL tools is they'll just answer anything right for the sake of answering and I'm like actually nobody wants that right people want safe and guarded you know, answers that they can trust and they're [clears throat] just like than anything. And so that's been that's always been the core of our You show that generated SQL behind every answer. Has a customer ever looked at it and said it was wrong? No. Thankfully, you're not so far. We try and be very very deliberate with with our engineering and we we test it a thousand times before. At 2K a month, companies are piping CRM, billing, and product data into your platform. What is the actual data architecture? Single tenant or multi-tenant?

[14:57] Single tenant. Of course, when people are trusting us with with their most sensitive proprietary or company data, we make sure that it is airgapped and separated from all of the other customers because it's it's it's sort of like Murphy's law if you're familiar and that especially Murphy's law is very famously applicable to cyber security. So my co-founder used to work at a at a cyber psych lab and one of the saying there is just like you don't have to give people a motive to hack you, they'll just do it for fun, right? And one of the like worst nightmares as we've been seeing over the last week or so has been coming true. Axios, right, the the famous library got hacked recently. Merur's internal database got leaked. Delve recently got Superbase bucket got leaked as well. Like so many things are are going wrong and so many companies are getting hacked. And so I'm very grateful for the fact that we're taking cyber security seriously from day one. And we're not in a rush to to sort of, you know, go go go crazy for the sake of money. We want to make sure that people trust us because there there's a huge trust barrier when you're giving a company access to so much of of your internal data. You want to make sure

[15:59] that it is safe, secure, and you know, if if let's say somebody hacks our account, god forbid, they have access to to every other company's data that over all of our customers data. So thankfully our own architecture does not enable that, right? Every single customer's data is is separate and even if somebody hacks one of them, you know, they still can't see all the others. And so we we take our security very very seriously to make sure that you know there's nothing physically can can go wrong and if something does right we're not going to assume it can't because cyber security people will just hack you for no reason. If it does the impact of that is as limited and as tight as possible. Your investigation agents surface root causes not just when churn dropped but why? How does the agent separate causality from correlation?

[16:44] Yes. So this is this is a great question and it's something that we've been uh playing around with for a while. I will have to say it's there's a multitude of factors that we personally apply within our own agent and and its own reasoning to try and understand okay what is the actual methodology there. So one is temporal sequencing. So like the agent checks whether the supposed cause actually preceded the effect. the turn spiked in March but the pricing change happened in April. It's obviously ruled out that that's not the cause. It's obvious but you know most dashboards can't enforce enforce this automatically whereas the agent can. Then there is of course segmentation in isolation of different variables. So when turn drops the agent slices across every available dimension.

[17:30] So the plan tier the cohort the region acquisition channel whatever features they're using in the product to see if the drop is uniform or concentrated in in some sort of space. If turn only dropped among users who were onboarded by a specific CSM, that's a much stronger casual signal than we launched a new feature and turn dropped. And so having that precise uh segmentation, being able to cut it up into different parts and then analyze all of those creates for much more in-depth analysis, too. And then of course there's confound surfacing. Instead of just finding an explanation, the agent actively looks for competing ones. Hey, so turn dropped and yes, you launched a new feature, but maybe you also launched a discount campaign, right? And so it prevents the full picture or I mean it presents the full picture rather than anchoring, you know, on the first plausible story. And so the way the deep research agent really works is it first comes in and then it has many different like a ton of different hypotheses that it tests against and then for each of those hypotheses once it goes into the research and then finds it we have the

[18:32] anti-hypothesis that is then uh validated uh through a secondary agent to then see if if that lines up or not. And so having these many steps and these segmentations is what enable us to try and we know as as make it as tight as possible in its analysis and as as correct and as grounded in the truth as as however of course we we don't claim to prove causality in the way a clinical trial would right no analytics tool can but what we can do is eliminate all of the lazy explanations and make the person's work as as simple and as as easy as possible. You have a forward deployed data engineer for on boarding that is a palunteer era model. How does it scale past 20 customers?

[19:14] I will actually argue that this is one of the best models to have especially in the modern startup scene. Part of the reason is because our product is is built on edge cases, right? Every single company I mean we can build out every single data transformation models for all the tools that companies have, right? Companies typically have, you know, at least the startups that we work with seven of the same tools, right? Hubspot, Salesforce maybe Adio, drive for billing, QuickBooks for accounting, post hog for data for product analytics. There's something else that makes you usually have like a intercom or pylon for your CS and then framework, web flow or Google Analytics for your website analytic. These same are always standard give or take. You have some combination of these tools and it's very that makes it very easy for us to build out the internal data transformations and not have to reinvent the wheel every time.

[19:58] However, the added benefit of having a forward deployed data engineer is every time we have a customer and they have their own specific bespoke needs, we're able to fix those for them and then apply that fix to the logic of the product itself. And as we sort of account for more and more edge cases through our forward deployed motion that makes the product itself more and more capable of handling more bespoke, more custom data sets rather than just the typical tooling. You say live in days. Is that that days to first dashboard or days to a fully governed semantic layer? Both is um we try and be as quick as possible within our onboarding. The what we found is getting people to just connect two sources usually again CRM and billing plus build out some sort of dashboard is the activation point where it sort of clicks in their mind and it's like okay understand what this tool is for now. And then after that they can of course feel free to um connect everything else but more interesting than not is building out the metrics and the full semantic layer is very very

[21:00] different for every company. It will say it's completely possible and and we have gone live with companies where they have tons of metrics, tons of custom definitions in days, right? And then next day, boom, everyone's using it. Everyone's, you know, run queries against it. Now it's being stress tested in real time. And of course, we're sweating because we're like, "Oh my god, there's so much." But for the customers end, it's it's the the onboarding is is not so linear. You don't, you know, start with defining all your metrics at once unless you're a very very hands-on and fastm moving company. And so it it purely depends. We try and make it as easy as possible for our customers, but from what we found, it it purely depends on how big of a problem is it for them that they're willing to spend time on on filling out all their metrics and definitions and then B, how fast are they willing to move to to fill all those out and get them accurately done and get them up and running as fast as possible.

[21:48] You are selling analytics to GTM teams. What does your own pipeline data inside Lopez tell you about your conversion funnel? Yes. So, this is also another very interesting aspect. What we have found ourselves was we were actually putting out a couple blog posts for a while and this is we've sort of applied our own learnings as a use case for our customers which is we would put out we put out two different blogs and this learning actually came from LinkedIn. I was a first analyzing the LinkedIn algorithm and people were like hey you want to make sure that you know you go deep into a topic. You want to talk like an expert. That way your post gets shown to other experts and that you know those can be like either high intent leads or followers of your content and then you you can draw them down the funnel. And so I was thinking okay does this apply to to blogs for example as well. And so we we we put out two blogs and one of the blogs uh of course we we put out on on social media and it did really well and it got 10,000 right and then we put out out the second blog and uh the blog didn't do as well but it still did

[22:49] pretty good. It got a,000 views and the second one was a lot more specific, a lot more nuanced, a lot more on hands with the problem. And we were like, "Okay, from a marketing perspective, right, the marketing person would of course be like, oh yeah, this one got 10,000 views. Let's make more like this, right?" We're like, "Hold on a minute. Which of these leads from these blogs actually ended up being the highest paying ACV customers? And which of them ad ended up becoming power users of our product?" And what we've realized ourselves was from this second blog that only got a,000 views, we got higher paying customers. We got more money than from the first one. And the customers from the second one ended up becoming a lot more active users of a product than than just the first one that was like surface level. And so that's a huge unlock for for our own business. If you can scale this to to much larger companies, much more complex go to market motions. And that's that's the sort of story that we try and tell. So you don't have to be bundled up into MQL versus SQL 24/7. You can see the full customer journeys and then make good judgment across your your funnel yourself. Beacon finds leads through

[23:51] buying intent signals. Probe is the analytics platform. Is Beacon a standalone product or a wedge into Probe? Yes. So, Beacon was was our pivot after a generative UI where we did a social media sales tool. And what we've come to realize when when we first built it was it was a you know, people needed it. It was nice and it worked pretty good. But the problem was it was just not scalable at all because, you know, all these social media companies jacked up their IPI prices through the roof. there's no sustainable way for us to keep the business running through that sort of business model. And so we ended up you know sort of taking moving away from that more towards the the data side and then as we've we found the data side um you know probe is sort of the the internal name for it but but we call it uh lus is um we've found ourselves in the sort of BI space. It's and it's a lot we found it to be it's a lot harder to build the product but it's a lot easier to to sell and to bring value to customers than just having to fight for data rights with with social media companies like to move on to the rapid fire

[24:53] section of the pod in one sentence first instinct the biggest lie growth stage dashboard style founders definitely I mean depends what stage but definitely the MQL versus SQL thing heard this a thousand times looker versus lus in one sentence looker requires you to maintain a 24/7 7 needs a data guy there. Lus just handles it all itself. The metric every GTM team tracks that measures the wrong thing. I mean I like beating a dead horse MQLSQL. There's a couple other unique ones. The belief about AI and analytics that is completely wrong. Yes, it is that fixing the layer alone will give us the right answers. The truth is that AI and analytics is very very complex and there's a lot of moving parts and unless you can bring those parts together and then also compress down the context of all those parts specifically for that query, it's extremely difficult for the AI to give you an accurate answer. And so there's so many moving parts to doing accurate analytics across your business. That's part of the reason why we're sort of

[25:56] position ourselves as as a BI tool that evolves with you, right? It's self-healing. Whenever something changes, it automatically fixes itself. That's the enablement of our product where you can you don't have to worry about, you know, maintaining all your underlying data pipelines. If you make add an activated field in Salesforce, it's not going to break apart. It's not going to pull the wrong thing. But that needs a lot of maintenance. And so that's that's the sort of understanding that we've figured out. But that is pretty complex architecture which gives thankfully gives our product a good moto. The next GTM tool category to get compressed by AI. Oh yes. Um, I will definitely say that all of these go to market automation tools need to be one and this is what I've heard from many AES and go to market engineers too is they're tired of tons of tools. They want consolidation and so it is my belief that you know like the power law one company's just going to make a bunch of these different agents or some sort of tool to build out these agents that's going to be 10 times easier than whatever is available out there and people are just going to use that.

[26:53] Every monitoring tool creates alert fatigue within 90 days. How do you prevent it? Well, we try and do multiple things, but to be frank with you, it's just a a matter of working with a tool. People usually start out, from our experience, with setting too few alerts because then they're so used to checking dashboards every day. When they don't do it, they feel like something's wrong. And so, we tell them, hey, you should probably set more alerts just to keep you up and hey, this is what changed today. Or or we do like some sort of daily briefing instead of just alerts. So, you have a couple like, oh, red signal alerts like, oh, this requires attention now. Then you have a daily briefing that's like, "Hey, that here's everything that needs your attention. Here's everything that changed." Um, and then you can dive deeper into it. See which deals close, see what's moving in the pipeline, etc., etc. And that gives people a much easier piece of mind than having to, you know, remember what to check 24/7. You pivoted because you found where the real pain was buried. You were building the governed data layer. Most growth teams do not know they are missing. If there is one structural shift growth stage founders must make about how they use their data, what is it? actually think that I've talked to some great AES in the past and they all of them have the

[27:58] same thing in common. They tell me, "Hey, I use data to grow in my own performance." And same goes for the most successful CRO and and RevOps people. They say, "Hey, we stay close to the data." But what people don't understand is too many people claim to be data driven, right? And then they just want the data to back up the claim that that they're saying, right? Being data driven doesn't mean you make the right claim and then you find data to prove it. Right? Being data driven means that you you don't know what you want to do and then you look in the data and data helps guide your decision-m right and I think going that sort of evolution needs to happen as soon as possible. Otherwise people are just going to be stuck you know in their own head making up assumptions without actually knowing what's what's happening in their business. 12 tools 12 definitions zero alignment. The dashboard was never the problem. The architecture underneath it was data does not compound when every tool defines the business differently. It compounds when there is one governed source of truth.

[28:52] If you are building GTM under real constraints, explore GTM vault. Build architecture, not activity. Thank you, Rick.