Noel:
Hello and welcome to PodRocket. I'm Noel and joining me today is Snir Kodesh. Snir is the head of engineering at Retool, and he is here to talk to us about Retool, and what it is and what it's built with. How's it going, Snir?

Snir Kodesh:
It's going great. I'm really excited to be here.

Noel:
Awesome, awesome. We got a bunch to talk about, but before we begin, can you tell us a little bit about yourself, your background, and how you found yourself at Retool?

Snir Kodesh:
Yeah, absolutely. Let's see where to begin. I won't bore you with the very beginning, but suffice it to say, I've always been a very product and business minded engineer. I've always been really excited about technology, but also frankly, more excited about the impact that technology and specifically software can have, the scale and the efficient scale that software provides. Obviously, we've seen it completely change the world.
I'll keep this as short as I can, but very briefly, I've founded companies, I've worked in consumer, I've worked in enterprise, and I'm saying all this to lead us to Retool. To me, what brought me to Retool is really two distinct things. One, as an engineer, I've always been more of a backend engineer, to be totally honest, more of a server side suite. And my front end skillset was never that great. I jokingly say that I'm probably one of the worst front end engineers you've ever met. And so Retool is transformative for me in that it can completely compliment my skillset and allow me to take a lot of what I'm good at and bring it to a client side experience, which is really cool.
The second thing, which is somewhat correlated is having built orgs. Before Retool, I was running a large part of Lyft's engineering team, and we actually spun an internal tools teams, a health team, really, for our marketplace. So the marketplace function owned dispatch and matching and pricing and a lot of the large computational systems at Lyft. We spun up this team called Marketplace Health, which was all about helping those engines operate more efficiently.
When I think about what that was, it was about taking these large systems, taking raw logs from them, massaging that data, effectively doing ETL on the fly, loading that data into a schema that could be interpreted, and building visualizations on top of them. And so when I thought about what I had done and the degree of operational efficiency and financial efficiency that I created for Lyft, understanding those systems better, driving more efficiencies, improving filters, improving decision making, Retool is that. Right?
Retool has the ability to take that function that we were putting people on and build it in a more effective, more efficient way, lower cost to the company and ultimately allows engineers to then reallocate their time. And that's something I care deeply about, making people more efficient, and so that brought me to Retool and I'm excited to be here.

Noel:
Nice. Awesome. Awesome. What was the timeline like? Where was Retool at when you joined?

Snir Kodesh:
Yeah. So I joined about a year and a half ago. At the time, it's crazy to think about, we were 13 engineers. Credit to Retool and credit to our founders, Retool went really, really far with very, very few people, which is a really big testament to the team. When I joined the product that we have today, the UI builder was in a place that's not that dissimilar. We've improved it massively in the year and a half that I've been here, but fundamentally it was the same product. It was about how you could build UIs for internal tools lightning fast. Right? So on the order of 45 minutes to two hours, you could have a UI spun up and a lot of the repetitious tasks that would've otherwise gone into building an internal tool or web app were abstracted and taken care of for you.
We were just getting started with a lot of the new product launches that we've since layered adjacent to the core UI builder, so Retool database and Retool workflows, which we're really, really excited by, along with Retool Mobile, so those were way pre-product. And then a lot of the efficiencies that we've provided, a lot of the incremental abstractions, the re-imaging of the component library, the new debug tools, and really up-leveling that experience, that's obviously all been new in the last year and a half. But I think there were ... directionally, you could see where Retool was going when I joined. And again, powerful, powerful mission there.

Noel:
Yeah, yeah, for sure. I remember some of those early Hacker News launch threads and stuff and it was like ... There were quite a few players in this space, but there was a lot of excitement around just the ... The direction that Retool was going doesn't feel like quite the right term, but just the way in which their approach to the problem was set, their perspective on how to solve it. And I think that has led to a lot of the excitement around the tool. But to frame that a little better, give us your, I don't know, two or three minute explanation on what Retool is for listeners that may have no context whatsoever.

Snir Kodesh:
So we like to say Retool is a way to build apps at the speed of thought. And by that, what we're really getting at is that with the Retool, you can build internal tools with a fraction of the investment in time or effort that you would've otherwise had to do. So we abstract the component library, we abstract state management, we abstract event handling, we abstract all these audit logging and security and integrations work that you would normally have had to do historically and counterfactually. And you can really focus on the value on the layout, on the UI and on the underlying data sources. And obviously on that point we're going to provide additional tooling, as I mentioned with workflows, with Retool DB. So it is a way to build tools very quickly that help your business operate more effectively.

Noel:
Nice. Awesome. That sounds very broad, right? So someone coming in naively. So say you're at a typical startup and you have some pseudo ETL processes, say you've got your typical backend service, it has a job where it's uploading a bunch of data to some database that is then people are taking and doing some pretty rudimentary analytics on or watching the numbers go up. How does Retool help with those workflows? Or why might one want to introduce a tool like it?

Snir Kodesh:
Yeah, absolutely. So I think even if we take that example, we can of split that up into at least the two distinct and maybe even three distinct jobs to be done that you described there. The first is the computational work, the ETL, the processing of data, querying it in its raw form, massaging it and then landing it in a data store or data warehouse of some sort. And if you think about that, traditionally you would've had to go out and build those connectors natively. You would've had to obviously written the queries, which you still have to do in Retool admittedly, but then you would've had to run those and ensure that you're running those successfully. So retry logic, success and failure handling.
 Then all the logic for the ETL, which includes filters of some sort, conditionals, branch factors, some sort of control flow for your ETL, right? And something like Airflows is pretty good at that, which again, we believe that there's actually a better way to do it in an abstracted way. So with Retool, and again specifically the workflows product, we manage the entire control flow for you, which gives you guaranteed transition through the different states of your ETL. We also help you visualize it. Right? And then finally we give some really nice abstractions.
So you think about looping through an object repetitiously, constructs, like just conditional forks, a lot of those represented visually can actually be more efficient and more effective. And you can really just focus on the business logic. I think an interesting parallel here in some ways is Python notebooks where a data scientist working in a Python notebook will really just focus on the individual steps, but the notebook takes care of all the orchestration for it. And so with retail workflows, we're again taking care of all the orchestration and all of, again the state management, anything related to needing to retry or managing success and failure scenarios. So that's one side, which is again on the ETL side.
And then you've got the visual part, which is building the actual dashboard. So if you were to go and build that dashboard in React, you would have to go build your own React components, you would have to obviously manage the entire layout for those. You'd also have to wire up the entire app. You'd have to use Redux or something for managing internal state, and you'd have to go build all the connectors now to your data warehouse where you landed that data.
So with Retool, what have we taken away? Well, we've taken away the entire component library in the sense that you don't have to do that work. It's literally just a library on the right hand panel. You can drag a component and it works out of the box. We've taken care of all the logic again of state management, event handling's a great example. You click on a button, it needs to do something or data changes out from under you and you need to refresh it. Traditionally you would've had to code all that logic up. It's really, really simple. With one click, basically 30 seconds of time, you get that for free.
And then on the integrations point also really, really fast. So we have 50 or so, I think maybe 50 to 60 connectors out of the box, everything ranging from your own APIs, restful or GRPC, GraphQL endpoints, data stores directly if you wanted to do that. And then obviously data warehouses directly if you want to do that as well, which means that you can really just focus on making sure that your query's correct and then the data just shows up. And so the benefit in terms of why you'd want to reintroduce that into the org is that the overhead of everything that we discuss that sits behind the Retool abstraction is really, really expensive. Not just to build, but also to maintain. And so we effectively take that off the hands of the engineer. A tool again gets spun up in 30 minutes, not three weeks, which allows you to just fundamentally do more with less.

Noel:
Nice. That makes a lot of sense. I guess, do you find that a lot of customers or users coming in that they have some of this logic built out already in whatever their language of choice is or their pipeline and they've grown frustrated with it or there's been shortcomings with it and that's why they're coming to Retool? Or is it a lot of users coming in more greenfield with net new problems that they're trying to solve?

Snir Kodesh:
Yeah, actually, it's both, which is one of the things that I love about our business. Right? I think if you look at the state of internal tools broadly, they are critical to a business, even that example that you mentioned. If I take that to the limit, that's how a company learns how well it's doing, having really good dash boarding and a good understanding of its fundamentals in terms of its data, allows it to push in the right places, ask questions in the right places, so on so forth. And yet in industry, this tends to be a neglected part of the stack, both in terms of people which ultimately lends to resources. The tools also bloat incredibly and maintenance becomes really expensive.
So what we see with a lot of our customers that have a preexisting tool that they're looking to port over into Retool is that the incremental change to add a new feature to that tool has become incredibly burdensome. Nobody's a domain owner, it's Croft on Croft on Croft, and it's really hard to iterate on it. And so they will bring that and actually effectively refactor it within Retool. And I know I didn't mention this in the description, but you can literally build anything in Retool because you can write arbitrary JavaScript in Retool if you have preexisting components that you want to bring into Retool. Our component library isn't just some static set.
We have the ability to import React components in code, and we run those in a secure I-frame in a sandbox to make sure that we are not letting people have access to Retool internals and potentially internal malicious hacks to do weird phishing schemes or get access to data they shouldn't. But it's really quite powerful that we have a rich set of abstractions that are available to you arms length, but fundamentally you're completely unconstrained in Retool. You can write JavaScript anywhere, you can bring React, and we're also expanding, especially for that workflows product expanding into other languages over time.
So it fits both purposes. And the cool thing with folks who are bringing in preexisting tools is that they can actually occasionally just borrow code directly. Right? If there are components that they love, they can bring those in. So yeah, hopefully that answers the question.

Noel:
Oh yeah, I think it did so beautifully. So do you find that, I don't know, the champions in customers organizations are typically developers or are they the end users of a lot of these dashboards like the-

Snir Kodesh:
I think the strongest champion is the developer. At the end of the day, if we were to have built a product that end users love because they get more tools, but developers hate using, guess what? The developers won't do it, right? And what we find is that even if they're clamoring for more internal tools from the end user, from sort the ops agent that might not be able to write code, write sequel, ultimately that feeds back onto traditionally the product roadmap for that internal tools team. But the engineer, the developer won't engage in behaviors that don't suit them.
 And so our biggest champions and our customers, first and foremost are those builders. We deeply care about the end user to be clear, and we make sure that Retool is performant for the end users. Again, there's some really interesting stuff there in terms of we find that end users tend to have different hardware than builders, right? A lot of engineers have whatever the latest MacBook Pro rolling off the line is, whereas you'll see Chromebooks in the long tail of support workflows, and because Retool is running deeply in the browser, you see performance skews there. And so we really care about that end user. We want to make sure Retool is performant for them, but our primary customer, our primary champion is the builder.

Noel:
Nice. Yeah, that makes sense. I like that term ops agent, whoever ... It's probably hard when you're developing tooling that is at this layer of abstraction in that the persona of the user can be so varied. Is that challenging at all? Is it hard to say design sensible, like UI defaults and stuff for those end users or templates maybe for the developers that would be setting up their flows and Retool, because it's such a broad surface area you guys are trying to cover?

Snir Kodesh:
Yeah, absolutely. Yeah, that is definitely ... especially from a product road mapping standpoint, a real challenge. And our response to that has been, let's be horizontal, let's be open. And it's why we embrace, as I said, the ability to write code anywhere because that's where you become limitless. And so we have great smart defaults and great presets and there's this low floor that is very accessible. And we say this internally a lot, having a low floor and a high ceiling. The ceiling should basically be unbounded is the truth. But yeah, the range of even within the builder subset, you've got, excuse me, even within the builder subset, you've got folks who are more or less technical on the sense that maybe they're really great with SQL, but they're not so good with JavaScript or the inverse. And so how can we make it so that you can reach for something no matter where you find yourself in the stack?
Or alternatively like Partner, we actually have some really great examples of cross-functional teams. So a PM will come in and set up the layout for the tool they're looking for, and then they'll hand it off to an engineer to go fill out and maybe actually the PM will write the sequel as well, but they'll hand it off to the engineer to go wire up all the conditional logic for the button toggling, the turn areas, et cetera. So we see that, and it is why when we struggle with that, we try and go as low level as possible and stay as horizontal as possible.

Noel:
Yeah, that makes sense. That makes sense. Yeah, we keep touching on this, being able to write JavaScript anywhere because the developer persona is so important and so intrinsic to what Retool is. I'm going to ask a tricky question here. Whenever you have code executing in this hosted manner within a SaaS product like this, I feel like there's always some challenges that you guys, the platform that is executing this, are brushing up against. Are there any limitations that you guys have recently tried to overcome or work around or anything recently that's come out in that JavaScript ecosystem specifically that is new and cool and has empowered users?

Snir Kodesh:
For sure. Yeah, I mean, I alluded to it earlier, the performance problem is historically ... especially it's been a real one and we've spent a lot of the last nine months or so improving it both from an execution context in terms of executing JavaScript exactly as you said, but also in terms of our logic for how we render. And so just trying to be as efficient as possible, to batch when possible, to defer and delay when possible.
And then also maybe beyond just the technical, there's a lot of really interesting product opportunities. Right? So what we see today is the platform or the product naturally pushes you to build really, really large, single page applications. And you can bring in a tab component and bring different tabs in, but it's not intelligent. Right? The dependency graph that you're constructing when you're building your app is still ultimately one large graph that needs to be evaluated collectively. And so that is the main challenge is how do you take that large graph and break it down?
And part of that is we don't have full control. At the end of the day, if a builder goes and creates a bunch of edges that are dependent on one particular note of evaluation, it is always going to be one large monolithic graph. But at the same time, there are things that we can do in terms of helping you break out into multiple pages and think of a large ... I don't know if you're seen large support tools, but the one that we had at Lyft for example, was 10 different pages comprising of ride data and route data and user data and payment data. And obviously your access control was dependent on job to be done and everything was access logged and audited regularly. So there's a lot of security and compliance around it, but how do we help enable engineers to do that and build a tool that complex? We have real plans there in terms of how we support multipage.
But zooming back to your direct question, the execution of arbitrary code is really complex. Again, we have a sandbox which allows us to run natively, and a lot of our investments have been around reducing round trips, that sandbox moving state into the sandbox and batching. So some fun computer science for sure.

Noel:
Yeah, yeah. I'm sure that there are some tricky problems in there, but they're satisfying when you have those moments. So I feel like inevitably a lot of the use cases when people are bringing up tooling in this space are what we've talked about here where it's like, Oh, there's some data, we need to transform it, maybe call another API, and then we ended up handing it off to an analytics team or a support team. Are there other cases that you guys have found ... a lot of companies have found have used Retool to find value in where it's maybe not that narrative that we're still used to hearing?

Snir Kodesh:
So there's a few things that I would say. There's definitely the ETL to analytics, which is BI said in different terms. To be honest, BI isn't the primary thing that people come to us with. A lot of it is admin consoles and support tools like I mentioned. So it's probably through an API, but it's direct access to underlying user data. It's also joining distinct services together, which we've always found really compelling. So you can imagine a refund tool for customer support when people write in and that joins your user store to your payment processor, or Stripe, for example.
We see people leveraging it in a notification workflow as well. And that's actually something with workflows, that product that I mentioned that we're seeing more of is more asynchronous processing. So you might have multi-steps, procurement flows is probably naive example here, but multi-steps in a workflow that terminates some sort of action, or something happens and you want to pull somebody into a web app. So a big customer signs up and you want to pull them into a UI to see how they're using your product, your platform. And so that's another specific example.

Noel:
I mean, I think it leads to another question as well of ... I feel like there's a lot of entities out there or businesses maybe that could leverage a lot of value from something like Retool. They don't really know the right question to ask to get Retool or a tool like it given to them as an answer. I guess, do you think about that problem at all, about expanding the market out of these more tech companies who have devs who are looking at this tooling space and thinking about application development and systems at a high enough level where they realize that a tool like Retool could be useful?

Snir Kodesh:
Yeah. I mean, I will say just maybe on a clarifying point there, pretty much all of our customers have developers, but we do have companies that I think fall out of the Silicon Valley venture back tech business. Specifically, we have JLL as a logo and they really use this for a lot of their agents. And so I think the thing that I would ask is what does your business need to be more efficient on the margin? That might be a more effective support team, that might be a more effective field agent team. That might be more insight into your core underlying engines and systems, like we talked about with the Lyft example. That might be better proximity to your customers and having lower latency loops.
We talk about this actually a lot in the context of Retool. One of the things that made Retool really effective is that David and Anthony are founders. We're really, really on top of customer signups. And people would sign up and there would be this app, I think internally it was called Big Fish Swimming, and it would immediately notify them and they would be on the phone with a customer within an hour. And so you can see work Retool not only triggering the asynchronous, someone signed up, but then pulling you into an app to allow you to explore more about how they're using your product.
I mean, like anything in software, it's up to the imagination. I go back to some of the tools that I've built in the past, and I don't think there was any prior art on them. We were just faced with a big open question, which is, what don't we know, right? Or what aren't we seeing or what aren't we exploring? And that is what we ended up marching towards, and I think Retool really is just an accelerant to arriving at that destination.

Noel:
Nice. I think that's a great answer. Yeah, again, I wasn't trying to, I don't know, paint you guys into too much of a corner, like, oh, you're only useful at Silicon Valley companies right now, or those are the only customer base currently. But again, I just feel like when we're in this realm of tooling, it's like those tech forward companies who are always looking for little marginal increases in efficiency and how can we cut out any necessary internal resources? They look for it, but I think that the traditional model of, you have a SaaS company that isn't in quite as abstract a field, it's easy to see the marketing path forward or easier. Right?
 It's like, oh, we know this is our target business, this is how we're going to try to sell to them. But with something like Retool where it's just so open and it's like we're really just trying to make it easier for businesses to have internal tooling for support teams or just admin panels at all, like you said, I feel like that would be a tricky thing to just market towards and use for product direction and everything like that.

Snir Kodesh:
Totally. Yeah. I mean it's a really good question, again, a good point. I think what's tricky about expanding into the broader product ecosystem is frankly the attention to detail and pixel perfect control that companies want is elevated. And I think that the beauty of the internal tool space is again, that it is really underserved and under serviced. And I think again, it's not just even ... a lot of the conversation today, which has been amazing, by the way, has been around, as you said, ops and support, but sometimes it's even about internal processes.
So we actually just saw this right now with one of our customers and we just pulled it in house as well, which is a lot of companies run a people performance process, right, calibration. And the tools for that, specifically the calibration exercise, are generally underserved. You've got Lattice for how to conduct one-on-ones or how to do performance management broadly, but when you're in that room and you've got of managers sitting around and trying to assess how the company overall has performed, the tools are actually quite lacking. And so we empowered our people ops team with Retool recently and allowed them to build a tool to better conduct the process that they believe Retool needs.
 And so what's really compelling about this is if you zoom out, it allows companies to operate the way that they want to. It's very hard to imagine that a calibration tool could exist in a one size fits all manner. And that's where Retool is effective because you aren't locked into somebody's perception of what people ops should look like. You can build it for your needs, but you are right that the delta between external product facing and how obvious it is to know that, oh, I need to build X, Y, Z for my end customer versus internal applications and what internal use cases, it's a little bit harder to come up with. That's generally true, but I think that there is a real arbitrage in terms of how under serviced and under invested internal tools is. And that's what leads to ... even when these tools are built, we talked about this earlier, the product is crofty, right? The artifact built is not at the same engineering caliber as what the traditional customer product would be for companies.

Noel:
There's no tests on it a lot of the time. It's like, we've just got to get this out the door. It's an internal tool. Yeah, yeah.

Snir Kodesh:
Yeah, get out the door, move on to the next thing. Right? And so that is a beautiful place for us to play because indeed we allow you to do more with less and we allow you to build it in a way that is actually maintainable for the long run.

Noel:
Yeah, yeah. No, that's perfect. Yeah, I think it's an interesting perspective to have in that like, yeah, you're trying to attack this thing. You use that you use the term that it's hard to find a tool that is well calibrated for a specific business, a specific use case because there's so many little modalities and things that are different, even in businesses that are in the same sector doing the same thing. It's like, yeah, but they use some other people management tool and the way that pipes data in just isn't there. So I think you end up a lot of the times with these little bespoke software companies that are trying to do some particular thing, but it's always like, yeah, but it's off the shelf. It's not that great. It's not that big a company. They're serving a very small market because we're in such a bespoke space.
Yeah, trying to play in this space of more general internal tooling that can be configured to solve these problems, I think that that is a very cool notion. And again, I think it's exciting that we're getting into this space where it doesn't always take a developer to go and do a ton of work to get there, but we can use the power that a developer brings to just really fine tune these processes to get them where they need to be. So that's super cool to see. Yeah. So you mentioned a little bit before. I want to talk about some of the new stuff that we brushed over at the beginning of our conversation. I think Retool Mobile was one you mentioned. What's different there versus the traditional offering?

Snir Kodesh:
So I mean, Retool mobile is actually, there's two classes of problems. There's the, I want to take my internal tool, my admin console, my dashboard on the go, and you can do that today. Right? You can build basically a responsive ... you're not going to need to build it. You can get a responsive version of an app with one click, which is again, just a really nice abstraction and a point of leverage. Rather than having somebody go and build some responsive version, you get it for free.
Retool mobile is a little bit different. We're specifically targeting field workers and folks who are mobile first. And so you can think about warehouse employees or bike share operators. Right? These are internal to the company. It's still internal use case, but it's more in the field as opposed to behind a laptop. And so it's compelling on a number of different fronts. And again, if we talk about Retool more generally as a way to get engineering leverage in a way to generate abstractions, one really amazing abstraction with Retool Mobile is you get a native app deployed to all app stores immediately because it is basically served through a white label Retool app that's already available. And so immediately you're already deployed to as many phones as you want across both platforms, iOS and Android, fully natively, React native, but you get a native app.
 The other thing that is particularly compelling is the native first support. So think about things like offline mode or barcode scanning, things that you would need if you are field enabled or field first more accurately. And so you get that in of a first class way with Retool mobile, which is particularly exciting as well. Yeah, I think that the application is nuanced and different, but it requires that mobile first approach as opposed to the responsive web equivalent and it just creates for a more seamless product.

Noel:
Yeah. I guess guys, when you were figuring this out, were there a lot of discussions on if breaking out into a dedicated mobile app was the right way to go versus just trying to juice up the web version to support some of these more mobile first features?

Snir Kodesh:
Yeah, yeah, no doubt. Absolutely. And I think really what broke the runoff there was the fact that we really felt like we did not want to do write twice run anywhere. In other words, you shouldn't have to build a form or a tool in Retool web and Retool mobile just to make it mobile accessible. But we believe that if there is this distinct class of users that is different, a native mobile experience would actually be a better one for them, and the interaction effects are actually pretty cool. Right? You can imagine, for example, a bike repair fleet that is managed by someone in HQ, and now you can have a Retool web app that can send out native notifications to these mobile clients.
 And so that interaction between some large admin console that has omniscient view of all bikes in a city and all operators and all repair folks and you can dispatch jobs and notify people natively and then that flows through Retool mobile. To me, that's a really cool reinforcing narrative there. But really to your question specifically, what made us want to make the dedicated investment is that we felt like this end user group is distinct and the builders that serve that end user group would be building in a different way. They wouldn't be building web apps that weren't responsive, right? They'd be building mobile apps. And that's certainly what we've seen validated in the market as well.

Noel:
Nice. Yeah, that makes a lot of sense to me. I don't know, I feel like this is a somewhat peculiar question maybe, but do you guys envision a future where there are employees who are not Retool employees, but they're so specialized in Retool that that is they are Retool contractors? I'm thinking of how Salesforce transformed the whole sales space and now we have ... because it was in the same space where it's like, oh, you can bring your own, do your own thing. And there's like you can write code and do your own front ends and bring in all these integrations. And I'm not trying to say you guys are doing the same thing, but we wound up in this space where it's because it was highly customizable for a long time, businesses found themselves in places where they needed someone who was an expert in the customizations that had been built for one reason or another. Do you guys think that that is a potential future of Retool?

Snir Kodesh:
Yeah. So I mean what I'll say is I think we view it in so far as it's like a two-way door. I think we don't want to end up in a world where the only people who can use Retool are these specialists that are Retool only. Right? Again, it's an open platform. As we talked about earlier, you can bring JavaScript in and be off to the races and really import prior art directly and have that work easily and seamlessly as well. But that being said, I do think that we do hope that Retool is a ... that there are people who are just more capable of operating Retool because they have that prior experience with Retool and then it becomes an asset, exactly like you said with Salesforce where you hire folks into sales companies that are just really good at customizing Salesforce and that's an asset.
 Obviously. We hope that Retool becomes the way that all internal tools are built, which is really ambitious and we're very far from that, just to be totally clear. But within that framing, if we're successful in that and we hope we, there will be people who really specialize and that's what they spike in. Again, we hope that it's a two-way door in the sense that you don't have to be that person to be successful in Retool.

Noel:
Gotcha. Cool. Cool. Yeah. Yeah, that makes a lot of sense to me. Yeah, real quick, I wanted to do a quick shout. Anybody who's listening, if you're digging the podcast, can you like or subscribe on your platform of choice, share, keep us going, send us a signal as to what you're digging so we can keep bringing cool people on like Snir to talk about what they're building. Anyway, so I want to ask a couple more questions about your guys' journey and then we'll wrap up here about what's coming down the pipe. But how have you grown the team over time at Retool? How do you guys turn that dial effectively to not go too fast, but to continue scaling at a reasonable level?

Snir Kodesh:
Yeah, that's a really good question. I think directionally we know we're doing it well because even in spite of a lot of what's going on in the macro market, we're still going to be growing engineering meaningfully for years to come. I think it begins with the fact that it was a deficit for a while. Again, I recall joining, seeing 13 engineers visualizing how big this product can be, seeing these opportunities that are [inaudible 00:37:51] being like, Oh, we have to scale. So to answer the question directly, we've gone from about 13 to 70 in the last year and a half, so a lot of growth.
And I think that's pretty much the asymptote of growth rate because at the end of the day, if you think about that, just last quarter, I think we had some teams that were literally doubling within the quarter, which is crazy. It means that every person on the team is onboarding somebody new and that doesn't give you a lot of redundancy. And I think you certainly don't want to be in a place where every person on the team is onboarding more than one person. That would be crazy. And so I think having grown incredibly quickly, the team is really productive. We always keep an eye on that and we want to be in a position where ... my heuristic is, you want people to have the opportunity to be over allocated, where there's more work than they can take on is a better place to be than when there's not enough work. When there's not enough work or people are looking around saying the roadmap doesn't feel compelling, or where do I drive impact, that's where you start to see of layoffs and things of that nature, which obviously we do not ever want to do.
So on a go forward basis, I still think we're in this crazy position where you look at a product like mobile, that was built by two engineers. You look at a product like DB Retool database, that was built by one engineer. You look at a product like Workflows, also built by two engineers, and these are massive, massive, massive opportunities. And so it's specifically in those areas that we see a lot of asymmetric growth, but even the core product, right? Up until six months ago, the core product team that was supporting everything we've talked about in terms of component, connectors, layout, the editor, the inspector that we have, debug tools, that cohesive group was nine folks. So I think, historically, we have been very under-resourced. And so turning that dial, again, we don't want to be irresponsible with it. We want to make sure that people have a lot of impactful work that they can do.
The last thing I'll say on this point is what's really neat about Retools, it's an engineer's tool. The best folks to comment about where it can go or what it's missing or what it can do is us, right, is engineers. And so on some level there is a real opportunity to bring more great thinkers who can have that shared vision with us, build that path together. So we're always looking to do that. The last thing I'll say that might be interesting is we have taken a little bit of an anti-pattern approach, and we are in person three days a week and we have three distinct offices, Seattle, San Francisco and New York. But we have found that that has been really positive for us coming back, we started about a month and a half ago. And so all of our growth will be in those three cities in those offices.

Noel:
Nice. Yeah, I think it is the previous point you touched on about working on tooling for potential or for a persona that is you is a huge privilege. It's such a nice place to be. We have that as well with [inaudible 00:41:07] and it's just like, it's so nice to be able to look at a thing and understand what the users are probably going to be doing because you are one of them. That is not a benefit that a lot of devs have.

Snir Kodesh:
And for me, what's cool is actually, it's funny, it cuts both ways. I love Lyft to be clear, I had an amazing time there. My mom has opinions about what the Lyft product should be, right? On some dimension, everybody has a point of view on what Lyft should look like. And I think having an earned secret, if you will, right, which is by nature of being a builder or an engineer developer, you have a point of view on what Retool can be or should be. And that earned secret is really powerful, so I love that connection for our team and for our product.

Noel:
Nice. Awesome. Well, I guess, to wrap up, what are you excited about either at Retool or just in the development space at large in the next year or so?

Snir Kodesh:
 I mean, at Retool, I really think it's this horizontalization. I don't know if that's actually a word, but the expansion into really adjacent products. And to me it represents the entire MVC stack of app development, right? Right now we're very much in the view layer where we've got the V lockdown, but the M and the C were actively working on it. So I'm excited to see that all come together, both for standalone value, but also for these reinforcing and interactive effects between the different products.
 More broadly, I think there's just a lot of cool stuff happening in industry. It goes without saying that a lot of the AI generated stuff is top of mind today, both code, but also images and layout. And I think it's just another example, again, thematically consistent with Retool, where people will end up doing more creative work and people will end up doing less mechanical work or repetitious work who have abstracted the things that are easier to do because those can be taken care of by a machine. And people will be more responsible for the creative parts, for the journey, for how it feels to interact with products for whether it culturally identifies with their organization.
So I think that to me is what that movement in part represents. And I think even though we're not AI generated, I think we have some similarities there. And then obviously there's a ton of really cool stuff happening technically. I'll pick on, I guess, web assembly here. I'm excited to explore that more thoroughly.

Noel:
Yeah. Nice. Nice. Very cool. I guess is there anything in particular you'd point our listeners to, to go check out?

Snir Kodesh:
I mean, selfishly, with Retool? Yeah, you should browse our product catalog, retool.com/product/database, or /mobile at the end or /workflows, just to see what we're up to. I think those are pretty compelling, especially if you're familiar with the core product. But other than that, no, just Google search superficially.

Noel:
Sure. Awesome. Cool. Well yeah, that's all I got. So thank you so much for coming on to chatting with us here. It's been a pleasure.

Snir Kodesh:
Yeah, thank you so much. Yeah, thanks for having me. This was great. I really enjoyed it.