Steve Ruiz: He Turned Down Adobe. Then He Shelved His Own Product.

I actually killed the project. I was like, this is not— it's just not differentiated enough. It's not like unique enough. The thing that was really unique, the thing that had no competitors and no like saturated market was—

Steve Ruiz was about to start at Adobe. He had his bags packed. The job was accepted. He started on Monday, but then he looked at what was happening with his side project, an open source canvas that he'd been building. Hundreds of sponsors had put up $200,000. And two major companies wanted to build on top of it. So he called Adobe and said he wasn't coming. That project became TL;DRAW. Steve's background isn't in software, it's actually in fine art, and he has his master's in it. He spent thousands of hours studying ink on paper, how it moves, how it bleeds, how it dries. And when he wrote the algorithms for digital ink, he had this deep physical understanding that most engineers just don't have. And he's put in 10,000 hours of that kind of labor. It's the whole reason that TL;DR even exists. We're gonna talk about why he shelved his own SaaS product to focus on the software developer kit, why he thinks craft only matters when you're building for high-agency users, and his surprisingly simple answer for the question every open-source founder faces: how do you actually make money? This is State of Play. Let's get into it. Was there kind of a moment as you were coming up where you said, oh wait, this, this arts background is actually a really unique perspective in this tooling space?

There's some obvious ones, right? Like, okay, I'm, I'm working on design tools. I'm working on visual tools. I'm working on like ink and arrows. And of course, like I worked a lot with ink, you know, spend my, you know, thousands of hours looking at ink move across paper and stuff. So, you know, when I later worked on, uh, algorithms that, that tried to approximate that, yeah, like I just had a, a ton of knowledge that was very specific and, and, uh, appropriate for being able to make good-looking digital ink. 'Cause I'd spent a lot of time looking at, at, um, good-looking non-digital ink, I suppose, analog ink. Uh, the, the, the surprising thing was just how many parts of the way that you work when you're doing art translated over into just doing software. Um, and doing software in a kind of an interesting way. There's a long answer to that question. I'll, I'll try and give you the medium, medium length one with, with some, some meat. Uh, which is, you know, if you're, if you're an artist, if you're working alone, um, especially with, if you're kind of early career or so, right? Your job is to, to find something that interests you in a way that really is evident to other people. You can kind of tell pretty easily, or at least I can, when, when an artist isn't really into their own work, um, because it's usually kind of shallow and, and, um, isn't really like iterated on enough to, to become really, really unique. But, uh, the problem is that unlike design or unlike software where you have a user, you have some problem that you're trying to solve for this, this, you know, theoretical user. Uh, when you're in the studio, it's, you know, if you're painting, drawing, like you don't really have a, anyone, no one, no one cares. Uh, and no, no one should care. I mean, it's, you're either gonna make something that you like or you're not. That absence of, of constraints, that absence of, um, you know, reasons why you need to do any particular thing rather than something else. That is the creative freedom that, that lets you kind of tune into, to what you really want to do, what you find interesting, what corresponds to your skills and your, the, you know, space that you have and the, the options that are in front of you. And that, that leads to the, the artwork. Uh, but it's really, really hard to be working without external constraints. It's really hard to work based on nothing but like, well, here's, here's what I think is most interesting to do next. You, you develop strategies, uh, as an artist to, to do that. And part of, I guess, what you learn at art school is like, um, you know, how to think critically about something that doesn't really matter. Like, you know, it doesn't have to be good, but, and it's really hard to even say whether it, you know, art can be good or bad or a painting is good or bad, but yet you're gonna try and make the best one that you can, which seems like a contradiction, but that's still the, um, that's still the game. And you, you do get a sense for how to, to work in this very, very open space of, uh, um, of the studio. And, and that surprisingly actually worked really well, especially when I got into, to open source where it was like, hey, you know, this is a side project or, or this is an open source project. I, I don't have to do this for anyone. I don't have to do this for anything. Um, there's no immediate reason why I should do this. And yet I have a pretty good idea of what it, what is most interesting to me. And I have a huge appetite for the type of working on something without immediate feedback on, oh, this is a good idea, or this is a good, you know, validated or, um, externally. Uh, in other words, like, I feel very, very comfortable saying, okay, I'm gonna work on ink, digital ink, and I'm gonna work on it for a long time, and I'm gonna go like really deep into it. Um, and even though I, It's not making me any money, or there's no clear reason why this thing needs to exist, or that what I'm doing, that even that I'm the person who's supposed to be doing this type of work. Um, well, that, that doesn't matter. I've already done that a, a hundred times. I've put in 10,000 hours of like unmotivated work or, or, um, like pointless labor in terms of, uh, in terms of artwork, because I know that at the end of that, you know, either is, um, a new direction, which I wouldn't have discovered any other way, or you can actually create stuff that, that really is great and really matters. But the only way to do it is to just kind of to do it. You kind of take that risk with your own time and with your own, I suppose, like the value of your own labor.

Some folks might say art is something that you, you really start by creating for yourself. And in, in tech, we're so focused on the external feedback we get. The product-market fit, um, will, will maybe give a little bit of, uh, attention to this idea that the creator has to enjoy what they do, and we'll call it product-maker fit. Um, and that's about as much love as it'll get. Or we'll say, oh, we're going to invest some time into just some exploratory stuff that might not yield an ROI right away. You're loss-leading. Um, and, and my relationship with, with kind of this idea over the last 15 years is everything has had to at least have some sort of ROI. I've been so obsessed with it. I've gotten good out of, out of necessity. And now I'm telling my team, let's move forward and play and experiment. And it's okay if we fail, but I want us to try some things that are a little unconventional. How has your relationship evolved coming from art into technology around that?

I have a pretty big tolerance for kind of trusting my gut. And, and kind of working without knowing immediately what you're working for, uh, or working towards. Because I, I just trust that, hey, look, if something is really, really interesting to me, uh, there's probably a reason why that's, that's the case. Um, I might not be able to articulate it right now. I might not be able to see it right now, but like, you know, my, my, you know, context window is really packed with, uh, you know, uh, with, with what's possible and within my specific domain. That I'm working in, but also just in general in software and stuff. So if, if something is like shining out or something really makes me feel like we should work on that, there's probably a good reason for that. I think the, the way that you negotiate those, you know, the, the, like the risk of play, uh, you know, the risk is that you, you put a lot of smart people in a room and get nothing out of it at the end because, you know, we've, we've investigated some things or we've scratched some itches, but like, Nothing comes together. The way that you kind of, the way that I, um, work with that is, is essentially setting up these parameters that make sure that something is gonna come out of this. Now that might be, uh, social media content, it might be marketing content, right? That if at the end of the day, the worst thing that comes out of this experimentation is that we make some banger tweets, like that's good. Like that's fine. It might have been some expensive social media content, but at least it's documented. With TealDraw, we have the ability to create examples and starter kits and just, you know, play with our own toys. And there's almost no wrong move there because it's all gonna be useful to, to, to someone, or it's gonna be useful to, I mean, these days even just as, so that someone's coding editor, you know, AI can say like, oh no, no, I found an example of how to do that, you know, on Online or something. A lot of content creators will do a ton of low investment content creation, very easy to do content creation that, that kind of just, you know, tries a whole bunch of different things. This is kind of a, you know, tweet, tweet, tweet, tweet, tweet, or, you know, lightweight post or something like that. And then you see what, what really hits either what really hits with an audience or what really hits with you. And you're, you're like, no, no, no, there's more there. Uh, and then you do the next level of like, you know, labor intensive, the next most labor intensive thing based on the survivors of that first, um, generation. So if you put out 20 tweets and, and 2 of them start getting traction, like, well, one of those can become a blog post, right? You don't pick the thing that no one cared about and do a, a long form video on that because like, well, no one cared about it, right? Especially if you've repeated that same topic multiple times and, you know, no one ever cares about it. Maybe you, you pick the one that, that has an audience and that audience could be you. You could be really, really into that thing and, and okay, fine. And, and I think you can do the same thing with building as well, is that you can, you can try a whole bunch of things in a way that is very lightweight, very lo-fi, or that very like leverages different tools in order to, to, to prototype quickly. And then you, you know, try it out either with your users or you, or with each other and the team. I think teams are great for kind of like judging this type of thing internally. And if something is compelling or if it, if there feels like there's more to a certain idea that that idea kind of leads to other ideas in a way that, that seems unique, then you invest more in that.

You refer to the canvas that we're referring to in this case is, is digital ink. And, and I, and I actually really like how you talk about that because I, I feel like you're giving respect to the fact that this is an art medium, um, it can still behave that way. In my brain, I always told myself the story that I'm not good at art and I'm not good at illustrating or pen and paper. So I'm gonna go into design because there are these very rigid constraints that I have to operate within. But it seems like you think very differently about that. And I think I'm shedding these too. Was there a moment when you took yourself to kind of a digital canvas and said, hey, there's actually something here that's very artistic.

I, I think there's a big difference between working in, in, in art and, and working in software. Um, software is just easier. I mean, like, I mean, you, you, you know, to, to go back, like you have those constraints, you have that external user, you have that problem that you're solving, and that is a gift. I mean, like it, so many things just become so much easier because all of the possible You know, things that you could do are just narrowed to the ones that like, well, what, what do we actually think is gonna be, um, gonna solve this problem? It's gonna help this user, is gonna entertain them, delight them, you know, all that. And especially if you're the own, also like a user of your own product and invested in its, its quality and can, can feedback that way, you know, then it becomes this kind of prosumer loop and you're trying to satisfy yourself and you, you, you know what good software feels like or good, you know, Hopefully, uh, you know, you're, you're on a team that can, can have that kind of critical, uh, eye towards the software experiences. I think from a, from a creative satisfaction perspective, um, in many ways the software can be more creatively satisfying. If you work on a project long enough, you, you quickly run out of obvious moves to make. Like, uh, even if it's a fairly conventional, um, a type of product, even if it's an email client or whatever, and you're, you're, you have this long list of, uh, table stakes features that you're kind of grinding through at the end. You, you, you, you'll finish those things and it'll be this space of like, well, what do we wanna work on next? You know, what do, what do we think is gonna, um, be the new, you know, and, um, the, the process of discovering that those new features or those new experiences or, or those new kind of like sister products or something. There's this, this kind of loop that probably every, every creative person goes through where you're like, you have this like empty canvas, uh, panic, you know, um, of like, oh my God, like there's, there's no guidance other than, you know, like what I can think of that, that I've like my own creative imagination is, is really the limiting factor here. And that, you know, whatever we're gonna work on has to sort of occur to me. Occur to us. And if it doesn't, then, then we're not going to make it. And if we're limited to what does and all that stuff, right? And that can feel very, very like scary or daunting. But then you do it and then you, the good ideas come, you build it and, and you make it good and you put it out in the world and you're, you're proud of it. And that, that kind of self-reliance, you know, uh, loop of, of knowing that you can, I don't know, get lost and find your way out again. Um, again and again and again. Like that's, that's the, that's the, you know, that's what keeps me coming back. I, I have that same feeling whenever I write. I have that same feeling whenever I, I, you know, would, would start a painting and whatever. Um, and software too. Like it's still like whenever we, we need to work on something big or need to kick off something big, it's always like a, all right, like, can we do it again? Can we make another hit here? Like, can we, are we gonna be able to figure out this time?

It already makes a lot of sense why you've been somebody who is increasingly finding new paradigms and ways to solve things from kind of a user experience perspective because you encourage so much play in the process, it seems like. Or do you subscribe to the idea that in each medium, so desktop or mobile, um, that there exists a ceiling of patterns? Uh, there's only so many ways we can create around progressive disclosure. There's only so many ways we can reduce cognitive load.

I would say the majority of like software experiences, uh, have not been discovered yet. I think it's still a very young young medium. If you had asked me 4 years ago, or like, you know, do you know what a chatbot is? You know, I would've said, yeah, yeah, yeah. It's super mature. Like Intercom is adding it, you know, it's, it's like, it's a very, very conventional thing. And now that's been completely exploded in terms of what I can expect from a chatbot and what kind of interactions exist within that. And I really like the, the fact that so much of software experience has been become conventional, uh, because it lets you focus on the things that are not conventional. So, uh, especially as a designer, as a maker, I mean, there, there was a, there was a time where I, I feel like a lot of designers, maybe we'll see it again with the Liquid Glass thing, but a lot of designers were spending a lot of time rebuilding, um, and, and building component libraries that like rebuilt native, you know, interactions and like native headers and toolbars. And I saw this in all the prototyping tools. Tools as well, where folks were like reimplementing all this stuff. I'm like, what a total waste of time. Because like, uh, like, good job, you did it. No one notices. Like, you know, cool. I'm sure it was like, you learned a lot about building components and building, uh, the design systems and stuff like that by, by copying. But, um, you know, it's not differentiated. Like, and I think the, the fact that like a combo box is pretty well known. As to what a combo box does and, and, you know, error text underneath a, a text input or, or the way that you set up an account menu or something like that, it was good. Like, I hope those things continue to conventionalize and like become more and more boring to design because, uh, we probably won't be designing them, you know? Um, we probably will be spending that energy on the parts of the, the applications that we work on that are like unknown, that are, that are new. And I, I really do think that there's a lot. Left to explore there.

You've described yourself as kind of prototyping obsessed, and, and I have to ask you, and maybe this is a, a pretty conventional answer, um, but I'm curious, how do you decide when something, a point of play in prototyping, like with TLDraw, you, you know, introducing something like the infinite canvas to maybe match certain expectations that exist on the market, but then going completely unconventional with some of the things that you can do on top of that canvas How did you start to say, yes, this is now ready to go and, and become a full product?

It was always kind of a full prod— like, it was always like, well, and in some ways it's not a full product. Like, we don't make any money off of TealDraw.com. You couldn't even log into TealDraw.com before January, and we had like 200,000 users a month, you know, but, but no one, no one could log in because we just hadn't done that and we didn't really have to in the the demo, the experience of Tilder.com was actually kind of fine, uh, without it. I think it's better with user accounts, but it was, it was kind of fine without it as well. Uh, you could still collaborate even though it was anonymous, but you know what, you, you tend to know who you're collaborating with anyway. You tend to send that link to someone anyway. Okay, you couldn't save files forever, or you didn't have a list of all your previous files, but you know what, most of the collaboration was ephemeral anyway, and you could always just bookmark stuff or or put it in a note or something. And so there were all these like kind of folk habits that people were building up around how they managed their, uh, their, their use of TealDrop before that. Like any prototype, it's, it's kind of real, but it's also kind of not real. It's also like, you know, it's, it's as good as you could make it given the constraints, but you know that you could always invest more in it and, or throw it out and start over. And I certainly did that a couple of times with TealDrop. Having done prototypes professionally as like the prototyping designer and, and technical designer, um, as well as just on many, many of my own projects, really the line between the prototype and the, you know, the, the actual product starts to blur really quickly. Um, and that the mentality that I had working on prototypes and the, the way of doing that just out of, out of, out of necessity when, when working with design teams. Uh, just turned also out to be a good way of doing software, which is that, um, you, you try and be as like clear as possible because you think that you're going to throw this out later. Um, you try and have loose couplings between different systems because you want those systems to get, you know, reused on the next iteration or replaced pretty easily. Um, you, you document a lot because you assume that someone else is going to be reading this in order to to like create the real version of it later. Uh, and you don't build more than you need in order to create a kind of compelling experience. And, you know, when we did, uh, MakeReal, you know, that was also an incredibly thin, uh, MakeReal is where you could draw a user interface, click a button and, and, uh, GPT-4 with vision, which was like the first multimodal model would go build it for you. And then the, the thing that it built would, we would put it back on the canvas and then you could like draw on top of it and, um, and like annotate it and give more context and then do that again and say like, okay, you know, I've crossed out and things left notes and like, all right, make, make that real again. And, uh, and you could iterate kind of forever that way, um, by just by drawing and people made incredible things. It was one of the first like videocodey type of, uh, apps that let non-technical people build interactive stuff.

It seems like you kind of optimize the critical mass around features of the things that are in the hands of the user. So like, I mean, like you decided to forego user authentication early on and before you poured into that and then some of the other features, you're like, you know, what's in the hands is what we're going to try and make work well. And then we'll kind of extend beyond that. Is that, is there, is there like an intentionality around that or does it just kind of. You just kind of approximate in that direction?

You focus on like the features that really, really, really matter, uh, that people are going to absolutely use, all of the users are going to use, uh, and then you kind of go out that, that next step of like the things that some people are going to use or some people are going to need or some people would want. Um, but if you don't have that core, like if you don't have the core user experience of a, of a piece of software like excellent, and, and validated and like iterated on and putting a ton of en— energy into that, nothing else really matters. I used to, I used to ride my bike a lot, like long distance cycling. And you can spend a lot of money on cycling. You can spend money on every single part of the bike. You know, if you want a, a carbon fiber bottle cage for $40, like you can find that. And the way that you make that manageable from from the perspective of, of, you know, the, the, the cyclist is that you, you have to give some sort of priority to the things that matter and everything else sort of becomes a luxury. And you're allowed to spend money on your hobbies, so luxuries are fine. But like the, the things that you, you care about first are the parts of the bike that you're touching. Like the, the parts of the bike that your body is gonna physically touch before you spend money on the parts of the bike that your body's not gonna touch. Um, because it'll just matter more. Right? Like that, that's the part of the bike that really, really exists to you. You can sacrifice, you won't notice the bottle cage, uh, you won't notice the, uh, uh, the, the, the whatever kickstand or something. Uh, but you will notice after, after 200 miles or 300 miles, like if the grips are, are low quality or something. And I think with, with software, it's the same. It's like you, you optimize for the, the part of the app that people are gonna touch. Um, and the people are gonna, gonna all everyone's gonna experience, and then you kind of deprioritize, or at least either you never build it, that's totally possible. Authentication for us, we just never built it. Um, or you, you just deprioritize it. You, you, you go lighter on those other things. Um, and I think most people understand that, like, and, and kind of even appreciate it as long as that core experience is great.

So you, so you optimize for the, the points of contact, the hands on the handlebars, the tires on the surface. Um, which makes it really interesting to think about the decision that went into, uh, TLDRAW, which operates very heavily. You just spoke about, you know, a non-technical person being able to come in and immediately prototype with very limited knowledge on what is happening in the background. But at the same time, this is a, a deeply developer-centric tool as well. You talk about the SDK and you talk about the philosophy that went behind making this open source and extensible from the start. Where did that come from and how did you kind of mix that into this, this core philosophy?

When I started TealDraw, it, it was kind of a follow-up to another open source project that I did called Globs, which was this experimental design tool that you'd have to, you, you'd have to see it, but globs.design. And, you know, I had built a pretty complicated canvas for Globs and, and I really loved the, the, the, kind of the UX paradigm of resizing things and moving it around, kind of building this little like Figma light type of thing. And I thought, you know, I'll, I'll probably keep making these, like I'm gonna be continuing to work on visual problems. Uh, and there really wasn't any solution out there for me to, to pick up and, and like use for, uh, like there was no open source around. Like design tools, like there was no design tool starter or canvas starter for, uh, for me as a developer. And I, I was actually surprised by that given how successful some of these products are, like Figma's massively successful. Uh, you know, Miro was, was massively successful. This was in 2020 or 2021. And it just made sense for, uh, for me to build that for myself. But, um, it also was such a visual problem. And you know, so many people were using these tools, like using Figma and using Miro that, you know, as I was sharing my work and, and sharing these problems that I was working on, uh, people just loved it. Like the content was, was great. The social media feedback was, was amazing. Like it just lends itself really well to, to storytelling on, on social media. I'm like, hey, have you ever noticed in Figma that the corners of the boxes are in the corners of the, of the box, even if, if you resize it, they don't, you know, the dashes are always in the corners. I don't know, whatever. Like, how does that work? Let's build that. It was really fun. And I just kept on hearing, as the project got more popular, I just kept on hearing from teams that were like, yo, we've been waiting for something like this to come around because we really wanted to build one of these, these types of apps, or we have this like design for this, this canvas. But, you know, as soon as we started working on it, we were like, oh my God, this is impossible to build, or this is like super complicated. Um, and, and like, like specialized work. So, you know, thrilled to build on top of what I was building. As the story goes, I had accepted a job with Adobe and said, let me start in January. Let me like finish this thing, uh, get this open source thing outta my system. Uh, and then by the time that I would've started working at Adobe, I had had like $200,000 of sponsorship from like hundreds of people and, and two major companies and had like, people were building with this thing and the, the tealchart.com was popular and the, the repo, like the open source part of it was really popular. And I was like, there's something here. I don't know whether this is, you know, like the, I, I'm going to end up making like a Miro competitor, which is saying, okay, end user experience, that'll be where I focus. Or whether I, I'm going to go in the other direction and focus more on the developer side. But either way, I had to tell Adobe I wasn't going to start work. On Monday. Uh, and really it took a long time to, to even decide which of those two directions we were gonna go in with regard to commercialization, because the work was the same either way. The work was to rebuild the canvas and to make it good and, and get all these features in. Um, and then when it came down to it, I felt like tildraw.com was, and we built a SaaS app on top of Tildraw. We never released it, but you know, where you could log in and have your team and, and get your Stripe credit card out and pay $10 ahead. Um, and I, I, I actually killed the project. I was like, this is not, it's just not differentiated enough. It's not like unique enough. The, the thing that was really unique, the thing that had no competitors and no like saturated market and, um, no super mature, you know, Muros in the space where it was, uh, was the SDK. And when software succeeds, it, it kind of just gets commodified. Uh, Trello was great. Trello boards like changed the way that teams work. Trello was amazing, but we don't call them Trello boards anymore. We call them Kanban boards, right? Like it's not a, not an application experience. It's like a commodity. It's like a, it's just software experience. I think we're seeing that happening in light speed with AI where like some company will come up with like, oh, agent mode, you know? And then like 2 weeks later it's like everyone has their agent mode. and it's like, all right, cool. That's, that's just a normal thing now. Um, and it, you'd expect with the success that had happened in, in whiteboards and, and canvas tools that that would've happened there as well, but it hadn't because it's a super hard problem and a very valuable problem. And every company that had started working on something like that was acquired. Um, and, and had that, that software folded into to some other, other company. If you're diagramming, if you're drawing, if you're on a, a quick call and you just need to send someone a link and, and work together, like TealDraw.com is exactly perfect for, for that use case. Um, and I, I'm really happy with that. I really like that, that role for it. And I'm very happy to, um, yeah, be able to justify the amount of quality that I like to put into a product through the SDK story where it can benefit thousands of different applications.

And, and I've got to imagine there was some conflict there, like quite a bit of conflict in deciding to open source versus, uh, kind of keep it proprietary or private. Do you think, uh, well, so I'm curious if that's true or not. And, and do you think, think what would've been, been different, do you think today had you decided not to open source?

The decision to share our code. To tell developers, you can build on this. We will continue to support this and we will continue to support you. It wasn't easy because there aren't a lot of good examples of companies that make any money at all doing this type of thing. Like there are some really great companies in this space in open source that, you know, are, they just, like don't, don't make nearly as much money as you'd expect given how much, uh, influence they have and how, how much impact they have on, on the kind of software world. Uh, React Flow for, for diagrams, uh, super far, like insanely popular, like way more popular than TealDraw. Um, I think we're making more money just because we're not, we don't have an MIT license. Like people, if, if a large company wants to use TealDraw, they, they pay large company money to use TealDraw. Um, and that's, that's very hard to do if, you know, most of the time based on the way that the company sold their, uh, access to their software by selling like access to their docs or premium, like little widgets that big companies can build anyway. And so there weren't a lot of like shining examples of, of companies for us to look at. It was a big bet that we would be able to do something different, uh, and, and make that work. The thing that we did different, by the way, is just not have an open source license and ask for money and ask for more money every time. And so it was, in a lot of ways, it's kind of a naive way of solving the problem. It's a little bit like that, you know, I use the Midwit meme to explain this, that like, ask for money, very complicated solution, and then just ask for money. Just charge for the product that you're offering and capture part of the value, like surprise, uh, everyone gets it.

You prioritize craft, but you also recognize there are these edge cases and these certain things that have to be done right in order for this to work in this context. Um, there are other teams and, and me included who I, I would at the first couple of versions prioritize a couple of those edge cases because I would want that those edge cases to be where we differentiated ourselves. We go to market having already thought about that. But if we were thinking through the kind of critical mass lens, that might be a waste of time initially upfront. That's not the points of contact approach. And so I'm curious, how do you define this word that's been, you know, overused this year, craft, in the context of TealDraw?

When you build a product or build a company, you kind of get to build it in a way that lets you take advantages, take advantage of your own strengths. And that's, That's what I feel like I've done with TealDraw is that as, as, as I was saying before, like the, the thing that I often find myself saying to developers when they're evaluating TealDraw or when I'm explaining TealDraw is like, look, you're a good developer. This is, you know, you, you could build this. Um, but you wouldn't build this. You'd build the minimal version of this in order to, to finish your application because you're not building the, the world's perfect canvas. You're building a tutoring application for, you know, K through 12 tutors. Um, and so making sure that the cursors rotate, like when you're rotating things, like it's probably not a blocking issue in terms of like delivering that experience to your users. I am trying to build a perfect canvas or a canvas that is completely worked over in terms of polish, in terms of all the little edge cases, in terms of all the, um, You know, the, the full user experience that, that we've gone in and solved all of the crazy stuff that you could probably cheat your way around. Like you might, you know, be able to punt on this or that, might just not let people rotate things, you know, in order to avoid the craziness that comes with rotation. And so now you get to kind of create that, that, that level of, of quality, not just in the, the things that you're great at of building tutoring applications or something, but also in the canvas itself should, should meet that same level of quality as the rest of your app. And that's, that's pretty compelling. And that's a good use case for, for quality. Another good use case for quality and craft is building products for high-agency users. What I mean by high-agency users, I might soapbox a little bit here, but, but go with me. Software developers are like probably the highest paid managerial staff outside of, you know, athletes. Like they're, when you think of like non-executives who are commanding like very, very high salaries, software engineers are some of those. And so they have a ton of influence. They have a ton of agency. They have a ton of like political power within an organization to say, hey, look, these are the tools that I want. My time is worth so much money that if you make me fill out a Jira ticket, I'm going to quit my job. You know, like you're wasting your own money in addition to making my life a living hell. Buy Linear. It's great. Uh, and it'll make me happy. And that's, that's very compelling because you're, you're building for Linear. Like you're building software for very high agency, high influence, uh, people within their organizations. I think where craft is less. A good idea or a strong differentiator is where you're building software for low agency or low influence people. There might be tools for customer support and I love customer support and I love every customer support person that I've worked with. Often the most interesting people at the company, certainly the nicest, but they don't have a lot of influence. They don't have a lot of like, they can't make the same demands that a software developer making a million dollars a year in comp can make. And so, you know, is that the right place to, as a software builder, like to optimize for user experience to this? If you're the people that you're building for aren't really going to be able to be making those decisions, if those, you know, it, yeah, it might not be. I mean, it kind of is sad, but it might not be the right place to strategically the right place to invest in craft.

That high agency, lower agency is really great. I love, I love your take on that. And you know, I appreciate your time here, Steve. I just want to kind of wrap up and ask you, what is the most fulfilling thing you're getting out of building TealDraw right now?

So with TealDraw, I love the fact that I get to build a team that sort of reflects what I care about. in, in, in software development and software design, uh, in, in, in approach to product and so on. And so like, you know, whenever we have a win, whenever we, we sit down and say, okay, we're gonna do something great and then we do it. Absolutely. I'm happy that, okay, this is gonna convert this many people or this is gonna bring in this much attention or this is gonna like get us this many Twitter followers or whatever. Uh, but it's also like, highly validating to that, that the way of working that I like and that I think is, is, you know, the, the right way of working for this product, like that it works and that it's not arbitrary and that these aren't like bad habits necessarily. It's just, hey, if you wanna do something that is both creative and commercially minded and super ambitious, then this is one way to do that. It's such an opportunity and such a privilege to be able to even try that and to really be able to run this startup as a somewhat of an experimentation on how software can be made.

I liked Steve Ruiz's long-distance cycling analogy that when you're spending money on the bike, you first focus on the parts your body touches first. And that's how he builds software. TL;DR had 200,000 users before you could even Log in because the drawing experience was just that good. People were bookmarking their files and they just kept coming back. I also liked his framework for when craft actually matters strategically by focusing on the power users who have the political power to say, use this tool or I'm walking, because that's where polish converts directly into revenue. When you can build for people who can demand better tools, then suddenly quality becomes one of your advantages. It's a colder take than I think most people are comfortable with, but I do think he's right. And underneath all of this is what he learned in art school that I think applies to anyone building right now. This ability to get lost and then find your way out again. To trust that if something feels interesting, there's probably a reason for it, even if you can't articulate it. That's the episode. I'll see you next time.