From Pandemic Pastime to Real VC-Funded Startup

David Kid, welcome to the work item. So great chatting with you. I've been following your adventures around Stately and XState for a while, so it's good to actually, you know, talk, talk to you and learn more about it. Yeah, glad to be here. Why don't we start with your main project, which is, well, Stately, AI and XState? Like, tell our listeners what? What is it all about? Well, it started, honestly, this whole thing started at the beginning of my career, when I was a junior developer, I was working, of course, junior developer jobs. And I just found the normal way of doing. App logic, you know, just writing code and if statements all over the place and trying to understand what other developers are trying to, portray I. I just found that so confusing, and so I just sought to find a different medium of expressing complex app logic. And so I did a bit of research. I ran into, of course, flowcharts, and then from there state machines and state diagrams, and then from that to statechart.

And I just remember that really, really clicking for me. Just this whole idea of visualizing your application logic, and so, I, you know, I started thinking about that idea a lot, applying those principles to other jobs that I had, and eventually made an open source project called XState. And so I started that about eight years ago, seven or eight years ago, yeah, and honestly, it was just a project to scratch and itch. It was something that I was, doing for fun, just to see. Can you write application logic in a way that it could be visualized as a state machine? Just because I thought that was a really interesting problem space. And, as it turns out, this library ended up being useful for a variety of uses, both in the front end and back end. And it grew to, I think, over 25,000. GitHub stars now over 1.5 million weekly MPM downloads.

So needless to say, a lot of companies actually found this useful. And so, three years ago, during the of the pandemic. I, I was at Microsoft, and I enjoyed my job at Microsoft very much. But also just being stuck at home, being remote, I just. Wanted to do something a little bit more exciting, and so I had the opportunity to actually start a startup around that, just because I really wanted to see. These tools come to their logical conclusion, which is, having tools that allowed you to either modify the diagram and you generate the code, or modify the code and you generate the diagram. So it's sort of bidirectional and having teams and companies use it for managing their application logic at scale, and so that's where we are now. What I find interesting is that you mentioned that during the pandemic, you wanted to do something more exciting.

And you started a startup. Like other people would start a podcast, start baking bread, and you decided to start a company like that's, that's unusual, like, what pushed you in that direction? Well, so it wasn't a zero to one like, or in state machine terms, it wasn't an immediate state transition.

Play from 0:00

Basically, I was already working mornings, nights and weekends on XState because so many people were dependent on it. During the work day, I had very little opportunity to work on XState unless it was relevance to Microsoft projects. So I, I, I just had the urge to just work on this fulltime, you know, just because it's not sustainable to work, after or four work hours. On this side project, and sometimes side Pro, so basically, side projects have two like next states. A side project either becomes something that you forget about and neglect, or becomes something that absolutely consumes you. And then you just want to do anything you can to keep working on it. And so the latter happened for me. Yeah, so there's kind of that, that hunger for solving a very specific problem. What is fascinating also about the fact that you mentioned state machines, that for anybody listening to this, the when you bring up the word state machine?

They think of this like intimidating things like, oh, no, like, back to the days of like, computer science. It's going to be the super complicated, but it's really not. Because, like, I like, looked at Stately, I looked at XState and it's like it does simplify to developer Workow quite a bit. So what do you say to folks that are kind of intimidated by the? Concept like, Oh, state machines like this, is this like super hard thing for me to understand? Yeah, so it depends who they are, you know, whether their role as a developer or whether they're Norm Noral person. You could say, Hey, are you familiar with flowcharts? Well, state machines are basically like flowcharts, except more, formalized. Or if it's a normal person, I ask them, can you be asleep and awake at the same time? No, those are considered two different. I mean, if you are, then please go see a doctor.

But those are considered finite states. You could only be in one of those states at a time. And so that clicks immediately. And then it's like, how do you go from asleep to awake, or awake to asleep? Well, if you're asleep and your alarm goes off, that is an event that happens, that transitions you from asleep to awake. And then I say, we could actually draw this process out with pen and paper. You draw asleep, awake, and then you draw arrows between those states. And then I say, that's a state machine. A state machine is just a thing that tells you, given I'm in some state. When some event happens, what's the next? That's all it is. It's something that answers that question, very, very easy to understand, so effectively, it allows you to define logic in more visual ways. As you kind of called out earlier.

And this is something that kind of, I think, crosses an interesting boundary. That in modern days, there's kind of this push for no code, like low code, no code. And that gets you into the world of, yeah, you go in, you pull some like things together. You know if this event, like, if or like, was a good example, or like one of the Microsoft offerings?

Play from 3:00

But that abstracts out the code completely, I never see any of the code at all, I cannot modify the code, I cannot generate the code. It basically is some proprietary system where I have to define the workflow and what you're building with Stately and XState. The code is actually a fundamental part of the equation, like you're not getting rid of the code. How, the how do those worlds kind of mesh together, like the no code world and the one? Where you're actually intentionally about keeping code into the picture. Yeah, it's really interesting because, if you remember, back whenl was, I don't know, popular or something that was heavily advocated for. I would say one of the reasons that it quote UNQuEs failed, I mean, we still see remnants of it every day. But one of the reasons why it failed was because it's like, hey, you could actually just draw these diagrams out.

And then you get code generated on the other side, but do not touch that code. That code is not meant to be read, it is not meant to be modified or anything. If you do, you screw up the whole process. So, that's one of the reasons why with ExED. I really wanted to find that delicate balance between meeting developers where they're at, which is one of our guiding principles at Stely, and also the ability to visualize that code. And so that's why with XState, it does have that structure where people, people are like, why am I writing this whole J.SOn looking thing? And then you realize that the purpose of it is so that you could get that visualization and B directional editing. And now with, I, I know it's very hyped right now. But with AI and LLMs, we are exploring ways to basically have that same functionality with basically any code.

And so we're taking baby steps there for now, but we think that's going to be a huge step forward. Basically, any code that you have, any way you express your app logic. Go ahead and visual ize it. And hopefully have a way to transform that back into the same code that you would have written. But we do find the principle of meeting developers where they're at very, very important, which is why we've been working so hard on TypeScript support and, developer ergonomics. And just making an API. That, if you wanted to, you could just use it in plain code, and you could use the diagram to supplement that code. So, really, we call it, or I call it, actually visually augmented programming. It's not low code, it's not full code, it is code with the benefit of having a generated model. I like the framing and I'm going to latch into the. Word of developer ergonomics, and that is something that not a lot of folks think about.

And that it's not about getting rid of the code, it's about increasing developer productivity with the code and making them make better decisions faster. MH exactly as you're building Stately, so you were an engineer, you, you, you were an engineer, you're building a library, but building a company that seems like it would take a whole different skill set.

Play from 6:00

Like, you need to have that business Acumen, which you're kind of exhibiting and growing as you're bu building your company. Was it something that you actually wanted to get closer to, or is it more of a byproduct of? Well, I'm starting a company? I better be good at business? Well, when I, when I started Stately, I realized that, okay, I have to really shift my skill set from being a developer to being a combination. You know, founder, CEO, manager, everything, you know, that typical wearing multiple hats in the startup thing. And those are things that I really had to learn quickly. Now, thankfully, I have a lot of friends who are, who are also Founders SL developers, so I would have regular meetings with them. Pick their brain, understand how they do things, and try to emulate that. Admittedly, I don't try to read, like every book in the world.

For, for, you know, running a business just because, you know, times change and what worked 10 years ago is not going to work the same today. So, yeah, just having a good network of other Founders, and developers who are business-minded, really, really helps. But yeah, it's. It's honestly been an uphill like, not a struggle, but just like a really steep learning curve. Just learning how to operate a business. But also, you know, just do the development at the at the same time, and admittedly, I am doing a lot less developments than I was before. But that just comes with the territory. Once you become a founder like, you have to shift your priorities and balance them between managing a team. Pointing the business in a direction that will hopefully take off. And also, you know, as a technical founder, doing some developments, you mentioned network of Founders and AS. Somebody that came from the, I want to say, like the Fang world. Even though Microsoft is not on the acronym, I guess it's different now.

But how do you build that network of Founders, like, how do you bootstrap it? Especially for somebody that you know you were not at a startup before you started a startup? The immediate states. Before I was, I, I. I talked at a lot of conferences and, from there it's actually pretty easy to just network with fellow speakers and developers. So I. I've built up my Net network there. Now, it's easy to say like, oh yeah, you already had a network, like, it's easy for you to just have that network. But if you go back, maybe I want to say, you know, six or seven years, or actually seven or eight years I'm trying to think of. Before I started XAT, what I actually did was, you know, I, I was on Twitter with all of 10 followers. And I just started looking for open source projects that I was really interested in, I started to contribute to those, I started making open source projects of my own.

I also wrote articles for, different online magazines such as Scotch..io, which was sold to digital Ocean. And that is honestly what started that whole network effect, because you network with other developers and you get your name out there. And I. I remember getting excited when I hit like a thousand Twitter followers. But I just kept creating more and more, getting my name out there, talking to more developers. And it eventually snowballed to the point where when I decide to start a company, I already have that network. The audience actually helped you bootstrap what you have now. Do you think that's a recipe that is replicable by folks like I? I need to start with an audience before I can go start a company. Or can you go the other way around as well? In my opinion, it really, really helps a lot have a big audience because that is your initial market, otherwise you're starting off cold. Like, if you start a company, you might just really pitch it to Y combinator or something.

Raise a couple million dollars and then you have to spend a lot of that money. On marketing, advertising, E.t.c. Just to get your name out there, but if you already have that audience, it becomes a lot easier. So speaking of company funding, you mentioned like, why Combinator? What about, your own kind of decision to make Stately VC funded, right? Because there's different approaches to how you like how investment flows into a company. Some people do a solo bootstrap. They decide, like, I'm going to do it myself. I'm going to do this, you know, for my own funds and get the family to invest. What was your rationale for saying, like, you know what? I think VC funded is the path to go? Man, that's a that's a tricky question, because of course, there's. There's basically two paths, or I want to say three. The the first.

Easiest path is just to keep doing it as a side project, and I say easiest because it's it. It's what I was doing already. But in reality, it is very difficult to have a side project and a full-time job. Especially at Microsoft. And then, of course, there's the other two options of being bootstrapped or getting VC funding. Now, I want to say, contrary to a lot of developers, I know I don't have the most money in the world, you know, I, I have a very average life and ways of, you know, means of living. And so bootstrapping wasn't the best option if I wanted to build a team and really build out the software, because I would quickly deplete my own savings. So that's where VC seems really promising. And so that was three years ago, you know, three years ago. It was easy or not easy, but it was easier than today to get money from VCS and to actually start, a company. Now, of course, it's a lot harder, but I will also argue that now it's easier than ever to bootstrap.

And many, many people think like, Oh, bootstrapping means you have to have a lot of money so that you could hire a team and do that without raising external funding. But, again, falling into the hype with AI and ChatGPT, it's actually very, very possible for you to be productive building your own company as a solo founder and a solo Bootstraps founder. At that, so, I, I don't know what I would say today, but I at least three years ago, uh. Raising funding from VC was the easiest option, the company structure itself. So you're not solo anymore, right? Like you, you hired people for Stately, what was that turning point for you, where you decided, you know what? Like, I can't build this by myself, I actually need to hire other people. Because, again, kind of the misconception sometimes that entrepreneurs can have is that, oh, I can do this as a side project, I can run this myself.

Then you have to wear many hats yourself, and then you just hit the point where it's like, all right, I'm burning out. Yeah, yeah. So at the very beginning, when I first received a message, it was actually a D DM on Twitter that said, Hey, have you considered starting your own startup? I immediately went to, his. His name is Mat Binski. He is another contributor on the project. He's, the like. Besides me, he has contributed the most to X Datat. And so I immediately started talking to him about, like, Hey, what if we were to do this, fulltime? And I was talking to, someone else. Mattz Pook, who did a lot of work on XState and made a lot of really great examples and was a huge advocate for it. I talked to him as well. So I was already thinking of a assembling a team. Just because I know that I. I had a really ambitious vision and it's not something that I could have done myself.

Plus, when you raise VC funding, the assumption is you are going to build out a team and do that, and in this case, the team. It sounds like it kind of came organically from the project, like you did not really have to go and seek out random people that would build it. It's people that are already contributing, people that are a known quantity, if you will, yeah, exactly, it was, it was pretty organic, and honestly, if you are going to start a project that you hoped to succeed, chances are you're already going to have Champions. And you're already going to have people who are so devoted to the project, whether it's contributing to. It, or using it, that some of them are inevitably going to be like, Hey, you're starting something, I want to do it with you. And those Champions are probably going to be the best employees. Because at that point, it's somebody that really kind of loves what you're building and they want to contribute to it, and they're more or less invested.

Yeah, absolutely. And in your case, the folks that you were talking about, that you hired for the company. They're distributed like you don't have an office, you, they're, I believe, in Europe, right? Like you. You mentioned it on another podcast that they were kind of like, all over the world. Yeah, we have half of the team in Europe and the other half of the team is in the United states. East Coast and Central time zone no one on the West Coast because of the time zones, and they're expensive. Nowadays, a lot of folks that hire remote for their teams, especially at bigger companies. They sometimes kind of squirm at the idea of, oh, like, we need to do like cross, you know? Across the ocean, the time zone difference is going to be a little too big. And in your case, you make it work. It's just a matter of waking up early, honestly, try to wake up early, and also even if you don't wake up too early.

Like, if you wake up at 7, then it's sort of like Christmas morning every day, because you wake up. And all of a sudden a lot of work is already done and you're like, Wow, okay, this is, this is pretty great, uh? Plus, it's sort of a win-win because for the Europeans, if they do start their day a little bit later, then it actually works out better. You know, they could do things in the morning, take their kids to school, E.t.c. But yeah, I, I would strongly recommend the. The caliber of developers in Europe is, you know, pretty much the same as in the United states, like there's just good developers everywhere. And what's your approach to organize Communications across kind of the different folks on your team, given that everybody's distributed? It sounds like it, you know? There's kind of the common idea that, oh, the best work happens in the office. Because you get in the room, you can wideboard things, you can easily iterate an ideas.

But when everybody's distributor, you literally have no chunk of the team that is in the room. How do you set it up? Actually? Technically, I'm an introvert, so even when I was working an office job, I just tried to find some quiet, you know, quiet time. And actually, it made, it made working with co-workers better, because it was time that it wasn't just a random. Hey, I'm just going to work with you and talk with you. ETc. It was a meaningful hey, I want to collaborate with you on this specific task right now. We do use a couple of tools, and remember this was actually during the pandemic. So, you were sort of forced to work remotes anyway, and we really had to make it work. Uh. But we use Discord, we use Gather, and Gather is actually really interesting because it's an app that really makes it feel like an office, at least in a remote setting.

So that help helped us a lot. But our communication was async, even our stand-ups every day are async.

Play from 9:00

We do, of course, have meetings together, but, most of the time we just do everything async. Starting a company, though, it seems like a very risky Endeavor. Like, especially coming from Microsoft. Where you have, like, a stable full-time job, right? Like, you have all the benefits, all the perks that come with. Like a big corporate job, especially as an engineer. And then going on your own, did you do anything intentionally to? I want to say, like, drisk your Endeavor to like, Hey, if things don't work out, I have a backup plan. First. It was, of course, talking to other Founders who were in the same position years ago. They they had a cushy, you know, full-time job at a big company and then they decid to start their own thing. But also talking to people within Microsoft, and, of course, some of them, they actually did the thing where they started their own company.

In a few years. They just did a round trip and came right back to Microsoft. Just because Microsoft is a really good place to work for, and so that's why. You know, while at Microsoft, I was trying to do the best work that I could, so obviously, no Bridges were burned, so I still have a great, you know, network over there. And also another thing to realize that when, like, there's there's sort of this Paradox that if you're a founder, you feel like you're falling behind because you're not working at a Netflix or Google, or Facebook or Microsoft or anything like that. Sorry, Meta, not Facebook. But, it's actually the opposite, because you realize that you're actually, of course. Besides doing like, continuing your development skills and continuing to innovate and learn the latest technologies, you're learning really valuable business skills. And, management skills as well. And so if worst comes to worst and your startup doesn't work out and you do need to put yourself back on the market and work for another company, then those skills are going to be extreme, extremely valuable.

Because the point of a company is to make money. And now you are much better equipped to, help any company that you work with, to achieve those goals. It sounds like it's just a way for Accelerated learning, because it kind of pushes you outside the comfort zone of, hey, I'm an engineer to I'm an engineer, I'm a product manager, I'm a designer. I'm like, whatever other role you need to fill, like, where else can you get that amalgamation of skills in one place? Yeah, it's accelerated learning, and it's also trial by fire. Definitely, yeah, yeah, especially if it's you have to kind of figure out, like, how to actually validate the the company. But was there any point when you were building XState where you kind of realized that, you know what this could be? A company like this is something that we can probably make into a revenue generating Venture. For most of the time that I was working on XState it, it really didn't occur to me.

I just thought like, hey, I would really like to just devote more time to this. Just because people really rely on this software for their day-to-day jobs. So, yeah, I. I started a sponsors program where I was like, Okay, you know what, maybe I could supplement my income a little bit with this, and, you know, maybe charge. $5 a month and people did contribute, but it, like, at the end of the day, even though a lot of people contributed, it was still a very small amount. So, yeah, it never really occurred to me to start it as a company. And that's really how, how open source goes anyway. Once again, very organic transition of like, huh? This seems to be picking up some steam, so let's let's do something about it, exactly. And so now that you've been doing this for close to three years, I believe with Stately right, like it's MH. What were some unexpected takeaways in a life as a founder that maybe you didn't anticipate?

Going in, or going down the path of starting a company? Oh, there were, there were a lot. One of the biggest ones is, uh. When you, like, when you're a first-time founder, of course, you hear all of these stories where it's like, yeah, founder life's really difficult, and join and making a startup is really hard. But you're not thinking that at the moment. You're thinking I'm going to have so much fun with this, I'm going to build a company, and, we're going to do this, this and that, and we're going to have so much freedom. But, ironically, one of the biggest surprises was that by thinking that those things were, you know, exaggerated, I, I was actually shocked because they're not exaggerated at all. Being a founder is extremely stressful. So, yeah, it's, it's not just a meme or a joke, it's it's really, really true. How do you manage that stress? Like, what's your approach to making sure that every day you can wake up and say, I'll continue doing this?

You have to have passion for the project that you're working on. That's honestly how so many Founders, just keep on going with their project. Because it is very, very easy, to quit, especially if you took VC money, it's very easy to say, you know what, this isn't working out. I'm having a very hard time finding products. Market fit, so I'm just going to shut down, uh. And if you really, really believe in the mission and the vision of what you're building, then you're going to find every single possible way to make it work. Especially if there's outside validation, too. And I mean, that's that's where I'm at right now. I'm extremely passionate about this and no matter what, I, I definitely want to keep it going. XState itself as a library, so you've built a pretty significant community around it. And building communities is never easy, like building anything around any product is never easy, especially anything of, any significant size. Was there anything that helped you boost up that community around the product that you were building early on, or was it just more of a wow?

There's a lot of people that have this problem, that kind of started aggregating around the product. What was the path? There will be a lot of people who tell you, yeah, to build a community, you need to do this, this and that. Like, watch your metrics, keep producing content, which is true. Like, look at your numbers, ETC. But honestly, I wasn't thinking of how do I build the biggest community? It sort of is something that came naturally because I was just focused on talking to users. Seeing what their problems are trying to, you know, fix their problems, see how they're using XState. And just, you know. Networking with other developers and getting involved in projects and Trends and things like that. And so it. It really never occurred to me, like, Oh yeah, I have to do everything I can to build a big community. And in fact, organic communities are better in many ways because it has a stronger Foundation than communities that you try to force so many people into.

And how do you find the right? I want to say, like, customers to talk to in this regard. Especially because for an open source project, there's going to be so many people with so many opinions and asks and feature requests. That sifting through the noise seems to be hard, especially for, again, a large scale project like XState. Honestly, I. So when I first started off XState, I was looking at other people's use cases and really just following Trends there. You know, they're using it in the front end, they're using it in the back end. And that gave me a better idea of what are what are the problems that people are trying to solve and how. Can we best make tools that help people solve those problems? So, of course, yes, there's a lot of noise. And before XState, I actually made a small, or, yeah, it was a small project compared to XState, but it was a for library.

And whenever someone said, Hey, I want to do this, I have this use case, I have this feature request, I was like, Okay, I'm going to go ahead and add it. And it became so bloated and so complex that, you know, I learned my lessons with XState. And, I guess, perhaps counterintuitively with a startup, and especally esally with a Dev tool product. It is important to constrain your features and say these are the specific areas that we're focused on. We're not going to try to do absolutely everything, and that's especially true with basically our state machine modeling software, where we're like this, you know, this is for state machines. If you want to build something else, I could recommend you other tools, but this is very specifically for this. And that really helped cut down the noise, too. Because you define this is our product, we. We're not trying to, you know, add every feature that exists in other products.

We're just trying to solve problems for our users. And you're not afraid of actually recommending competitors for things that the product is not well suited to do? Because I think that's the scary part sometimes to say, like, well, if a community member asks for something and then we point them somewhere else and say, actually, there's a better product for it, go there. It's like, well, aren't you losing a customer? Aren't you losing potential for Revenue by saying no? Chances are they? They already have, like other people in mind, or other use cases in mind, so it actually really rarely comes up. People who discover Stately, they already are. Like, I'm either using XState or I have a problem that very specifically fits the. I need a state machine for this, or I need to use the actor model for this. And so, those conversations don't really come up, uh. However, when people do talk about other tools, then we do get inspiration.

We're like, Okay, why are they using that tool instead of our tool? And. We're not trying to convince them to use our tool, it's just something that we learn about. And, you know, just keep in the back of our minds. So that we could improve our product if it makes sense for our feature set in our goals. I really like that approach, it's the intentional scoping of I want to do this, this is what our product is about, and really not trying to do everything. Because, as you said, like, it's very easy to for things to bloat and for things to become out of control. Because every customer wants something. And then you're not solving anybody's problem at all, exactly. And I mean, to be fair, we're, we're still making those mistakes. Especially as a firsttime founder, where I'm like, Hey, this feature would be cool, let's add this feature and that feature.

Play from 20:00

And Now's the time, where, you know, we have to just scale back and say what we have is what we have. Don't add any new features. And that could be a really hard thing to do. Because, you might think, okay, in order to get more users, I have to get, add more features. And nothing could be further from the truth because the. It's easy to say yes to everything and then you're swamped. Your product has no definition. But if you say no, you just said no to that one thing, that's kind of it, exactly, exactly. I like that, I really, really like that. Well, David for folks on the show, and I always ask the one question to wrap up the episode. And that is, if you think back about your career, your work, things you do. If you give one piece of unconventional advice. For somebody that listens to this and says, I want to follow David's journey, what would that be?

I would say, optimize for what your passionate about. There's the old saying where it's like, if you enjoy what you do at work, then you'll never work a day in your life. Which I, I mean, I, I get the idea behind that. It's not necessarily true. Like you, you are definitely working and working hard, and you might be doing things that you don't want to do. But it just comes with the territory. But at the end of the day. That's going to be what keeps you going so honestly find something that you're passionate about and just hone in on that fantastic advice David for folks that want to learn more about the work that you're doing the libraries you're building where should they go I am @DavidKPiano pretty much everywhere on the web GitHub Twitter Instagram I guess places like that and they can go to stat. to see you know the work on Stately and we'll include the links in the show notes for XState I highly recommend folks check out the library and David it's been a pleasure talking to you today thank you so much this has been great

Play from 30:00