Building ambitious developer tools with Ruben Fiszel from Windmill
Ruben Fiszel spent nine months building Windmill as a solo founder before it had a workflow layer or a UI layer — a product he admits even he wouldn't have wanted to use daily. He thought Retool was permanently out of reach for a small team, until he realized speed, not feature parity, was the actual opening.
Ruben Fiszel is the founder of Windmill, an open-source platform for turning scripts into workflows, UIs, and internal tools — self-hosted, and combining what he describes as a mix of Retool, Temporal, and Zapier plus AWS Lambda.
We get into why he thinks speed, not features, is what will let a small team compete with a 400-engineer competitor like Retool, why the first nine months of the product were genuinely too buggy to use, and what it's actually like being a solo founder on something this ambitious.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
What is Windmill, in your own words?
I think of it as an onion. At the core, we provide an execution engine, function-as-a-service, that you can fully self-host — everything's open source, and you can run any script in Python, TypeScript, or Go. Unlike Lambda, where you have to prepackage dependencies yourself, we handle imports and dependencies for you, with advanced caching so you're not reinstalling them every time. On top of single functions, we built a workflow engine — Zapier for developers, or Temporal for mere mortals, is how I sometimes describe it — where every step is either code or a pre-made block. The outer layer is dashboards on top of all that, so you can run things from a table or a graph, the way you would in Retool. We describe ourselves as a cross between Retool and Temporal or Zapier plus Lambda — the whole serverless stack for startups and enterprises, self-hostable, covering workflows, script execution, and dashboards all in one place.
Where does Windmill actually fit best — what kind of problem is it solving that a pure serverless edge deploy wouldn't?
As an engineer, the first thing I do when prototyping is write a few lines of code and run them locally — the real barrier comes when you want to deploy to production. If you need low-latency, performance-sensitive production traffic, an edge serverless framework is probably the right tool, and that's not really what we're built for. What we shine at is internal needs — things you want to run offline or on a schedule, like training a dataset every night at midnight to build a corpus you then query live in production. Where we really shine is when privacy and permissions matter: self-hosting everything, encoding secrets and resources with granular view/write permissions per team member. External tools care most about low latency; internal tools care about compliance, permissions, and being able to iterate quickly on a shared base everyone uses.
What's the actual gap between existing no-code tools and what developers want?
A lot of existing solutions are either no-code or low-code, and developers who actually know how to code find that constraining — but building everything from scratch means wiring up a git repo, deployment to Lambda, permissions, scheduling, and composing functions together yourself, which takes forever. So developers get pushed toward something like Zapier, and eventually hit a wall where they think, if only I could put real code here — not a small JavaScript snippet inside a builder, but actual Python or TypeScript with real dependencies. That frustration, from developers who want a genuinely powerful tool rather than a toy scripting box, is exactly where we fit.
How does someone actually get started with Windmill day to day?
The entry point is usually just writing a script in Python or TypeScript in our web editor — we handle the dependencies and parse your function's parameters to automatically build a UI around them. If your script takes three arguments, we turn it into an app you can share with your team in about ten seconds, pre-configured with things like your database connection, and permissioned so not everyone has access. It's a mix of hacky scripts becoming production tools very quickly. We use it internally for almost everything ourselves — our DevOps, our Kubernetes deploys, even our CRM. If someone signs up and doesn't touch Windmill for 48 hours, a workflow uses OpenAI to research their profile so the reminder email isn't a blank template.
You're building three ambitious products at once — script execution, workflows, and dashboards. How do you balance ambition against needing real user feedback?
We built this in stages. What people see now is a year of very passionate work, but the first three months were just the script execution layer — no workflow engine, no UI layer at all. Until about six months ago, I genuinely thought Retool was out of reach — how could a tiny team compete with them? Then I realized Retool made strong product choices of their own, and people do complain it's slow and a bit clunky. Starting from scratch with a different mindset, you can compete with an incumbent as long as you don't try to reproduce every one of their features — you focus on the one dimension you think you can meaningfully improve and build your MVP around that. Our overarching focus across all three products is speed. We put a lot of effort into system design so script execution has almost no overhead, because I think a lot of the reason developers start rebuilding tools themselves is that existing tools feel clunky and slow. If Windmill consistently feels fast, that buys us the time to build out feature parity on everything else.
Retool has hundreds of engineers and a lot of resources. How do you think about competing with something like that?
Retool has around 400 engineers, and their founders and team are genuinely smart — we're not coming into this thinking our competitors are bad or that displacing them will be easy. The idea is more that we have a second-mover advantage: we can see what already works for people using Retool and focus specifically on delivering that, fast. Retool also has a real constraint we don't — a large existing customer base built on their current architecture, which makes it much harder for them to pivot hard toward speed without breaking things people already depend on. We get to learn from the best in the category and build something narrowly focused on the thing that matters most, done extremely efficiently.
What did the early days of getting users actually look like?
For a long time we didn't have many — for the first nine months it was mostly curious onlookers, and honestly the product was extremely buggy; I was almost surprised anyone was using it as a daily driver at all. About three months ago things got noticeably better, partly because I went from being a solo founder to a team of four, and my second hire, someone I've known for ten years with a real eye for design, changed how the product actually looked and felt — I design like an engineer, which is to say, crudely. Fixing bugs and improving the visual polish together changed things — we went from a product I personally wouldn't have wanted to use to one I genuinely want to use. In the last three months we've grown a small community of very passionate power users who see no real alternative to it, give us excellent bug reports and feature requests, and are patient with us while we build.
Is there a tension between building fast in dev tools and actually shipping something good?
It's genuinely hard to build a good dev tool in three months, and the usual startup mantra of moving fast doesn't map cleanly onto infrastructure. I feel privileged that YC trusted a solo founder building something this ambitious, knowing I wasn't going to have meaningful revenue three weeks into the batch. Infra takes time, but it's an incredibly interesting market because you're providing enormous value once you're embedded — your code runs constantly, processes huge amounts of data, and companies critically depend on it staying up. You see a lot of recent YC batches chasing the latest trend, which makes sense as a strategy, but it can mean losing sight of what actually makes a good dev tool — which isn't chasing the newest AI wave, it's building solid infrastructure and systems other people build on.
What's it actually been like being a solo founder on something this ambitious?
It wasn't really a deliberate choice to go solo — I didn't see another path at the time, and I couldn't find a co-founder who shared the same intensity of passion for this specific project when I started. I wouldn't necessarily recommend it; if you find a great co-founder, take that route. But not having one shouldn't be what stops you either. It's genuinely hard — I wish I could take a few days off sometimes without worrying everything grinds to a halt. There's an upside too: infrastructure requires strong, decisive opinions, and I can prioritize without needing big alignment sessions, though that also means nobody's there to keep me in check, so I have to regularly ask myself honestly whether I'm doing the right thing or just the thing I want to do. It's a bit lonely, but genuinely rewarding to see something you envisioned from scratch come out close to what you originally imagined.
What do you think the actual 'recipe' is for a dev tool startup like this?
You have to be genuinely passionate about it. If you're doing it for the money, or the glory, or anything external, it's not enough to carry you through — you need to actually want to build the thing. I'm lucky that's true for me, and once you're genuinely passionate about something, in computer science especially, a lot of things that would otherwise feel impossibly hard start to feel easier.
What advice would you give another founder trying to build something similarly ambitious?
One thing I'd avoid is trying to build everything perfectly in stealth before any release — we couldn't have pulled that off, and even a laser-focused stealth effort wouldn't have been nearly as good as what we got from real user feedback along the way. Open source is almost a growth hack in itself for dev tools — a lot of founders worry someone will copy their code or nobody will pay, but if it works and people love it, enterprises will pay you for it; if it doesn't work, all you've lost is time, which you'd have lost anyway. I'd strongly encourage strict consideration of open source for anyone building dev tools or infra. The other lesson, which I haven't always followed well myself, is don't try to do everything yourself — surround yourself with people you genuinely trust rather than contractors you're constantly managing and syncing with. Four highly passionate, high-caliber people can move dramatically faster than a team of twenty who are there mostly because there's funding and it looks good on a resume.
What does your team actually look like day to day?
There are two front-end engineers, myself, and someone I'd describe as a semi-engineer — he learned to code with us and now handles a lot of the growth hacking, blog posts, documentation, and QA that engineers often don't have time for. My own role is basically doing everything nobody else wants to do, which I think is true of most founders — most of the day-to-day tasks aren't solving intricate distributed systems problems, they're a lot of small, unglamorous things. You have to genuinely love the work, because most of it isn't the exciting part, and keeping the end goal in view is what makes the rest tolerable.
What's the one thing you'd want a listener to take away from this?
There's still real opportunity to build genuinely ambitious startups in dev tools, not just chase small incremental improvements. We've seen companies like SpaceX achieve the seemingly impossible in other industries, and I think that's still possible for developer tools too — but you have to actually try. Part of why I was able to take this risk is that as software engineers, we're relatively insulated from financial insecurity compared to a lot of other paths, which means we can afford to take bigger swings, even if we tend to get comfortable instead. I'd encourage anyone considering it to take a genuine leap of faith for a year or two — if it doesn't work out, you'll be fine.