# AI in Operations: Build vs Buy, Data Warehouses and Internal Tools at Lanch
Guest: Leandro Gross — Head of Growth · Lanch (Loco Chicken)
Published: 2026-05-29
Series: Business AI Explained
Canonical: https://www.elementsagents.com/podcast/lanch

SPEAKER_00 0:00
Hi everyone. I'm here today with Leandro Gross, who's the Head of Growth at Lanch. Lanch is the company behind Loco Chicken — a network of ghost kitchens and quick-service restaurants selling chicken across Germany, Austria and beyond. They launched in 2023, and what's very interesting about this model is that they went from zero to around $200 million in revenue in just over three years. Leander, thanks so much for being here. I'm finally super happy to have you on the podcast. Can you tell us a little bit more about the company, your journey since you joined three years ago, what makes the company special, and your role in it?

SPEAKER_01 0:10
Thank you so much for letting me be on the podcast — I'm super excited to be here. So I joined the company three years ago, pretty much when we started, as one of the first employees. Currently I'm Head of Growth, so I'm making sure that we grow quickly and in a very healthy way. That's my job, pretty much. As you mentioned, we've been on a crazy growth journey in the last couple of years. We started off as a pure ghost slash virtual kitchen company. We find different restaurants that are in large and medium-sized cities, sign them, deliver ingredients to them twice a week through our supply chain, and then they sell our menu and our offer over the delivery platforms — so Uber Eats, Wolt, Just Eat Takeaway. That's the way in which we started. In our go-to-market, we worked with the largest celebrities in Germany to basically launch the brand. Then we quickly came to realize that we can make even more revenue if we build our own physical locations. So we went into the QSR — quick-service restaurant — space and started building physical stores. We built over 20 stores in one year, which was a huge jump, and hired around 300 employees. And then we realized that we can grow even more in the franchise segment. So we're now also actively franchising and expanding to the Nordics, while continuing to grow the ghost kitchen segment with our Switzerland, Austria and Netherlands expansion. That's pretty much Lanch in a nutshell.

SPEAKER_00 0:20
That's very cool. I'm super happy we're having this conversation, because the goal of this podcast is to talk about how you can implement AI in operations. When we talk about a quick-service chain selling chicken, we don't necessarily think this is a company that would be AI-built or running a bunch of AI workflows to help it grow. But to go from zero to hundreds of locations in three years, something must have happened — product-market fit, a lot of demand, and you're also using all these underutilized kitchens. Can you tell us a little bit more about how your role has evolved over the last three years, and at a high level how you've been using different tools to help you achieve that scale?

SPEAKER_01 0:30
From an operational standpoint, managing so many different ghost kitchen locations is a real challenge. For one, you don't own the kitchen operationally — these are partners we work with, and they're not even under a franchise contract. They're licensees. So you have to find ways to understand what's going on in the kitchens. One of the first things we set up was our data warehouse, to make sure that everything is integrated in the right way. That means having integrations to all of the delivery platforms, to our supply chain, to all kinds of stock data — all of this information we needed in advance to be able to manage the business and the performance, because there are millions of data points coming in every day: the ratings, the comments of the customers, when deliveries arrived, what was ordered, when it was ordered. We needed all of these data points to make sure the locations were operating in a profitable way. Over time, this turned into our partner portal, which is basically an app that the QSR stores and the ghost kitchen partners use to manage themselves. We've been able to build many features into that platform.

SPEAKER_00 0:40
I think that probably takes us to the kind of tools you built internally. But if we take a minor step back — your main channel for growth is basically growing your number of locations and increasing your capacity and sales. So how are you using AI to identify those locations, to decide where you should grow, and to make sure that these partners are performing as expected? Can you tell us a little bit more about a specific workflow that's helped you achieve that?

SPEAKER_01 0:50
For sure. The amazing thing about having a really well-structured data warehouse is that you have live data coming in that you can use to run your operations efficiently. From the first moment we onboard a partner, we immediately start tracking their revenue and their orders, to understand — after the platform fees get taken away — what their profitability is from working with us. We can live-calculate: are they profitable currently, and are we profitable currently? And we decide whether to invest more or less care-time into them. That basically drives all of our operational decisions, and it's an essential part of our growth model. Another aspect where AI is extremely helpful is just writing all of the SQL queries quickly that we use to interact with this data. In the past, companies were structured with an entire data team that communicates with the strategy team — an issue gets framed and documented, it takes two weeks, and then you come to an insight. Now it's basically done in a couple of minutes. So on a high level, it's helped us really refine our growth model and figure out edge cases really quickly.

SPEAKER_00 1:00
You mentioned a couple of times that this data warehouse was a big project. So how do you determine that a project is worth investing years into? In this case it's fairly clear — you needed food traceability, it was core to the business model. But you're also talking about building a bunch of applications on top of this data. So how do you think about what you should build internally and invest a lot of time into, versus just buying tools off the shelf?

SPEAKER_01 1:10
I think the easiest way to make that decision is whenever there's any kind of structured database necessary. CRMs are still 100% necessary, ERPs, the data warehouse itself — they're your source of truth, which you need to base everything on and run different workflows out of. Those are something you shouldn't build with AI, because so much business logic goes into them and they need to be structured well and not vibe-coded. Then, taking one step further, it becomes a question of how much time it takes the team to develop this. Is it the tech team? Is it someone in the strategy team? Are they the right people to build it? Then you continue further and ask: are there even any tools you can build this with? The highest-impact operational tools that we built — front and back end — were the ones where there just wasn't any solution in the market. A great example is our route optimization tool. There was no way to map all of the delivery areas in Germany on a physical map, have all of our leads and existing stores in there, and then include a route optimization feature. For years we were stuck with this classic CRM structure, and our reps didn't really have a great overview. Now they have a perfect overview of Germany — exactly where to place new partners. That was a case where it was technically complex, but we could build it, and it was worth it because there just wasn't anything in the market. That's the mental model I would go with.

SPEAKER_00 1:20
It sounds fairly complex, to be honest. And if I recall correctly, your background isn't that of a traditional developer — you're driving growth, building teams, testing channels, doing ads and influencers, growing the franchise. So there's only so much time you can dedicate to building. Do you have specific tools that you're using? How did you get into this? Did you know how to code before? How did you build the muscle?

SPEAKER_01 1:30
It's a great question. I started like everyone else. I started chatting with ChatGPT, and quickly came to this moment of, "wow, it can actually handle a lot of complexity." I can write different SQL queries, or I can upload a CSV or documents, and it provides valuable results. Then I quickly flew into this whole world of workflows and AI process automation, which I guess the entire company did. We realized we can take quite a lot of work off people's hands by setting up AI workflows. But at some point you realize these workflows are quite hard to maintain, and quite complex to scale, since they create a lot of maintenance if they're not built in the proper way. Then I started learning about how to set up applications. Replit and Lovable are great places to start, because they provide a lot of structure. They have a direct integration to Supabase and the cloud in general, you can see how these apps should be structured in terms of which functions to use, where your secrets are, security, all these things. As soon as you get a concept for the six or seven repetitive components that are in each application, you can let go and start working with Claude Code. My stack currently is Claude Code, GitHub, Vercel and Supabase, and sometimes Claude for design, depending on the project. You just get better at it over time. It's quite a challenge in itself, because you can get lost in over-optimizing the whole time, and then you're building an MVP or a prototype for two weeks.

SPEAKER_00 1:40
You mentioned that you hired around 300 people. I guess not everyone is as excited as you are to build out all these tools. So how do you think about adoption? Are you encouraging everyone to pick up these tools? Is it coming from the top? Are you hiring younger profiles who are excited about AI? Or is this something you're trying to centralize? How do you think about building tools and overall AI adoption across the company?

SPEAKER_01 1:50
It's important to distinguish here. We have around 70 people at our headquarters working at Lanch, more or less. And then on the Loco Chicken side, in the physical stores we own, there are lots of blue-collar employees who are part of the stores. How we came to implement it quickly at the headquarters was by communicating it a lot, and stressing the importance of even having access to these tools. A lot of companies haven't properly provided access to language models to their team. And then giving the freedom to experiment in general. You're completely right that it usually starts with smaller intern projects that then get developed into larger themes and developed more intensely. That's actually where it started — with our strategy associates and interns. Then we integrated Claude Code across the tech team, and that was the second part. Then more and more people in the company started to work with AI. Usually it starts with you seeing more ChatGPT-prompted messages in Slack, and then you see them coming up with more specific workflows and their own tools that they build. The first step is being open — pushing everyone in the company to start working with it. Then, once everyone is comfortable and using the tools, it's more important to channel that more effectively, because it can get quite expensive. One of the tools we used to do that is PRD documents. We clearly write down what the requirements are, what the problem is we're solving, and then we come up with a prototype, which we cap at around two days. You have to set it up within that time frame. As soon as we have positive feedback and our tech team has evaluated it, we move forward and make a decision on whether the tech team builds it, or someone on the strategy team can build it and then go forward with building an MVP.

SPEAKER_00 2:00
You touched on cost. In the news in the last couple of days, a lot of companies are stepping back from granting full access and unlimited tokens to their teams, because they realized they hit their token budget five months into the year. Is this something you've come across — people going completely nuts and building a bunch of useless tools, where it feels like productivity but it's just procrastination? Or people not having the capability to tie a business outcome to whatever they're building? How are you actually managing costs across the company?

SPEAKER_01 2:10
That started to be felt more when the new Anthropic models came out, just because you hit your limits much quicker. I think everyone in the market had that same feeling. It also depends on how much you understand which prompts you're letting go — people in the tech team and people who understand the infrastructure behind it more are more responsible with the costs. We actually found that we had to set up limits quite quickly, especially within our internal tools. We use LangDock, which has a similar front end to Anthropic and ChatGPT, but you can set usage limits really flexibly. We just took away those models that were making each user hit their limits. And one thing we also included in this PRD process was an evaluation of how much it should and will cost going forward to set this up.

SPEAKER_00 2:20
You mentioned LangDock. I'm curious, because in France there's Dust, in the Nordics there's Sana, and there are so many more horizontal platforms now that give access to these different LLMs. Do you build all of your agents on this platform, or do you integrate custom applications? How do you think about what should have a nice UI via a platform like LangDock, versus what needs some low-level custom building that can integrate across multiple channels like Slack?

SPEAKER_01 2:30
That's a great question. From the front end — and I haven't looked at Dust in detail — they're all quite similar. You have this chat interface, and I assume with the others you're able to select which model you want to use regardless of the company. Initially that was quite helpful, since there were always new models coming out and you didn't know which one was best, but you wanted to try everything and not commit to one single company. Then they started to expand on different features — the ability to add agents and workflows and skills, all of these systems that were also in the OpenAI and Anthropic structure. In general, the pricing for workflows is more expensive in these tools, since if you host it yourself in n8n it's genuinely cheaper. So not too much workflow building, but what's really helpful is the agent building and the ability to share it across the org. For general things — in our customer support, for example, we have an agent set up in LangDock that's super helpful to answer questions. We have an SQL agent that's used to write SQL queries, because it has the whole schema of all of the different tables in the company. We have a negotiation agent for making negotiation and sales decisions, which is also really helpful, and procurement, and all of these kinds of spaces. Being able to share that across the team is really helpful. Also, having one place where all of the org's general information is stored — about the brand, about the structure, about the tools we use — is really helpful. And across these tools there are individual value-adds like compliance and data security, all these things that bigger companies are really concerned with. You have that all there as well, so it eases implementation.

SPEAKER_00 2:40
You don't want to be sharing this chicken recipe with the rest of the market. Keep it on the secure LLM.

SPEAKER_01 2:50
Exactly.

SPEAKER_00 3:00
To touch on something — you have all these agents that have access to different knowledge bases. If we take the customer support agent, it takes tickets, and then you have a set of policies to handle the refunds or whatever you need to deal with. So how do you think about managing this data? By that I mean: how do you optimize this context? We often talk about context whenever we're building agents. Is this something you're spending a lot of time on? Can you walk us through how you're thinking about context in a company that has so many different moving parts like Lanch?

SPEAKER_01 3:10
The most important thing about context in general is that it's clean and well-structured. A mistake that we made was connecting all of this information and then assuming you'll receive amazing answers out of the agents or workflows you set up. A great example: nine months ago, we started structuring all of our standard operating procedures — SOPs for our QSR stores. Just structuring this data in the correct way was a huge win in terms of the inference speeds we were able to build the agents at later, the quality, the accuracy, all of those metrics. That's just standard machine learning knowledge: clean your data, structure it well, and the model performance will be better. I think what's often forgotten is that it's still machine learning — it's still just predicting stuff. If you don't understand your data model, if you don't have your different systems connected in the correct way, you can't build any agents. We figured that out the hard way. We had all this information on which fryers are in which store, all of our data in one place — but if you don't have this primary-foreign-key relationship with your IDs connected cleanly, and you don't clearly define your schema, then it's basically impossible to build an agent that gives great answers, or a chatbot, or any other kind of product. We also realized there are different kinds of retrieval systems that have completely different effects. For the chatbot we're building for our stores, we're retrieving high amounts of text data from a knowledge base that we built in Notion. And we realized that even the way we write different knowledge articles makes a huge difference. Let's say you're writing a troubleshooting guide — it's really important to think in terms of symptoms and then resolutions. And if you're thinking about a process, then you want to mention education and these kinds of things. So we ended up setting up different templates for different kinds of knowledge articles, and that really helps the accuracy and the way the responses are structured. If you think about this whole system, it's like one context base. There's context in the knowledge base, there's context in the prompt, and there's context in the model itself. The most recent revelation is that at some point you can't fill in more context in the prompt within the agent. Then you have to start looking at the model, and there are lots of companies starting to pop up that help you train models to provide better answers.

SPEAKER_00 3:20
That's super interesting, because what you're describing basically sounds like when we think about articles that need to show up in LLMs — like Perplexity, or whenever you're thinking about LLM engine optimization, AEO, GEO. You always think about how there are multiple sections, but you have to have a TL;DR — a too-long-didn't-read section at the top — which acts as a tag to give context about whether this article is relevant for the query you're actually asking. And then you have all these FAQs. So this is a little bit similar to what you're saying: symptom, diagnosis and solution to some extent. You're rethinking how AI visibility works, and you've used that mental model to reorganize your internal knowledge base to make sure you can retrieve information internally to make it helpful.

SPEAKER_01 3:30
Yeah. And also the systems that you run on top of these different retrieval agents. Maybe graph RAG or a RAG knowledge base pipeline works really well with large text documents. But you do need to set up some kind of SQL retrieval agent as soon as you're interacting with more structured data. So even the systems you need to interact with different kinds of data are really important to consider. I'm super curious to learn where this goes in the next couple of years, because right now it's more important than ever to have a great understanding of your data model — much more than you did in the past — because you can scale so much work and save so many people's time through these agents and agentic systems that you can build.

SPEAKER_00 3:40
I just want to go quickly back to the output. Do you think about evals — evaluating the output? How much time do you dedicate to that? Who's responsible for evaluating the output of whatever you're building? Is it always a technical person building the solution? If you're building an agent for a marketer, is it the marketer who evaluates the output? How is that feedback to the developer made robust? Do you have a system in place for that?

SPEAKER_01 3:50
Setting up correct benchmarking when you start is super important — you can't really improve these things if you don't have it, because otherwise you don't have a base which you're comparing every iteration with. It's really valuable to understand the different kinds of problems being solved. Let's say you're interacting with two or three of the different data sources I mentioned. Suddenly you want to understand how quick or how correct it is when it's working like that, or — depending on the tone you use, the language — how it performs. One of the most important things for us was measuring the latency, because we have quite impatient users. We can't let it take too long. But the final and most important thing is always: is the user happy with the result, and are they getting out of it what they want to get out of it? That's the litmus test you need in the end, because you're not doing electricity forecasting — you're building it for a user, so they have to be happy.

SPEAKER_00 4:00
So you basically have a capability to say, "are you happy with the result — yes or no?" A Boolean value to determine if the output is good or not?

SPEAKER_01 4:10
We don't, but I think that's what we should have. We set up the benchmarking and all of the metrics connected to that. The main way we do it is through user interviews with our store managers and shift leads, because they can give the best insight. In the long term, it would be a smart idea to include something like that as well, just to get their feedback.

SPEAKER_00 4:20
Is there anything specific that you're very excited to be working on in the next couple of months, considering the recent developments in models and the kind of tasks they can achieve autonomously now? Is there anything you're bullish on that you think you'll be able to build?

SPEAKER_01 4:30
The most exciting thing for us at the moment is providing all of these chatbots to our teams, and making sure our operations are run in a really efficient way. That'll continue to develop over time — it's always exciting to add capabilities to it: shift-plan forecasting, order forecasting, troubleshooting for very specific machinery. Those are impossible and really painful tasks that you have in the QSR space. In general, we'll continue developing that tool to set up a system you can get coached by, essentially. The other thing that's really exciting — and I think this is the case in many other companies as well — is how the buy-and-build decision is changing. We have so many tools that we were dependent on that we can now build in a much better way ourselves. That costs some time and tokens and energy in advance, but those are one-time fees. If you spend $7,000 or $2,000 developing something, you pay that once, and you don't pay that fee every single month. Those are the fees of the tools we're paying for every month. So we're able to save ourselves an extreme amount of software costs. The other exciting aspect is the effect on our tech team, because we're able to solve even harder problems. We're looking at more complex systems now, like POS, and how we can even replace those. Those are significant costs on our P&L which traditional businesses just have, and which we then don't have anymore if we're able to build it. So it changes many of the rules. The most important thing is to be really structured about it, and not to get lost in developing things that are overbuilt and that don't work in the end — and to make sure that the people building the tools understand what they're building.

SPEAKER_00 4:40
Well, if you start building your own version of Stripe, we'll know you went off on a bit of a tangent.

SPEAKER_01 4:50
Payment processing is actually a really difficult part to build.

SPEAKER_00 5:00
The POS is quite ambitious, honestly.

SPEAKER_01 5:10
It is. But in general, most of our transactions, especially for the ghost kitchens, are done over the platform anyway. So we don't have payment processing in there, luckily. That makes things a lot easier.

SPEAKER_00 5:20
There's always this debate online — people saying, "we can build this ourselves." You said the source of truth maybe it's better not to vibe-code, because you have so many deterministic rules foundational to the business that you can't really afford to clone HubSpot in 24 hours and expect it to work. It's too risky. But the other tools, you'd be able to build. Then there's something around maintenance and improving and refining features over time. So once you've shipped this nice-looking MVP that adds value to the business, who's maintaining it? Are you maintaining all these apps yourself? Is it the tech team? How do they keep up with all these tools that get built internally?

SPEAKER_01 5:30
It is, and it caused a lot of friction initially. It's also a challenge because, even within the tech team, these are really interesting projects — the way they're set up. Suddenly you have people with less technical knowledge building really exciting things, and then the engineers are just there for maintaining everything. That's culturally not a great or fair position to be in. So you really have to rethink how the product development cycle works within a company. Now everyone can contribute, so you need to be really clear on how much time you should invest in a prototype, what a prototype is, how much time you should invest in an MVP, what an MVP is, and how much you're able to spend doing these things. Just because you built a prototype in two days, it might be completely scratched and rebuilt again in a technically correct way. But there does need to be involvement from the tech team. There should definitely be a handover, because otherwise people who should be working on one-off projects are continuously doing maintenance. That's one of the most important things, because it's just so easy to send another prompt and add one more thing, and then add one more quick thing, and then it becomes much more than it should at an early stage. So it's really important to be disciplined there.

SPEAKER_00 5:40
So you'd say the functions are coming up with their own MVPs, and they build them with Lovable or Replit. Then once it starts delivering value, they write these PRDs with the help of Claude, and those PRDs are sent over to the tech team, who then build those tools from the ground up again in a more robust and secure way?

SPEAKER_01 5:50
In general, the prototype is one or two days — test the functionality with the user and make sure it has some fit in what it's doing. As soon as that's validated, we see: can we build it from a technical perspective, and what are the requirements to integrate it with the different systems we have? If it should be integrated with systems — and if it shouldn't be, that gives a bit more freedom. Then the MVP gets developed, and that gets handed over to the tech team. Another interesting aspect we've been testing more is directly integrating Git repositories with Lovable or Replit. The exciting thing is that if you control the way you do pulls, pushes and commits in the correct way, you can really do easy contributions — especially for small features — from someone who's really close to the product and the use case. Then you have different hardening jobs and skills that are specifically created for the front-end AI tool to manage and integrate the code. So there are so many changes happening in terms of product development at the moment.

SPEAKER_00 6:00
Super interesting. It's the first time I hear that — basically using a skill to pre-clean a vibe-coded feature from someone who doesn't know how to code. The skill gets drafted by a developer to make sure that everything fits correctly and has full context about how the main repo works, to ensure things don't break.

SPEAKER_01 6:10
The main issue is that most repositories aren't built to be integrated with these apps. Lovable has specific requirements. If you just upload your Git repository, it starts refactoring with a crazy amount of tokens, and you end up with a completely different product. But if you start building in there and integrate it with your Git repository from a fresh start, and you have all kinds of maintenance and hardening flows on the other side, you're actually able to build a really solid product that you can contribute to quite quickly. Obviously, later you want to be integrated with cloud services directly and not have everything run over Lovable. But at least it really understands your codebase, and the handover is really minimal in comparison to before. Essentially, it three or four x's the entire product development cycle, doing it this way, because it just has a better understanding of how your codebase is set up from the start.

SPEAKER_00 6:20
So just to make sure I understand: you're creating a new Next.js folder locally, you use these skills that were developed by your tech team so it has the right scaffolding, and then you import this repo into Lovable, and someone who's not technical can build on top of the scaffolding that was custom-built by your team.

SPEAKER_01 6:30
Yeah. You basically need to pre-check what requirements there are from the front-end building app that you have, to make sure that the codebase you're importing is compatible with it. That's the most important thing. But I think in the future you won't even need these front-end tooling apps anymore, because essentially what they do is have a visual understanding of what your front end looks like and continuously feed that into the development process. I think you can also just set it up with Vercel in a nice way as well. I haven't played around with that aspect yet.

SPEAKER_00 6:40
I think that's the debate about Lovable — is it going to go down to zero because of this very argument? But they're also shipping new features all the time, so they'll always outrun it and stay relevant in one way or another.

SPEAKER_01 6:50
The way these systems are really helpful is in maintaining an overview of all aspects of the development process. As soon as you're working in Lovable, you can see: what are the costs of my cloud at the moment? How much data am I storing? How much am I spending on the five different API integrations I set up? That's just really invisible if you're doing it in Claude Code — you basically need to set up this system and overview yourself. You completely lose the overview of which secret you have stored where, and all of these things, if you're not using one of those systems. The topic of security is also something that will be handled more and better in these systems, and it's something that, without any kind of computer science background, you're just unaware of when you start building these tools. So you definitely do need something monitoring all the coders, and if Lovable and those coding tools can achieve that, then they definitely have a right to exist.

SPEAKER_00 7:00
Amazing. Coming back to Loco Chicken and what makes it special — you guys are partnering with Luciano, who's one of the most famous artists in Germany. What's your stance on how companies will stand out in the future, now that software costs are going down to zero? How do you think about competitiveness at Lanch, and what could companies learn from how you're approaching it?

SPEAKER_01 7:10
In general, it's really important to own value in the transaction at the moment, because it's going to be very competitive to be in the software space. I think companies that are managing the transaction are in a very good spot, or that are directly creating the value in a non-software-based way. There's going to be so much competition coming up on the horizontal space, because more companies will be able to enter quickly. And then on a vertical level, companies will be pressing down and building things themselves. So the thing companies should look at right now is making sure they're creating value in a non-software-based way. All of these operational companies that are managing the transaction are in a very strong and future-proof space, and the ones that are creating pure value through software will be eaten up. Just to give an example: as soon as everyone really understands how much you can build with AI, then software is just going to become the leveling field. Other dynamics are going to take part — like how well you manage operations outside of software, and how you create a brand, and how you do your marketing, and all these things connected to that.

SPEAKER_00 7:20
So building a strong brand, and something that is operationally heavy that you can optimize with AI, is kind of the edge people should figure out how to get into. Awesome.

SPEAKER_01 7:30
For sure.

SPEAKER_00 7:40
Leander, thanks so much. I actually learned a lot, and I'm super happy we got to chat and take the time to go over how everything is set up at Lanch. Where can people find you if they want to learn more about Loco Chicken or reach out to you?

SPEAKER_01 7:50
Please reach out to us — we're always hiring. Feel free to apply, or catch me on LinkedIn.

SPEAKER_00 8:00
Awesome. Leander, thanks so much, and hopefully see you soon. Thanks for listening, and don't forget to like and subscribe to the channel wherever you're listening to this — whether it's on Spotify or Apple Podcasts. I'll see you next time for another episode of Business AI Explained.