xyflow

This episode features Moritz Klack and Christopher Möller, Co-Founders of xyflow. They look back on their career journey leading to their current company, from developing webkid, creating Datablocks, and launching React Flow. They discuss their transition from agency work to open source, their pricing strategies, and the importance of community feedback. Moritz and Christopher also bare their plans for the future and what trends in the digital space they are most excited about.

---

Welcome back, everybody. I'm talking to two guys from Germany, Christopher and Moritz, from both webkid and xyflow. Christopher, Moritz, welcome to the podcast.

Thank you so much for having us.

No problem. I've got a small confession to make. My father's German, and I was brought up reading Max and Moritz cartoons, which you guys might know of. Moritz, you're the first actual Moritz that I've met who's a human being and not a cartoon character.

That's basically us, Max and Moritz.

Career Journey

For those of you that don't know, it can be, at times, a fairly dark children's cartoon where invariably these two children, who are always badly behaved, end up being turned into bird food or something. Great to have you on board. You're here to talk primarily about xyflow, but you guys started with an interactive agency, webkid. Do you want to just give us a brief overview of xyflow and webkid for those who don’t know?

It started around ten years ago. We just had our ten-year anniversary party.

That was fun.

When Moritz and I met in university, we studied computer science. We met there, and we, as a student job, worked at the same newspaper as front-end developers. When we finished with university, we were like, what to do now? We had all these contacts already with these journalists who were doing these interactive pieces, data journalism stuff. You can imagine they have articles about a subject in Berlin, maybe it's about increasing rent prices. We would do an interactive map to support the online article, where you can search for your location and see how exactly the rent prices developed in your specific area.

It was a very interesting time because all those interactives had just got started.

I was about to say the timing is really good because that's when there was this explosion of people and media companies investing quite a lot of money in this stuff, because it's not cheap.

That's true. The New York Times showed up with these super crazy interactives. We got interested in that too.

In Germany, it was a handful of people who then started to do these kinds of things. We were connected with some of them already by accident. We decided, after our studies, let's start a small agency to help these journalists do these interactive pieces. It went really well because we already had these contacts, and we could easily start this agency business. It didn't really grow much over time. We had more clients, but it was always the two of us who coded the stuff. You couldn't really scale it. At times we had three employees, but that's it. That was only for 2 or 3 years where we had this.

It also was very intense for us to be in this situation of, we only need to get the project, and then someone else will execute it. Whereas we wanted to build these things because we were really passionate about it. When we had these employees, we were like, we are not working on this anymore. We are content developers, but for project managers. We really scaled back again to the two of us. Over the time, this was eight years or so that we did it, or seven years, we got really tired of this agency business.

Because agency work is always hard. You need to talk to so many different people who speak different languages, with different knowledge. It's a tough business.

Agency work is always hard. You need to talk to so many different people who speak different languages and have different knowledges.

Especially in journalism, you have always had these short-term projects, which were like 2 to 3 weeks with a deadline, not much budget for the project because journalism is super underfunded, at least in Germany. I think it's the case in many countries. Always working closely with teams who have very different technologies and then integrating it into their 30-year-old CMS. It was interesting because we got so many projects out there and also connected to this journalism sector, not only with tech people but also with very good journalists. It was interesting, but then we got really tired of it.

I remember, actually, that because I've been running an agency for almost 20 years, maybe 18 years, before we started Flagsmith. It's a tough grind. I remember we won a project to put the Amnesty International annual report online and then internationalize and translate it and all this sort of stuff. When you've got a deadline like that, that is completely and utterly immovable, it's a pretty terrifying experience. I remember, actually, we had a vector map of some of the borders in the Middle East, the sensitive ones, they were seven years old or something.

We just never considered that. I remember when Amnesty saw it, they absolutely freaked out. They're like, if we publish this, it's a complete and utter disaster. We realized the sensitivity and importance of some of the stuff that we were working on. It was pretty terrifying. After that job, we were like, maybe we should back away from the media industry because it's just too stressful.

It's interesting because we also were, most of the time, especially in the beginning, like the only developers in these teams. You have a very different responsibility also as a developer that you might not know from other jobs, where you're like, it's my responsibility that this data that we are presenting, which is a journalistic piece, is right. Also, the journalists were making conclusions from the data that we had gathered or transformed. You have a responsibility. You are the only person that understands the code behind it because there are no developers in the newsroom. I can really relate to what you said there.

I think we had a similar issue with Polish city names that used the old German names or something like that. Complaining about that, like, those are not the names that we use right now.

Tooling On The Front End

Back then, ten years ago, especially, the front-end tooling for this sort of stuff was much more primitive.

The tooling was fun. It was before React, it was all jQuery. Spaghetti code, wild stuff. I think we used Google Maps for our first huge interactive map, and it was all a mess. Formas, GeoJSON, TupleJSON didn't really exist, or at least we didn't know about them. But it got way better over time. The first years were pretty rough. We couldn't reuse anything, and there were no real standards that we used.

One of the things is, it's more important that the project gets out than maintaining your technology stack. We never really had a component library or much reusable stuff. In the end, there were starter kits and something, but still, everything got developed from scratch because there's no time or budget for, "We want to develop our component library for 1 or 2 months so that we are faster in these next projects," because the projects are not planned like this.

Getting your open-source project out is more important than maintaining your technology stack.

It wasn't sustainable at all. I think after 3 or 4 years, we had something like a starter kit, super basic stuff, but it got way better now. Today, it looks very different. If you look at those interactive teams, they have public repositories with UI component libraries and all that stuff.

xyflow

I remember 20 years ago, just drawing a bar chart in a web application was pretty tricky. The final result always looked really terrible. It had no panache about it at all. Some backend software engineer had done the visual design for it. How did this manifest into the creation of xyflow?

I think maybe after 5 or 6 years, we already had the idea that we wanted to have another source of income or revenue, so we weren't 100% dependent on this journalism work and agency work.

We also wanted to have one thing we could work on. I think it was very different from publishing 150 projects, like one project we could improve over time and work on.

We started to get these ideas, but we were really focused on the journalism sector and what we did there. We always looked into this niche and said, “How can we help journalists to make better use of their data or to make it easier to transform datasets?” The idea came from, okay, we had these 200 projects. I don't know, all very small-sized projects where we always had a node script to transform some data. From that, we thought, what if we could build a UI for that? We had the idea to have it in a node-based editor so that you have building blocks.

For something like chasing data in a filter, merging it with another CSV file, and spitting out 10 JSON files that we could use in our web application.

Through this node-based interface, we wanted you to have branches for having multiple paths for your dataset, like Yahoo Pipes in a more modern version. We started to build a prototype, and I don't know if it was by accident, but we had this separation between, we have this editor, but we need a library for rendering this flowchart, and we were using React. We didn't really find something that suited our needs.

We couldn't find something that was flexible enough, I think, because we wanted to render charts with inputs and complex stuff inside the nodes. It wasn't possible with the libraries that we found back then. We split up the work, two people worked on the editor front end, and 1 or 2 people worked on the library itself. That's when we started a library called React Flow Renderer back then. It had no website or anything. There was just this GitHub repository, and we used it and published one major version after another, which is super weird. If I look at it, that's why we are at twelve already. However, we had no plans to make it big or so that other people could use it. It was just for us.

‍

Because at the time, we thought that Data Blocks, like this editor, is our product, and that's what we want to market or build up as our second revenue stream. I don't know how long we worked on Data Blocks, it was maybe one year or so.

Was that project open source as well?

No. It's not.

The website is still out there.

From that, then maybe 1 or 1.5 years later, we were like, this library is getting a lot of attention. We were getting lots and lots, and we just put a very simple documentation based mainly for us.

It was just the README, right?

Yeah, exactly.

After 1.5 or 2 years, we published a website for it. I think after we published the website, it really got more and more traction.

You weren't going out and specifically marketing it. I don't know, appearing on podcasts or trying to get onto Hacker News or anything like that. It just happened organically.

Not at all. We posted it to Hacker News at some point. Until today, basically, we don't do any marketing or specific advertising.

This is the first podcast we are on. One of our employees, John, was on two podcasts already.

But that was more about open-source funding, I think.

Anyway, we didn't realize that this library had this much value until we got some emails, also from bigger companies, who were like, “Can we get development services from you? We are building something with your library.” There was, I would call it, a transition phase because we had this agency running. For one year or so, we still did the agency work, but for React Flow projects then.

Another agency was born.

After a year of working as an agency again but with React Flow projects, we said, we are back at the beginning. We are an agency again. We just want to work on the library. What can we do about it? That's when we started to put a price tag on the pro platform that we also launched.

Library Project

Can you talk a little bit about the library specifically rather than an end-to-end project or platform? It has always felt interesting, and I think even this is before open source was a big deal. I remember back starting my career, there’d be desktop UI components and stuff. It has always been a strange way of buying those things or packaging them and selling them. Were there any projects, specifically library or toolkit projects, that had influenced you on what a potential path was to try and make it a sustainable project and idea financially?

Yeah, so the library itself is MIT licensed until today, and we will keep it like that. It was kind of, okay, we have this free open-source library. What can we do about it so that we are enabled to work only on it? Because it really benefits the users, we care about it, and we ship updates and stuff. We thought about it, and we had the first idea for this pro subscription. We have used Leaflet and Mapbox. Leaflet is a mapping library, like Google Maps, but a bit more open source and stuff. It’s a really nice project, and we have used it intensively in many projects. It had this little attribution in this little label at the bottom.

We thought we could take this as an inspiration and put a React Flow label into our renderer. Only in the source code, when you inspect it, we have a little HTML description that says, “Please consider subscribing if you want to remove this attribution.” That was an inspiration for us, basically. Leaflet, they don’t do it like this that you donate, but having this little logo. Because when you install it and you see the editor for the first time, then you see this little badge, and you instantly, as a developer, right-click on it and say, “How can I remove this thing?” I think that is one of our main marketing channels, if you want to call it that, making people consider supporting the project.

I remember some people were super annoyed. I think we introduced this in version 10. However, some people were like, “You are going fully commercial,” but we were like, “It’s still MIT. You can do whatever you want.”

It’s crazy. If you wanted to, you could fork it, probably, and then just trivially remove it. That’s sometimes a bit of a depressing aspect. It’s like, so you want bug fixes, feature updates, and browser upgrades forever, but you’re not happy with some little thing at the bottom of the screen? If you don’t want those, just go and fork it. I don’t know. Maybe I’m too old. At that point, I don’t have much time for people like that. I say, “You can go and copy the whole thing and just delete that thing, and good luck.” That’s depressing. Did you guys have any arguments about what level of opacity to make that text at the bottom of the screen? Because that’s a deal as well. You don’t want it flashing red, but at the same time, you want people to be aware that it’s there.

I think that’s really up to the users. Legally, they can just remove it without paying anything because it’s not licensed. We don’t have any guidelines about it. It’s just something. That, I think, is really interesting about it because we were surprised that it worked. The first version of our pricing was only about this attribution thing and very heavily priced, I don’t know, $700 a month or something. That was our first initial release of the pricing. I get that people were a bit upset about it or had strong opinions on that. That’s also a good thing for us because we were seeing that people really care about what happens with this library.

‍

That also was a good sign, and that led us to realize we needed to adjust our pricing and offer some more things. We just learned from these initial ideas and this initial feedback. That’s when we introduced two different pricing plans. One is with support from us, and you also get more advanced examples. We call them pro examples, which are usage examples of React Flow where you can only copy the source code when you are subscribed, a goodie kind of thing. We were really surprised at how that then went.

Pricing

In terms of the pricing, that’s really interesting. It must be very hard to price a software component like this. There’s probably a hundred times range of what you could theoretically charge for it. How did you come up with that initial number?

Good question. There are some commercial competitors out there, proprietary competitors, let’s say, and we looked at those packages as an inspiration. It’s a different thing because they sell licenses. We took it at least as an inspiration. We talked to a lot of people. We also thought about, what would we pay for something like that, or what’s a reasonable price? Still, we don’t know, is this too low, too high? Is this good? We don’t get a lot of feedback about our price, so I think, for now, it’s fine.

It’s interesting as well, because also the nature of the tool, it could be a serious part of a large company’s user interface and tooling. It could be very valuable to them.

That’s something we were also wondering, like, why aren’t others doing it like this? Because we also tried things like GitHub sponsorships and stuff, and it never really worked out. It only worked until we put a concrete price tag on it and said, this is how you really can support us. We expect companies to do this when they are making money with our project. I think it’s also very beneficial for us that the library itself is often used as user-facing, and you use it for editors and stuff. That’s something that users really interact with and see. Our assumption is that it’s more important for companies that this gets maintained than a helper library that they use under the hood for state management or something like that.

That’s definitely true, but still about the pricing, back to your question, I think that’s something we could work on. It feels a bit unfair that a huge company with thousands of employees pays the same as a company with five employees. That’s something on our list. We introduced this new, how is it now called? Is it a custom plan?

Yeah. Enterprise plan.

I think we can do a better job on this still.

The other interesting thing that’s tricky about a component library or a UI tool is that there’s a number of really challenging things. One is, it’s very hard for you to get any idea about usage volumes for any of your customers. the second thing is, it must be quite challenging when we’re building a feature in Flagsmith. One of the first things we’ll think about is, will this be in the open-source project, or will this be in the enterprise only, or whatever? Sometimes, maybe 30% or 40% of the time, the thing that we’re working on just structurally has to go into the open-source projects. It would be a crazy amount of work.

Maybe an addition to one of the SDKs or to the SDKs. It would be like, we've never wanted to have the pro versions of the SDKs. That would just be really painful. The user experience to onboard customers would be horrible. Some of the stuff has to go open source. A lot of the time, maybe 70% of the time, it's like, where do we want to put it? Do we want to put it in the open-source project, or do we want to put it in the enterprise version? We've got a little philosophy, I think it's public somewhere. I'll try and add it to the show notes, of how we try and figure out what to go where. Generally, the stuff that we're working on falls into one of those fairly obvious categories, and it's not that contentious.

A part of the process when we're working on features is that we don't really get into big arguments, three people saying, “It should be enterprise,” and then three saying, “It should be open source.” I guess it's hard for you guys to have that because I would expect that the vast majority of the stuff you're working on has no real way that you could segment that stuff, right?

Yeah, exactly. That's true. We can say, “We want to build a new pro example,” then it's for the subscribers. But if we want to improve the platform somehow, everything else is open source.

Commercial Aspects

The other thing that I noticed about your pricing, not just the pricing but the commercial aspects of the project altogether, is that it really does lean into, “You're supporting us, and you're supporting the library.” It's interesting because normally when that happens, it's like, I don't know, it's purely done on GitHub. It's probably very much more what I would expect, much less effective. Rather than setting up a product, a website, and a platform and stuff, it does lean into, “You guys are using this, you need to support the platform.”

How much of you leaning into this, like you're supporting the project and you're supporting its development, was just out of necessity rather than like, this is the direction we want to take it.

I think it was always a mix of both things. We wanted to give something back, but also, we wanted to communicate. Most of the time, what gives you the most benefit is that when we maintain and develop the library. I think that's the tricky part of this pricing thing because you are paying for something that everyone else benefits from. That's different from other pricing models, like software-as-a-service models, where you're like, “I pay for this, so I get access.” For us, it's, “I pay, I get something. Maybe you're interested in support, but then the main thing you pay for is what benefits everyone else, too.” I think that's really the tricky part.

Also, the first employee that we hired, then we needed someone to communicate these things. That's still something we are working on, how to communicate what we are doing and what you're really paying for and stuff. I think it's really difficult because it's not that common.

Creating open-source libraries is difficult because it’s not that common.

I would say it's challenging, but for us, it was very clear from the beginning that we wanted to have the library open source because we’ve worked as developers for more than ten years, and we never used a proprietary library. It just feels weird. I want to install stuff via NPM, and then I want to check out the source on GitHub or GitLab or whatever. That's how we use software. We could do pro plugins, for example, or stuff like that, but we don't have those because we wanted it to be the open-source way.

You've got some absolutely top-tier logos. How did you go about getting some of these companies, like Zapier and Stripe, as customers? Did they just come to you having found the library?

Yeah. I think as a developer, wherever you search for new stuff, GitHub trending, Hacker News, you see something in a blog post, whatever. You know how to look for a React library for flowcharts or node-based editors or whatever. There, you have some options, and those companies decided to use React Flow. They used React Flow before we had pricing, and they still use it for the documentation.

Generally, that class of customer that you have, I would imagine they've been good customers to have in terms of being happy to pay for the pro plan and provide feedback and things like that.

I think for the big companies, it's easier to get an okay from the product manager or whatever. Like, “We need this $130 or $250 a month,” and then it's like, “Yeah, okay, whatever.” It's nothing compared to other software things they need to pay for.

At what point did you include a second framework, like Svelte, to build this out? That must've been a fairly big decision.

It's a huge bet, I would say. We want to be sustainable, and we want to be sustainable in five years. We thought it was a good idea to diversify a bit but stay with the core product. It's still a node-based thing, it's just for a different library that's on the rise, I would say. There's another colleague who's doing Vue Flow. It's not sure yet if we want to take it under the xyflow umbrella, but it could happen. I think with those three frameworks, we are good to go.

The big advantage of it was a huge effort to build this version for Svelte. The big advantage of it was that we could really structure it in a different way. We have a core package that handles the underlying things that are shared between the two libraries, and then we have packages for React and Svelte built on top of that. It really benefits to build it for Svelte also, really benefit the React library.

‍

I think so too. Sometimes we do some updates, and then this update is for both libraries. It feels super nice because we only have to change one thing.

Plans For The Future

Nice. In terms of the future for the projects and the business, what have you got planned for the future?

That's a good question. Currently, we want to focus on our current business. We might do Svelte Flow Pro, but that's also not sure yet because numbers are still quite small. There's no need for it now, I would say. There's also Svelte 5 coming up and all that stuff, and we need to work on that. On the business side, we have some ideas about how we could extend the ecosystem for React Flow and Svelte Flow, and that's definitely something we want to do. We want to make it easier for you to build node-based editors, and we can give you a lot more than this low-level library. For example, workflow editor starters, themes, components that you could reuse, there are lots of ideas floating around already.

How hard is it to maintain support parity with React and Svelte when they're making big changes?

Good question. For Svelte, it's very hard because they released a new major version, and everything is new, but that's the Svelte way, I would say. With React, it's way easier. It's always backward compatible, and they don't introduce huge changes.

Their API generally is fairly settled, right?

Yeah, I would say so too, but then there's something like React server components, for example, or server-side rendering/server-side generation, which is, of course, interesting for us. We try to be up to date with that. We released a new major version of React Flow, and it's possible to render flows on the server.

In terms of the browser support that you have to manage, how consistent are those engines now?

That's a good question. I would say we don't care too much about browser support. We always say we support whatever React supports. It's basically up to you. You can always add polyfills and stuff and get it to work in Internet Explorer 11 or something like that. I think it got way better over the last 2, 3, 4 years with all those different browsers and browser support. It's not a huge topic for us, I would say.

Episode Wrap-up

Interesting. That's great to hear. Just as we wrap up, are there any contributors or URLs or folk that you want to mention, or how can people find out more about the projects and contribute? If you've got a chat community, anything like that?

Yeah, sure thing. The most important channel currently is Discord, I would say. We have a huge Discord server with a few thousand members, and it's good for getting quick support or asking questions. Also, the community starts to answer more and more questions, which is great because we can't answer everything on Discord. Then, of course, there's GitHub, which is also used a lot for issue tracking and discussing new features and all that stuff. Besides that, do you have any things you want to mention?

No, I'm just super thankful for our community, and it's super inspiring also to see our library being used in such a variety of projects. It's really great how much people care about the library itself. What I mentioned in the beginning, like what we noticed when we put a price tag on it, and people were upset, that's nice to see. You build something that has value for other people and makes their lives easier. That's really nice. I really enjoy working with this community and working with our pro subscribers, and thank you.

Cool. Thanks for your time. It's been really interesting, and it's interesting as well talking to a sustainable business and projects that are coming at it from pretty unusual angles. It's great to hear that it's working for you. Wish you all the luck for the future.

Thank you so much, Ben.