Building ambitious developer tools with Ruben Fiszel from Windmill

Ruben Fiszel 0:00
For me, like the recipe for startups, I think for digital startup, at the very least, is to be really passionate about it like, and I think it's the same in computer science. Once you're passionate about something, a lot of things feel easier. So

Jack Bridger 0:12
hi, everyone, you're listening to scaling dev tools, the show that investigates our dev tools go from zero to one. I'm joined today by Ruben, who is the founder of windmill, and windmill is doing a lot of stuff for debt for developers Reubens laughing already. But Rubin has built an amazing tool already himself. And like bootstraps quite far now has a team of four went through YC raised some money. And windmill is doing kind of three main things. One is kind of a low code code builder of like, dashboards plus kind of workflows that you can write within Winmill, which is almost a bit like code Zapier plus workflows, that kind of similar ish to temporal. And it's all open source. And WiMo. Sorry, Ruben, I've probably like completely butchered their explanation. But is that roughly?

Ruben Fiszel 1:17
Yeah, it is. Thanks, Jack for having me. I think one of the thing is like, I kind of see it as a nanyan. So we basically provide an execution engine or like function as a service that you can completely self host, everything is open source. And so it basically run the script and the script in Python, TypeScript Bourgault. So one of the challenge with that is that we take care of the imports and the dependencies, so you don't like unless like, languages lambda, where you have to like pre packaged things and, and take care of the dependencies. We take care of everything. And we do some advanced caching mechanisms, so you don't have to reinstall the dependencies every time. And on top of that, well, now you have you can execute one function. Well, it'd be nice if you could compose them. This is where we do workflow engine and Zapier for developers or like DOM pro forma mortals is how we would describe it sometimes. But basically, every step is code or like pre made blocks. And then the last layer is building dashboards on top of that, because now you're doing a lot of things. But you want to be able to run them from a table, you want to be able to view them as graph. And you want to build everything that you would do in things like retool, for instance. So we have like the full feature set of retool. And so 111 way of like seeing us I think we're like, we describe ourselves as a cross between retool, and either temporal or Aiden and or Zapier plus the plus lambda AWS lambda where you can like run scripts and the wall several lists back in general. And so if, if that makes sense, it's kind of like the several stack for startups and for enterprise that you can sell first. And we do everything, the workflow, the actual, like, script execution, and the dashboards are all in one.

Jack Bridger 2:55
Yeah, that makes sense. And then if we were to get like kind of a concrete example, let's say I'm building a startup that makes like, generates pictures of dogs with a poem about dogs, and it's all using like, open AI, products. And with, with windmill, I could kind of run the workflows to like,

Ruben Fiszel 3:17
so one of the like, as an engineer, I think the first thing I do when I want to like prototype is to write a few lines of code, run them locally run kind of like prototype stuff, and then enough like you have a big barrier when you actually want to deploy them in prod. So right now one of the solution will be to use one of the serverless stack and then deploy them to the edge to the edge. I think if you're deploying for prod, this is not exactly like our stack is not basically oriented toward that's what we built for is basically all of your internal needs. So basically, you mentioned basically doing like treating request or around open AI. But I think where what you would do is like, do all the processing with one meal, where basically you can do things offline, basically, say, you want to train your data sets every day at noon, or at midnight, and basically build a big corpus and that corpus, you're going to be able to, through prod physically, to vector search, live and and get your result back to your client. So there's a lot of like things where you want to do things offline, you want to schedule them regularly, and their scripts that are not necessarily performance, low latency performance sensitive. If you want to do low latency performance sensitive, this is probably something you should actually deploy with any kind of like the edge serverless framework. We're more where we shine really is, is in places where privacy is really important. Everything everything so first did everything, everything permissioned so basically, you have a lot of ups and that ops team may not everyone should have access to all the resources some should have read access to the database, some should have Right Access database, some should be able to interact with some of the API. So you can encode your, like your secrets and your resources within, within within mil windmill. And you can say with access to it with like view and write permissions. So I think in general, there is a lot of like, external tools and internal tools, external tools are things where what you really, really care about is low latency. In Pro Tools, what you care about is being like compliance, permissions, being able to iterate quickly, being able to kind of like, have a tool that is like the common base for everyone. And so this is where we really shine is, I'll say, compared to a lot of solution where basically, it's either no code, low code. And it's not a good fit for, like developers, because developers, they know how to code and they're like, this is like constraining myself. And building everything from scratch, where you have to well, like do everything in a Git repo, then have the Git repo being set to be deployed into Islam does take care of like, all the auto, like switch to production, you have to make sure that only the right people have access to the right scripts, you have to take care of like, okay, how do I manage my, my permissions? How do I make sure that it is run every day at noon? And like, how do I like compose lambda function between themselves, a lot of things were like, well, in the end, if you want to write things with code, you're going to be like, it's going to take so much time, then you're going to be forced to use a no code, low code solution that doesn't feel as powerful as it should. And so I think the pain, one of the pain we're solving is like, well, if you use a solution like Zapier, at some point, you're going to reach the limits. And you're going to feel like, oh, it's if only I could put the code here, but not code that is like small JavaScript, but actual code that is like Python or TypeScript that can import any dependencies. This is where we really shine where like, those people are frustrated. And they're developers, and they want like a more powerful tool.

Jack Bridger 6:54
Yeah, so that you want like something that just slots into this workflow that otherwise is like kind of, you know, very, like incremental. But you don't want it to just be like a simple little JavaScript snippet that's within one of these builders.

Ruben Fiszel 7:12
Exactly, exactly. And I think the entry point to windmill is is is mostly to you write a script, Python, TypeScript in our web editor. And we basically take care of the dependencies, but also parse your parameters. And from those parameters, we build a UI for you. So let's say you have a script that just takes three arguments in like 10 seconds, you can just pass it into windmill, we make it an app that you can share with anyone in your team. And that apps, you can decide that basically, you want not everyone to have access to it. And like that is pre configured with like your database, for instance, and so on. So there's really the sense of like, well, you can start from like a script that you already have, and get something that you can like use in startup or corporate settings really quickly. So mix of like hacky scripts that be coming to that becomes production scripts, basically.

Jack Bridger 8:07
Yeah, that makes sense. So maybe like a slightly different example might be like, if you wanted to just create like an onboard a customer onboarding video, and you put in a few parameters, and then you could like, the sales team could put it in and spit out like a video and then behind the scenes, all this stuff would be running, and you're just using it internally. But

Ruben Fiszel 8:27
yeah, so what do we do is like we run everything with it. So for instance, we do our DevOps with it, we deploy on Kubernetes. With it, like all of our like, when we take care of the deployment, we do our CRM with it, which means that everyone, every time you sign up to windmill, we're gonna send you a reminder email, if you don't use windmill at all, for the next 48 hours. We can we use open AI to basically search about to your profile to basically give a bit of like, like to not send a blank template and like, get a bit of information about you. So you can do a lot of things with workflows. And, like in general, the first I mean, I'm biased because it's my product. But I started a lot of things by writing a scripting windmill and seeing how far I can go, basically.

Jack Bridger 9:15
Yeah, yeah, that's really cool. So this is like, yeah, definitely one of the most ambitious projects we've seen, like you're, you're kind of building almost like free, very complicated products. And I know that like you've been on like, I was looking at the repo and you've been on an absolute, like storm with your code, like writing so much. How are you thinking about this challenge where it's like the to get to the threshold of like, it's useful. And people really like it when it's so complex, but you also need the feedback from people using it.

Ruben Fiszel 9:57
I think it's really so we build things in state right? is like now you see the three layers with the street, you see the result of like, a year of work a year of very passionate work. But basically, the first three months there were about just being being able to like do the script layer that I talked about, there was no workflow, there were no UI layer. And to be completely honest, until like six months ago, I always thought ritual was are rich in the sense of like, well, the people that really want to use ritual, or like a solution, like ritual, ritual is amazing, there is no way we're going to be able to compete with such a small team. And then you can have like, realize, well, that's what people actually want. And also, ritual is not perfect. They have like they made strong choices around their product. And people complain that it's slow that it's a bit clunky. I think, starting from scratch with this observation and a different mindset, you can actually like, compete with those trigger notes, as long as basically you don't necessarily try to reproduce all of their features, you focus on one aspect in which you think you can really improve on and then you really like kind of like build your, your MVP around that. And so we were building three very ambitious things. But on those three very ambitious things, we don't try to do everything we try to do the thing that we think people care the most about. And one of the I'll say over arching theme that we have is speed, it, we're building a developer tool, it should feel fast. And I think a lot of people, we were placing tools for a lot of people not because necessarily we have all the features that their previous tools that they were a lot faster, because a lot of those tools basically need to execute scripts, they need to execute code. And we focused a lot on the on our basically, system designed to execute all of this code extremely fast, there's little overhead when you when we execute one of your scripts. And so the impression that you get when you use windmill for workflows, when you're for scrapes or windmill for like your dashboards, that everything feels super fast, and it's almost more important than, than everything else, because like as a, as a developer, the one I feel like a lot of the reason why you try to start to rebuild things yourself, because you feel like tools are clunky and slow. And so by not giving this impression, I think we can basically convince people to bypass like to kind of like give us time to build all of the features that they have in their existing tools in in, in comparison by having something that is extremely consistent together filled extremely fast, and is made for developers, so you can run actual code the exactly the way you would what you would do normally.

Jack Bridger 12:32
Yeah, yeah, I think you Yeah, that I think you may well be on something that because I I've been like a huge fan of rutile in the past, but then we went to went back to recently, I had a lot of like, kind of pains around stuff. And like it can be I feel like no code developers get more frustrated with when it doesn't work, especially if it's like, something that's not a mistake that they made. But on the other hand, rutile like, I know what you mean about the speed. But it's also like the kind of speed of how quickly you can get it working like even if it is a bit slow to run. But

Ruben Fiszel 13:11
I mean, for sure. I mean, retool is a company of they have 400 engineers, and they're very smart. I mean, the founders are really smart. They are really smart. It's like, of course, they build a great tool. And it's like, we don't come into market where we think that our competition is our competitors are bad, and it's going to be easy to be able to display them. I think the idea is more like we we've come with a different mindset on some aspects of it. And we think we can apply. We have kind of like the second mover advantage, which is we see what work with retool, we know what people want. And we can focus on like, basically giving, giving that and making it fast and not necessarily. I think retool has basically also the problem of like, having too many customers that are not now used to their current tools. And it would be hard for them to like switch to like something that is oriented around speed, because now they need to kind of like they have a lot of legacy thing that make it work that they need to make it work with their current tools that people are not going to migrate from. So we we took our we take our learning from the best, which are our competitors, and basically try to build something that is like only as the thing that matter most and is extremely efficient.

Jack Bridger 14:29
Yeah, yeah. Amazing. And so if you're going to have going for that speed, like how have you been kind of getting your early users.

Ruben Fiszel 14:38
So I think that for a long time we had not a lot of early users. I think for like the first nine months, we had people that were curious, was the end. To be honest, the product was extremely buggy. So it's like I was like almost like Well, I'm actually like impressed that you you can like like you can use this as your daily driver. I think like three months ago, we started having like a lot of things got better what one has a reason is also because I went from one to a team of four. And my second hire is is, is fatten, which I've known for 10 years. And he's like a great front end engineer, someone who has a keen eye for design. And I'm not bad in design, but you know, it's not something that is as as polished, I kind of like to design like an engineer, right? So it's very crude. And so I think having a product that is actually kind of like, pleasant for the I acted, Chen's things are focused on being able to like get rid of all the bugs also change things. So we went from a product that probably myself I wouldn't use to a product that I would really much want to use. And so in the last three months, we grew a small community of like, very passionate bar users. And for them, it's kind of like Night, night and day, they they use it all the time. And they, they are fun of it, because they don't see any alternative to it. And yeah, they gave us a lot of feedback. They're patient with us, they give us like, good like back reproduction. They give us like good, like, request features and everything. And so we're able to kind of like be refocused on, like, what is the next pain and what is the next pain and then basically build on top of that, we are an exciting phase where we build other features that we deemed important. And we're about to like, make our one point or 2.0 announcement, depending on how you see it, because we basically spent, I'll say, Yeah, nine months basically doing Volk work that felt a bit kind of like, buggy and clunky, and then three months of polishing, and now we feel ready. And I think for this kind of like dev tools, in general, the more mantra of like, building things fast is really hard. Because, like, it's hard to make it with Dev tool in three months, like the and so I'm, I feel very privileged that, why committers as like, interest, I'm also sort of founder and like, this is something that I felt like, I was building a dev tool, that work was way too ambitious for me, and kind of like doing it solo. And and, and I knew it's gonna was going to take months and not going to be able to, like, get MMR after three weeks of yc. So there was a lot of things where, yeah, I think Infratech time, and but on the other hand, in fries, like some, it's a market that is extremely interesting, because you're, you're providing a lot of value. Like once you're in the infra sector, it's like you're, you could run all day. And basically, process a normal startup process, doing enormous amount of operation and companies relied on it critically is something that if they can afford it to go down, so you have to be extremely careful about the code about the guarantees that you give, but it also providing so much value and like solving such interesting things that it's a market for me that is like the domain in which I am really happy to do and I think like, there's a lot of like you see it in the latest batch of YC, or like a lot of companies or you can see them chasing the latest fate. I think that's something which I think makes sense. Because I think there's a lot of like, you can build a lot of great startups on top of the latest fate. But also, you lose sight of the of the kind of like, the core of what makes a good Dev Tools is not necessarily chasing the latest AI innovation. But it is like building in frog building systems for others to use.

Jack Bridger 18:39
Yeah, and there's ultimately got to be like budgets allocated to do this, right?

Ruben Fiszel 18:45
For sure. But, you know, we mentioned this basing your notes in fries, a lot of your notes. So you know, it's like Kafka, but like, you know, it's kind of like all of this, like, being in pressing, they have like, huge corporate backing. And so it's it's also your notes in themselves. So,

Jack Bridger 19:00
yeah, yeah, that's, that's awesome. You mentioned that you're a solo founder, building a def tool. And how, and as we've, I think, made abundantly clear, a difficult one to build. How has it been being a solo founder?

Ruben Fiszel 19:17
So I think it's not like, I'm not, I'm not gonna say it's a choice like that I really, really wanted to be a solo founder and didn't see any alternative. It's more of, I think you need to be passionate for this project, because it's, it takes time it takes it takes all of your energy all of your time. And it's easy to give up early, because, you know, we have great competitors. It's not an easy market. And I couldn't find someone that shared the same passion as me at that time when I started and I was I just went through so it's like the it's not like, I would recommend anyone to go solo founder. I think if you have a great co founder, then then you should go that route. But on the other hand, not having a co founder should not be what stops you. And about the experience, I think it's hard. I wish, you know, I really wish sometimes I could like take a week off or like, take a few days off and know that, you know, everything was not gonna stop stop. On their hand or the end, it's kind of a privilege, because I think in fries, is something you need to have like strong opinions on. And there's a lot of like decisions and things that I can focus in paradise on, without having to necessarily do big alignment session sessions, which can be a problem in a way, like, I don't have anyone to keep me in check. And so I tried to do that exercise of being like, well, you know, am I doing the right thing? Or am I doing the thing that I want? So, but, yeah, it's, it's a bit of a lonely experience. But also, it's really cool to see your projects that you've kind of like, envision from the start to be one thing and see it come to fruition? Almost very close to what you had in mind. And, and so it's, it's, it has a downside and upsides I would say.

Jack Bridger 21:03
Yeah, it's, it's really hard, I think, to find someone that matches that passion, as you mentioned, but the Father you have done so well, like, as a solo founder, I think like, it's, it's so hard, I think. So it shows that you're, I think it says a lot about you that you've, you've been able to do this, which is exciting.

Ruben Fiszel 21:23
I think I for me, like the recipe for startups, I think, for digital startup, at the very least, is to be really passionate about it. Like, if you if you're in need for the money, or you need for like the glory or anything, it's kind of like this something like it gets, this is not enough, right? You need to want to really build a product. And I'm lucky enough that this is something that I really want to do. And, and so it's like I like I'm happy to take credit for like, yeah, I work a lot or anything. But I think the more like, and I think it's the same in computer science, once you're passionate about something, a lot of things feel easier. So yeah,

Jack Bridger 22:00
that's, I think that's the soundbite for this episode, I love it. Yeah. And just digging in on that, like, Do you have any advice for founders that are also building something that's like, ambitious.

Ruben Fiszel 22:19
While they there's do's and don'ts. I think for us, the don't was to kind of like saying we're going to do, like, we're going to do everything perfectly. And we're going to do it in stealth. And, you know, it's like when we're going to do a big release, everything's going to work, we will not have been able to do that, because our product takes time is going to take more time. And even if we had been in sales and like really focused on one thing, it wouldn't have been as good as with the feedback we receive. So I think kind of like a hack. Open source is kind of a growth hack, in a way. And a lot of people have reluctant reluctance around open source, because they're like, Well, what if people someone copy my code, what if you know, like, people don't pay? I think for dev tools in general, that's something you shouldn't be worried about. Because as AI works, people love it, and then you know, large enterprise use it and you're gonna get paid, or it doesn't. And then basically, you've just wasted the most precious thing that you have, which is your time. And so I would really, really, strongly recommend to kind of like, really consider open source, if you're building dev tools and infra I think that don't for me, it's kind of like, don't try to do everything yourself, which I've not applied very well, right. But try to surround yourself with like, like people that you trust, I think there's a tendency to have like, finding contractor like trying to delegate, but with like lots of people, but people you don't necessarily kind of like trust or like contractors. And it never works. Because you're spending more time managing people and managing those people like thinking aligning with them. And so you can go so much faster with like, four people that are highly passionate about one thing and have high caliber than with like a team of 20 where everyone is there because you know, you got funding and you get paid and you looks cool, but you know, so I think there's a bit of like trying to take time to build your core team. And if you have to stay small, that's fine. You can income like with the right kind of people, you can go extremely fast.

Jack Bridger 24:24
So yeah, what is the makeup of your team? Actually,

Ruben Fiszel 24:28
there is a two fold engineer me and someone which is, as I'll say, semi engineer, he learned coding with us. And he's doing a lot of like the like growth hacking blog posts, documentation, doing QA about the product, doing a lot of like, things where as engineers we sometimes don't have time to do.

Jack Bridger 24:50
Yeah, this, those those people that are great, do everything, everything, and anything that comes their way,

Ruben Fiszel 24:58
which is also how I describe my role. I do everything that no one wants to do. So it's like, there's also like this, which is, I think what? Everyone, every founder does that. But I think, you know, you have like this user casual bucket for every task. And it's not a, it's, that's why I think you have to love what you're doing. Because most tasks 95% of the time, they're not solving distributed systems question that are extremely intricate, intricate, interesting. They're like, doing a lot of like, like, it's mostly expensive. Yes. So it's like, yeah, well, you get a you get to see the the the end goal, and everything is easy.

Jack Bridger 25:38
Yeah, 100% Riven, thus, that's amazing. It's been so great speaking. One final thing, what would be the biggest takeaway that you kind of, if anyone listening what they should take away from this call?

Ruben Fiszel 25:52
I think there's opportunity to make really interesting startups. Like, the like, there are like startup, they're gonna chase like, like small, incremental improvements, and they're gonna succeed, but they're still like oriented to dream big for developer tools. I think we have seen like SpaceX, and then like, all of those, like companies in other industries, kind of like achieve the impossible. I think we can still do it for dev tools. And you got to try. And we're, I mean, one of the reasons I start I was able to, like, take this risk is because I feel like we're really privileged as software engineers, we were not so worried about kind of like financial security or like less worried we. So we can take a bit more risks. And I think we get a bit comfortable in our situations. But there's still opportunity to make amazing dev tools. So I would encourage everyone to like kind of like, do a leap of faith and take a year or two try it and you know, that doesn't work out. Everything is gonna be fine.

Jack Bridger 26:54
Amazing. Reuben, thanks so much for joining. Where can people learn more about windmill and about yourself?

Ruben Fiszel 27:02
We have a website Vimeo dot Dev, we have a open source repo, which is like windmill labs slash windmill on GitHub. We really commit to open source so everything is open source. And yeah, we have a discord I think this is we respond immediately to discord and I mean, we it's mostly me because I'm either coding or like, but I always like have a tab on Discord. You can reach to me extremely easily by just joining our Discord.

Jack Bridger 27:26
Amazing. Thanks so much for joining Reuben and thanks, everyone for listening. See you again soon.

Ruben Fiszel 27:31
Thank you. Thanks a lot.