The Old Vertical SaaS Moat Is Dead. Where Are the New Moats Now?

Stephen Poletto (0:00)

Jean-Denis, it's good to see you.

Jean-Denis Greze (0:02)

Yeah, Stephen, it's great to see you. It's been a while.

Stephen Poletto (0:04)

It has been a while. You led engineering. You were CTO over at Plaid, but you left to start a new thing called Town. What's what's Town all about?

Jean-Denis Greze (0:16)

Town is an AI assistant that knows you. We call them Townies. It's an AI assistant that basically works off of your email, your calendar, your most popular SaaS, and just does work for you. And it's built on a layer of context about who you are, what you do, what projects you're working on, who do you work with, how do you communicate with those people so that it can both anticipate and do your work more like you would in the first place. So you know, our idea is that there's a lot of cumbersome, repetitive, kind of boring parts of everyone's jobs for every white collar worker, and we're trying to make those go away so you can focus on the things as a human that you like and are really good at. We're big believers that you know AI should be friendly, approachable, and easy and simple, and it's for everyone, right? It's not just for engineers or you know so-called tech employees. It's really for everyone, and so we try to make AI really feel personable. We have little avatars, and you give them names, and they're kind of hokey or a little bit cute, and you know you feel like you have something that understands you as a human, and that's gone a long way towards making the product kind of grow you know virally and have really good word of mouth, even though we're still in the greater scheme of things, in the you know one batter into the first inning of our journey.

Stephen Poletto (1:43)

Incredible, yeah. the The UX around AI seems like an opportunity. Obviously, we've all got chat bots, and folks are pretty comfortable using those, but they're kind of blank canvases. And technical people are using AI in all sorts of creative ways, but you know, creating a product UX around what AI can do for you feels like a huge opportunity right now.

Jean-Denis Greze (2:08)

I think most people don't really know what AI can or can't do. Do you know what I mean? They use it either as a replacement for a Google search, and it's really good at that, right? And ChatGPT has 800 or 900 million users because it's a better version of that, and often they cut and paste things in there to help them draft emails or do first pass at docs. But I think there's a pretty big gap between what it can do and how easy we've made that to happen. So it is a UX gap. There's a question I ask myself, you know, if you're in the subway in New York City and there's a teenager next to you on TikTok or something, and you watch how they're putting things together or Instagram. To me, it's like, oh, you know, I could never. It would take me an hour to edit that little 15 second video, but the teenager is doing it in 45 seconds. So you know, a question I ask myself is, maybe for next generation that's really AI native, it's not a UX problem, maybe for them that chat box that they can type stuff into will be very natural because they will know exactly what to ask and how to ask it, and they will get the right results. But I think most people aren't yet kind of really truly AI native, so there's definitely an opportunity, you know, there. For us, I'll give you a stat: 15% of interactions with town, we suggest. So we'll say, "Oh, you received this email. Do you want us to do this research and put together a deck? Right, and we just suggest to the person, and then they just say, "Yes, do that. That's 15% of the interactions. And the way I think about that, it's 15% of interactions that probably wouldn't have had happened if we didn't tell the person, "Hey, I can do this for you. Just delegate it to me.

Stephen Poletto (3:44)

Right. Very cool. So your team is building agents and AI solutions for folks, but then you're also using AI a lot internally. Your development team is. Would you say that your development team is AI pilled?

Jean-Denis Greze (3:59)

Yeah, we're AI pilled, and I think when, if we ever feel like we're not enough, we talk about it as a team because it's moving real fast. AI-pilled today, AI backwards tomorrow. You know.

Stephen Poletto (4:12)

Yeah, that is such an interesting dynamic right now because you know the there's SaaS apocalypse, and I think the way that people have traditionally thought of moats in SaaS products is changing and collapsing because you can build so much faster now than you could have built a couple years ago, and what you're doing with you know building these these assistants, these personalized assistants, I mean it it puts you in the competitive arena with the big dogs and like the the big tech companies, the model providers, things like that. So you clearly think there's an opportunity, and that some of those kind of advantages of the past might not exist to the same extent. So how are you thinking about AI changing? Moats and defensibility, and how that's creating opportunities for startups like yourself.

Jean-Denis Greze (5:06)

One answer is I don't know, in the sense that nobody knows where the what exactly the moats are going to be in one year, two years, five years. Whenever we settle from the current wave of innovation, but the best way to find out is to kind of to be in the arena, right? And you're in there, and you're trying to figure it out with everyone else, and you're getting the product signal and the market signal as early as anybody. So you know, I don't think you could have sat around in 1998 and understand what would make you know some internet companies really successful. I don't think you could have sat around you know in early MySpace, Facebook land, and known kind of what the moats were going to be there. So you can theorize about it all you want, but part of it, the answer for me is pragmatic. You got to be in there doing it. There's a few things I am sure about, which is some of the existing moats are gone. So you know, vertical SaaS, the last 15 years of software have been really interesting because you could start a company, spend a year building your first product, and then you kind of got product market fit, and then other people would notice that and they would want to copy your product, and it would take them a year to catch up. But by then, you'd had another year of more input from users, so you're ahead, and then they would catch up again. But then you're a year ahead, so the end result is in most vertical SaaS. By the time you had the two to three top companies, they would just stay ahead of everybody else, and then eventually venture capitalists are like, "I'm not investing in the fifth company because I'd have to give you so much more money just to catch up with a product roadmap, and then the other people would be ahead of you.

So I think that dynamic is dead, unfortunately, because now you can copy someone else in weeks to months, and so when you can copy someone else in weeks to months, any advantage to being early in product disappears pretty quickly, and so I think in a sad way for someone who's benefited now. For I'm old, I'm 47, so I've benefited for you know 20 plus years of my career from software being both you know not having a supply of enough engineers and then even once you got the engineers it would take a long time to copy things. I benefit from that economically tremendously, and I think that advantage is going away. I'm sure of that. But there's a bunch of other advantages that I don't think are going anywhere. Right, so, distribution actually, distribution might be more of an advantage today because it's easier to build the plus one features that you can use your distribution channels to send to users. So that's true. Network effects, I don't think, are going away. And actually, I question ask myself quite often: what do network effects look like when there's a lot of AI agents going around, and there may be very interesting network effects that no one's really on Earth that could make businesses more valuable, you know, than they've ever been. There's clearly you know there's a lot of questions around data moats and whether trajectory data or private data will end up itself being very valuable. I am. I don't know where that lands. I just think it's going to be increasingly hard to build companies that don't allow their data to be shared if the user wants it with someone else, because everyone wants…

Stephen Poletto (8:17)

MCPs and interoperability and to build custom workflows…

Jean-Denis Greze (8:22)

And because it benefits the LLMs need more data to be successful, and so I think if your whole business strategy is I'm going to capture more data and not make it available, I think there'll be more skepticism. I mean, this is put it on the street, but you know there are some large enterprises that 18 months ago signed large contracts with one of the frontier models to power some of their, say, enterprise AI offerings, and that company is no longer leading as much as they once were, so to speak. And those enterprises are like, well, I kind of wish my data wasn't. It's not just about the LLM model that they're using from that frontier, it's like they're using their rag pipeline, and I think some of those enterprises are like, well, you know, you're not winning, and not just that, the Chinese models are really cheap, and so I wish I could take all these things that I've built on you and make it available over there, and you know now they're doing that, and so you look at that and you got to be like, well, I don't know who will be able to stand up and say, "No, I will not allow my data to be federated. I mean, Salesforce, right? Just literally, in the last two weeks, has jumped on the, "Hey, okay, kind of fine. You can more freely access our data in our system of records. So I don't know about data modes or trajectories, but we will see what the moats are. I believe they're going to be there. I wouldn't be in the, you know, I wouldn't be out there building if I didn't think they would exist.

Stephen Poletto (9:43)

Well, let's talk about speed a little bit more. Speed is now a table stakes, and you know, the folks who are embracing AI are delivering faster than those who aren't. Given that your team is AI build. And I'm seeing the velocity of town from the outside. I'm watching what you guys are shipping. It does feel like the velocity is different than it was like two years ago. How how do you see it as a leader observing your team and pushing your team? And what can you do now that you would have struggled to do a couple years back?

Jean-Denis Greze (10:20)

Yeah, I mean, the velocity at which we operate is truly, I don't know if it's 3x faster, 5x, or 10x, but it's in a different universe than most of my software engineering career before. We were talking about earlier about, we build a mobile app in two weeks. Was it amazing? No, but it was an MVP that we could get user feedback from and iterate on top of and it was secure and safe and deployed and you know had five out of the top 10 features that users wanted out of mobile. It's crazy, right? Because when you and I were Dropbox, you know it took six months to build a mobile app from scratch or something.

Stephen Poletto (10:56)

The Apple approval probably took longer than the build did.

Jean-Denis Greze (10:59)

Oh, 100%. I mean, we're still not launched in a bunch of countries because we're just going to jump through all the hoops. Yeah, it's nuts. Yeah. So here's what we do. First, frankly, we look at Anthropic's velocity, and we're like, oh, that's kind of the gold standard. I mean, that company, not all of Anthropic, but the Labs Group that's responsible for Claude Code and Cowork, they're shipping at very high velocity. I'd like to think we're faster, but I mean, for us, we need to be at that order of magnitude, or it's over. And so we have a few. There's a few companies like them or Ramp that we look at, and we're like, hey, they are showing us what's possible. And I wake up every week and I ask myself, are we within 10, 20% better or worse than those companies? And if we're not, we need to have a conversation about it. The second part of the team is we talk about AI a lot. We just talk about it at lunch. We all are talking to our friends at labs or different other companies that are doing well, kind of trying to understand how are they operating differently? What are they doing that's better? You know, how could we change about how we build? And there's a lot of information sharing. You know, it's not all just you know vibe code all the time, right? Some of it is on this area of the product now. It's been way too much vibe coding. The time has come to build it again. And before that, as an engineer, you never would build again because it was, or rarely would because there's huge investment. Now, building again from scratch, once you have the tests and the evals and the proc requirements, actually is you can do it pretty damn fast.

An interesting little tidbit for you: there's a bunch of companies that literally have 20% of their engineers. These are smaller places, but their job is to just do red diffs, red PRs, PRs that are just continuously removing code. Because you all know, if you use a lot of AI, it's a lot of green PRs. It's always writing more code, reinventing. The problem with that is then the next time around, it takes longer for the LM to know the right way to do something because there's too much code, too many ways to do the same thing. So if you view it that way, if you reduce the complexity for yourself, you're also reducing the complexity for an agent, which makes it faster the next time around. So there's some of these learnings that we hear from other teams, and then someone will maybe try it, and then at lunch they'll talk with the rest of the team about how they did it. That part is big. I just don't think it's figured out. So if your motion has to be. We're always talking about it, and sometimes, by the way, you some Twitter influencer will say something, and you will try it, and it just will not work. And you know, you're in the world of people are just bragging more than anything else. That's why I can't tell you for three times faster, 10 times faster. I can't tell you exactly what part of our process makes us faster because I think some of it is working, some of it isn't. We're 11 people, so how do you judge it? But we try our best. And then the third pillar, which is this is old school engineering, is I believe that clock speed determines how fast you ship. So we have a crazy clock speed. We say we will ship one large major feature every week, and we usually know the next two or maybe three major features. So that means effectively, at any one point in time, one or two people are working on what's shipping next Monday. One or two people are working what's shipping the Monday after that.

Jean-Denis Greze (14:13)

Maybe one person is building the prototype MVP of what's shipping three weeks from now, and everything that we've shown, nothing has taken longer than three weeks so far in the history of the company. And I think just putting that constraint, it's a hard constraint. People don't like it. It means sometimes we're working on Saturday and Sunday because we don't quite have the level of polish that we want for the next Monday. But it forces people to be really creative with the tooling to get there. Human beings are very creative, and so when you put constraints on them that feel impossible, people will find some way to power through. And what's cool about AI is I think people can test their hypotheses about how to be faster, the ingenuity, much better than ever before. So I actually love that constraint, and it's been huge. For us, and even when people thought it would be impossible to do something, we've almost every time figured out a way to get it done.

Stephen Poletto (15:07)

Very cool, yeah. And something that I heard in there is this idea of prototyping and getting to market fast to get feedback, with comfort to come back and rework, like almost discard or rewrite or revisit the code that you use to quickly validate an idea, right? Is that is that something that you're incorporating into your kind of product development mindset at Town?

Jean-Denis Greze (15:32)

Yeah, I mean, I've always been a big believer of prototyping. When you're an early stage company like us, you know, we don't have a million users, and we don't have, you know, J.P. Morgan Chase is not today a customer of town. Our customers are smaller and more understanding of what I would say experimental features. So when you're lucky to have customers that are willing to deal with the pain of inconsistent UI or a feature that works 95% of the time, but 100% of the time, you can afford to ship prototypes. And just like you said, sometimes the prototypes work, sometimes they don't work, and you just throw them away, right? Or you get better input into what to do next. So we're lucky to be there. I would like to think we can keep that development process much longer, but you know inevitably once J.P. Morgan is a customer and runs their entire AI and ops on top of town, we probably won't be able to put them in the prototype new feature. So you have to think about that. The second part actually goes back to the chat box from before. This is an interesting thing about AI. People expect that it won't always work, which is kind of cool when you think about it, right?

Jean-Denis Greze (16:54)

And then so what can happen too in the product when you build a new feature is it can be rougher, and if the AI can set expectations and ask follow-up questions of the user, you may still get an outcome that's okay for everybody. So it's actually easier, I think, to hide kind of broken parts of the UX because you should you can just have a prompt. You have a new tool that's supposed to do something, you have a new tool that's supposed to generate walking maps in your neighborhood, right? It just turns out that it doesn't know about hills, and you live in San Francisco, and people use the new tool, and they're creating walking maps, and you could just have it tell the user, hey, I'm just not good at hills, and just you should know that this walking map is not hill aware, and I can't make a walking map that's aware of hills, but actually, I can search online, so maybe I can you know find a topographic map and try do my best to tell you that in case here I have asked you in fact to go up and down a bunch. It's kind of weird. It's not the right product experience. You wish the tool just did it correctly, but the LLM can hide itself, hide its shortcomings in some other way. So we found that to be an interesting aspect of the product experience, or we also, another example for us is we draft emails for users, and the reality is if you get 100 emails from our users that are supposed to have draft replies, maybe we can only write good draft replies half of the time, and the other half we just don't have the information to write the right answer. We just don't know what it should be. Well, so what we just do is we just don't do draft replies for the other 50% and we're just like, oh, can't help you, right? And from the user, we thought they would experience it as weird that sometimes they get drafts and sometimes they don't. But actually, their mental model is like, huh? When I get a draft, it's helpful, and when I don't, I would just have to do as much work as before. And so, you know, you can think about how does the UX expose your experimental feature in a way where it's not maybe as jarring for the end user? Right. So I spent a lot of time thinking about it, but I do hope we can prototype forever because it's so much easier to prototype than it's ever been.

Stephen Poletto (18:51)

Yeah, and this this kind of relates to a LinkedIn post that I saw you make a week or two back where you were talking about evals, right? Like a new model comes out, and the new models are being assessed against these benchmarks, right? So, oh, they're they're better. They're doing better on you know SWE-bench or whatever. But then in practice, what does that mean for your product UX? And actually thinking about like the evals that you have in place for your product. And at the end of the day, to some extent, there's no substitute for good user feedback, right? That's the ultimate eval. Is like, do people like it and want to buy it and stuff like that? But yeah, I'm curious, like, because you're going through a lot of this. There's there's probabilistic dynamics in the things that you are building. How how are you doing, like, kind of those those evals and and thinking about whether something is an improvement or not as you're iterating?

Jean-Denis Greze (19:41)

I mean, you know, the real answer is I think we just don't have enough data right now to do it the way I want to do it. I want to do it with A/B testing. The way I want to do it is I want to get a new model. I want to put some users in it. I want to see the trajectories. Then I want to have an LLM automatically, tweak. Prompts based on whether the trajectories are not as good as they should be, and then I want to A/B test the tweaks. And I think I can't automate a lot of that, but I think we could automate a decent amount of it. That's what I want to do. But for us, we just there's a lot of areas we just don't have enough trajectories where we could A/B test, and so then you're in a tough spot because you get a new model, and even if the benchmarks are much better, often the new model is not as good for your users for really dumb reasons. Maybe it's more verbose, and this may seem not a big deal, but your users are used to a paragraph long answers, and you put in you know GPT-5.5 or something, and suddenly you get three paragraph answers, and even if the answers are better, your users get annoyed. It's not the same voice, you know. So I think for us right now, it is tough to go across providers because I do think Anthropic and OpenAI and Gemini they spend a lot of time across version bumps, making sure that their models, quote unquote, feel similar as the last one. So that the feel part is hard because if the feel is different, you really have to adjust your prompting, and the problem with adjusting the prompting is suddenly all your evals won't be as good with a new model, and so then you have to ask: Are they not as good? Because the model is not as good, or it's because my prompting is not quite right for the characteristics of this new model family. And then even within a provider, even within Anthropic, you will get some of those issues. So you know, for us, it's usually we'll try the new model internally on our team for a bit. If we think there's some areas where it's much better. Then we'll put it there. If we're not sure, we're like, might as well stay with the old one for a bit longer. Maybe two version bumps. The quality increase will be you know much clearer.

But the answer for you is we just need more scale. If the companies that I've talked to that have a lot more scale that can take more of the A/B testing approach, like you said. The A/B testing with are the end results there for the user? Can you see the user behavior? Those are much better because when you're doing evals, you're at some point you're judging. You know, you're making a judgment whether the feel and the trajectory of this conversation is ending up at the right result. Right? It's not. Right. It's not objective all the time. People aren't saying, "Hey, what's two plus two? Right, where you can be like, "Oh, well, if it's not four, it's wrong. People are like, "Hey, can you do research on these two competitors? This one wrote a new blog post, and it's just like, what's the right answer to that? You know, the right answer is: Are people using the research report from the LLM or the typing all caps, "fu model. Why can't you get it right? Don't you understand that I was asking about this other blog post? You know, your eval is not gonna help you there, unfortunately. If you have a better answer for that one, let me know because that is when you're in pure LLM land, the trajectory stuff is the, you know, it's like the water of life.

Stephen Poletto (23:04)

Well, I see this a lot on like the coding side, right? Because code ultimately is truth of how products behave. It's executed. There's a output that is either correct or incorrect, right? And we're now using nondeterministic systems to generate code that we want to determine deterministic outcomes, right, and to have correctness. And so the techniques that I'm seeing is teams investing a lot in the harness, the infrastructure, the code review, the quality assurance that guarantees that we'll just let the agent run for longer and let it run into the the bumpers and let it run into the test failures and and get feedback that it needs to try again because if you don't have those things, it's actually really hard to steer these agents toward correct outcomes. And then senior engineers complain about code review and AI slop and things like that. So this whole game of like how do you invest in taking nondeterministic systems to become deterministic, I think the software engineering discipline is going through that journey right now, and there's a lot of corollaries to the ultimate product experience that we're going to want to shape for customers. We're going to want maybe not 100% determinism, but like a reasonable level of determinism. And I think the harnesses and the support and the tooling around this stuff is going to evolve as this develops as like a new practice and a new skill of the trade. Maybe one final wrap-up question: Just as you've been using AI internally with your own development practices, have you found any good hacks, tricks, harness techniques, things like that that you feel like the team is getting better outcomes from their use of Claude Code or their use of Cursor. Is there a lot? I imagine there's a lot of rampant experimentation. People kind of sharing things that are working for them. Any techniques that you would recommend to to folks who might be listening in?

Jean-Denis Greze (24:55)

I mean, a really basic one is we find that having a plan discussion with the model, but when you tell it, it's not allowed to write any interfaces at all. Because one thing we found often is you put it in plan mode and you explain what you want to do. It asks you some follow up questions, and then immediately it's telling you where the systems are and what the interfaces are. And as soon as it does that, you're like, you know, your aperture has gone from this to that direction. And as an engineer, sometimes you feel like there's still a lot in there. There's a lot of details, but actually, you want it to be in just abstract, one higher level of abstraction for longer. So, some real simple tricks is tell it not to write any code, any interfaces, any stubs, have it provide potential architectures. Then the second trick on this is you want to get rid of its trajectory. So ask it to put it in MD, close it, start it again, or you know even better. I personally do this. I don't think a lot of people on my team do, but I love to go back and forth between Codex and Claude in the plan mode. But the point is, just start again and just be like, an engineer gave me the spec, and this is what we're trying to accomplish. Critique it, tell me what the what are the pros and the cons. Just doing that before any abstractions are written in code, I think, is very helpful. So that's one trick that I would say because it's, you know, now once you've got the right plan, it'll implement, there's variance within the plan, but it'll do a decent job.

I think the second thing this is not a trick, but you got to this is where you need discipline, in my opinion, is if you tell the AI to do something, and you don't have just the right function written for it to do some building block of that thing, it will write the code from scratch. It just will do it. You know what I mean? It will not find the right util. It copy your util function and right now, the one three lines different. Yeah, and it's just so I think there, what it's hard to stop because you're when engineers in these mode usually you don't mind so much, and then when you get to 700 line PR, you might not notice because your codebase is huge, right? It's 400,000 lines of code. You don't even remember before the code was handcrafted, so you remembered all the things. Now you don't even remember really where the things are. So that's this is a problem. You know, Claude has a Claude Code has slash simplify, which is pretty good. So I do slash simplify way earlier, meaning I so I have the plan and then I get the stuff like that. I'm like, hey, let's come up with the stubs. What are the functions? What are the classes? What are the modules and components that you have? It shows that to me, and then I'm like, okay, okay. Now go look in the code base for things that are below this that you might need, and document where you're going to reuse and what you want to abstract away. And I have an abstraction plan where it basically figures out what code reuse it wants before we're in the final code, so I spend more time on those two things, and usually when I have those two things, I feel pretty good. And then the third trick is the one I recommended before, which is I think you should just do this. Someone just go in a set of files that work together, sit down, and be like, hey, let's refactor this together. Just talk to it, what's the extreme? Tell me what the extraneous code. How would you write it again? You know, and if you do that, I guarantee you, you can shave 2,000 lines of code almost everywhere in your codebase.

Jean-Denis Greze (28:30)

But no one spends the time doing it. It takes really discipline to spend that time. But I, we found that good. Usually, we don't do it everywhere, but we have a part of the codebase that we know we're going to work a lot on, and we know it's gotten a little hairy, and we do that. And then the final advice I would have that we just started doing this is we had pretty bad performance because too many REST endpoints were being called from the front end, and you know the caching wasn't quite right, and so now we've added performance metrics to what gets reported to the PRs, and you know the discipline is much like when you have a PR, you're like, hey, review it for security, review it for simplicity, just review it for performance, and this is one of the things about LMs. If you give it more input and things that they have to optimize around, like all the tests have to be green, like no page load can be longer than 200 milliseconds, and it has the data and it can just test it. Yeah, you will get better proof of something.

Stephen Poletto (29:37)

You spin up an environment in which the agent can exercise the code and test everything, and and run prep tests.

Jean-Denis Greze (29:42)

There's no difference for us between what it can do locally and what it can do in CI/CD. We're lucky that we just started with that, so it always has full access to all the things. I'll just say this out there. So, you know, I mentioned we built both an iOS app. We actually also built a desktop app. And the speed up on iOS is less than on web, it just is, you know. And it's both because there's probably less training data, right? There's probably less open source of world class iOS apps, so there's you know it's not quite as good at engineering them the right way. But also on iOS, you can't be as fast because if I mess it up, I'm like a broken build out in the universe, and then I got to get people to auto upgrade. Right? We're more careful with iOS, and what's so we get less speed up, you know, of it than everywhere else. And so I think this is a lesson for me from Plaid is, you know, if you're building, if you're competing with Anthropic with the same constraints as Anthropic, then you sure as hell need to move faster than Anthropic. But if you're not competing with Anthropic, you're competing in healthcare, and the constraints of what you can get right and wrong are different. Your speed is going to look, you know, fundamentally different. And so, you know, we're building a prosumer, you know, agent that automates work for you, that helps you with email and so on. So, no, I know who our competitive set of companies are, and also know the parts of my product where I can't afford to move fast, and the parts of my product like data privacy and security that absolutely can't get wrong. And so, again, it's not like we have a universal software development lifecycle model everywhere because different things need to be done differently. Our storage system, our key rotations, those things have to be done very well, and we're not vibe coding key rotation, right?

Stephen Poletto (31:28)

That's something that I feel is often missed in the Twitter influencer discussions about all of this. It's the the lack of nuance that different customer profiles, different platforms, different domains merit different constraints on how you develop.

Jean-Denis Greze (31:45)

If you're a big company with lots of enterprise data, and you're wondering why is your database team not, you know, surfing? Well, they're not moving at light speed because you don't want them to. Maybe they should be 20% faster than they were before, but a 10x speed up there makes no sense. If you're an early stage startup like us, and you're doing a lot of front end and product work, and you've not found a way to be multiples faster, you will lose because there on front end especially, right? Where your API endpoints aren't moving, oh my god, why is it not moving fast?

Stephen Poletto (32:19)

Excellent closing thought, Jean-Denis. Big thanks for spending the time with us and sharing some of your learnings from town. Where can folks check out town if they want to check you out?

Jean-Denis Greze (32:30)

Town.com. We have the four-letter domain. Yeah, town.com. Try it out. It's fun. In two weeks, this may or may not be out. But so you heard it first. Where I have little new avatars coming out, and they're very, it's very cute. I don't know if you read like Philip Pullman books or whatnot, but there's a thing where we're trying to make the AI feel approachable. So just for that, people should go to town.com and check out cool avatar universe. Can I think Span is that okay? Because you ask, I do look at engineering productivity actually on Span to see kind of you know not just the relative speed of team members, but also of different areas of the codebase. And I'd want to give a shout out to that because I think for the team members, it has actually helped me realize some people are doing pretty fast stuff, working on the same areas as others, and encourage conversations, and then just from you know the codebase overall, yeah, it's not one universe, right? The entire codebase may be a mono repo, but not from an AI perspective. So yeah, it's a great product for that, and it's you know we're still very blind in terms of how to use this stuff, but you're doubly blind, I think if you don't have some analytics around it, which most of us don't. Anyway, I don't know if you want to use the target plug, but I believe it. Otherwise, I wouldn't have said it.

Stephen Poletto (33:48)

Thanks for the shout out. Thanks for the shout out.