Check out the conversation on Apple, Spotify and YouTube.
A comprehensive guide to building AI-first companies from Gumroad’s founder. Learn how Sahil Lavingia runs a $10M ARR business with one employee, ships features from Slack to production in minutes, and is deleting 5,425 lines of CSS to enable AI speed.
Here is the transcript:
Introduction (00:00:00 – 00:02:09)
Aakash: Most founders are drowning in coordination overhead. How do you ship features faster than teams of 50? How do you run a profitable company with just one employee? Today we’re meeting with Sahil Lavingia. He is the founder and CEO of Gumroad, a $10M ARR company that he runs with one full-time employee. He pays himself $2M per year in dividends. And today he’s going to break down his three-tier AI workflow, show us live how to go from Slack to production, and explain why architecture is the new bottleneck. We’re not going to gatekeep any of the knowledge. We’re going to demo and show you the sauce. So strap in and let’s get started. Sahil, welcome to the podcast.
Sahil: Thanks for having me.
Aakash: I was telling you offscreen that I’ve been fanboying about you for a while. I once saw you in person four years ago but was too shy to come up to you. So this is a dream come true to be recording with you. What are we going to do today?
Sahil: We are going to be cooking. We’re going to be making three things, walking through how we use AI—small, medium, and large. The first thing will be how we use it to solve a really small issue that comes up in Slack where we have Devon just kind of take care of the issue. The second one is how we walk through building a feature, scoping out the PRD for an existing product of ours called Flexile. And then finally we’ll try to build something totally from scratch and see how that goes.
The Small Workflow: Slack to Production (00:02:09 – 00:07:47)
Aakash: Can you show us this first one? I was pretty mind-blown when you even just told me about this—from Slack to code.
Sahil: This is an example of how we would use something like Devon to solve a problem. We have Slack like many companies. We have an internal customer support tool that we’ve built called Helper. And we had a feature request from somebody basically adding this “assign yourself” button when something is not assigned. So if you use something like GitHub, instead of two clicks where you have to first click on assign and then click your name, it’s one click. So you save your customers one click, which is awesome.
This was reported by one of our customer support staff and she explained exactly why this is great. This is exactly like the perfect feature request—what you want and why you want it. And so I just said, “Hey Devon, solve this. Address this.” And Devon reads the Slack thread, sees the two images, and then explains its planning and keeps you up to date, and then eventually opens a pull request. Here you can read the code as you should. You should probably test it, make sure it did what you want it to do. Obviously if you have tests you should make sure the tests are up to date.
So Devon goes through and creates this and then I review it. This is a good example of something that no one had to really spend too much time thinking about, but it was solved, it was deployed. All the deployment has long been automated. So all of a sudden, this is now a feature in production for people to use and benefit from without us having to really do anything.
Aakash: That’s crazy. So the original process at a larger company that most people are living through right now—they’re going to get that request in Slack. The PM is going to take note of it. They’re going to investigate it. They’re going to see, oh, how many people is this affecting? Is this a big enough request? Then they’re going to prioritize it. Once they prioritize it, there’s going to be a request to create a PRD about this. They’ll create the PRD about it. Then engineering is going to create their engineering spec about it. Then finally it’ll get prioritized in a sprint and an engineer will actually work on it. Weeks of coordination. You guys just decide we want to do this. Devon, address it.
Sahil: Yeah. Well, you know, a big reason that companies do that is because they need buy-in from so many people, right? So the nice thing about Gumroad is it’s basically just me. It’s a dictatorship, right? So that’s kind of why we can move super fast. You don’t have to put together all this work that’s really just to get internal buy-in. It has nothing to do with actually shipping the change. The hard part is aligning all the people to kind of get behind that specific decision.
One other reason I really like AI is because I think it’s sort of quite good. It’s sort of like 99th percentile at many things. And so generally the decisions it makes are pretty good ones. And actually like things like design and code—we just kind of defer to the AI, right? And so it should come up in that PRD. Something that’s important should show up in the spec conversation itself. And if it doesn’t, then it’s not that important. AI can decide however to tackle the problem. You know, as long as it meets the criteria in the spec, it’s correct.
Aakash: But could bigger companies adopt this for features that are a little bit less contentious that don’t need buy-in? Like I feel like there’s going to be a future world where some companies are taking more of how you guys are working, maybe creating a bar for certain features, and that way shipping much faster.
Sahil: Yeah, I mean I think the way that a bigger company would probably do it—I don’t have a lot of experience working at big companies so I don’t know the mechanics of them—but basically you would just do it on a team basis, right? So you would pick a specific project. Microservice architecture is quite popular in these big companies for this reason, where people get frustrated that they have to move at the slowest pace of the large organization. And so they think that if they factor off and they just have a small API microservice, they can now all of a sudden move much faster.
It’s true to some degree, but that introduces a lot of other complexity that you then have to think about. And I think my bias is to tend towards: what’s the right approach such that one person could ship the entire product? A lot of the way that big companies move faster makes it impossible to get smaller. Their process actually is probably quite fast, but requires a number of people that you can’t—you need a PM, you need the designer, you need the engineer. The way they work, you can’t without refactoring the process get smaller. And that’s largely why these roles even exist.
The Medium Workflow: GitHub to Feature Launch (00:07:59 – 00:19:27)
Aakash: So we saw the dictatorship workflow, maybe not portable to other companies. I think this second workflow might be portable, especially with some of those microservices, those smaller teams who want to pilot it. Can you show us this workflow?
Sahil: Yeah, sure. So this is for Flexile. Flexile is open source, so anyone who visits this URL will be able to see. But we have a GitHub issue here which is basically for this feature on Flexile. Flexile is a contractor payments tool, so you can invite people, you can pay them, and then they can accept the payment, they can type in their bank account, all that kind of stuff.
And so there’s a feature we have where the admin of a company could issue a payment, right? So contractor does some work, they want to get $400, you can give them $400. You could specify what it’s for. And in our case, we’ve built equity into this. So in this case, you can choose an equity range. And then the contractor can say I want 10% or 50% or what, but they have to pick within this range. This is very complicated. It’s reduced a ton of complexity.
And so we’re basically going to simplify this and say we’re going to get rid of this. When you say I want to send someone $400, you’re done. They just get $400. If they want equity, that’s going to be specified ahead of time. It’ll just show up as a note here. You know, for example, they will receive 10% of this $400 in equity and stock options. But this way we’ll be able to delete probably a few hundred lines of code and it’ll be much simpler because you don’t have this two-three-step process.
So anyways, all of that I just put in this, which is not super helpful, right? If you’re an engineer and you’re like, “Okay, great. Sahil wants me to do this. I can guess roughly what this is going to be but I would love to know more.” And so people have questions, we have a conversation about this. This engineer asks a question, I loop somebody else in, we kind of have this discussion, debate, etc.
And then typically from here what you would do is you would create a PRD. So in the case of this, I pasted this into GPT-5 Pro, which you probably don’t need something like Pro, but it kind of comes up with this. Now a human would kind of go through this and read, edit this down. To me, this is way too long. And so often that’s why I think the PRD is dying. Like I don’t think you really need it anymore.
Because the PRD is sort of—you can think about it like this internal resource for a company. You don’t really give it to the customer. You’re just kind of using it to get these PMs and engineers and designers aligned. So if you can get everyone closer together and have more overlap in the skills, you can operate off a much leaner and tighter PRD. So this is the PRD in my case, right? Like this truly is. And so as people have questions, I would go up here and I would flesh this out.
For example, always use the equity percent that was selected by the contractor, note this in the modal, etc. So you kind of—basically what I love about this process is you learn where your PRD is lacking. And your PRD is only as dense as what can basically not be inferred naturally, right?
So for example, I could take this and go into V0 and say, you know, for Flexile build this. Build this feature. And imagine this PRD was much longer. Imagine it was like this long. You could build this. It’ll go and build this. And then you could actually see based on your PRD—what did the designer think they were supposed to be designing? What did the engineers—and if they’re wrong, if you think they took a different approach, then you go back and reread your PRD and you say, “Oh crap, I forgot to mention that like do not update, you know, whatever,” right?
So it kind of allows you to have almost like this fake conversation with the engineer and the designer such that when you actually give your PRD to the engineer and the designer, which may still exist in your company, they get a much better PRD, right? Like they’re getting a much tighter, much more accurate to what you want, what’s in your head. Because that’s sort of the problem—there’s something in your head that you’re trying to express in English and you’re failing, right? Basically there’s a lot of stuff that you wanted to have accomplished that you didn’t necessarily state.
Architecture: The New Bottleneck (00:12:14 – 00:19:27)
Aakash: And getting V0 to respect your design system—or is it fine if it’s just whatever it comes up with?
Sahil: I personally don’t care because for me V0 is like an internal tool just to get the UI/UX right. And generally the codebase—that will be tackled in the codebase step. And if you have a well-architected codebase, then you won’t have to worry about it. It’ll happen perfectly every time. If you don’t have a well-architected codebase, then you’re going to have a lot more issues.
Aakash: I don’t exactly know what that means. What is a well-architected codebase? What are the elements that they need to establish to make it that way?
Sahil: Yeah, I mean this is sort of the now most valuable skill in software engineering, which is to architect the codebase such that making incremental changes to it is really easy and intuitive. But for example, for a web application, there are several parts of the codebase. One will be the design, right? Typically the design used to be handled with CSS. So you have these massive CSS files.
So for example, I can show you in Gumroad’s case, which is also open source, so people can follow along if they want. But if you look up our CSS files, you’ll see that we have tons of CSS files that define the style of the application, right? They all live within this. So the calendar, the car, the carousel—like they’re all these things.
This is a terrible way of building stuff today because what it means is all of this code to make a single change on gumroad.com—this code will be included on every single page, right? So if your page has a progress bar on it and you change the width, the size seven instead of size five, that will change the progress bar across all of Gumroad, right? So now you have to test every single page in which a progress bar shows up, right?
So then you have to search for this specific thing, progress bar, search for it in the codebase, and then check, update each one of these places and test it to make sure. For example, here you’re overriding the width of the progress, right, and the display. So you have to test. You can kind of notice a lot of these places the width is 0.75 EM, so maybe that should be the default. But there’s no way—the default is set to size five. What is size five? I don’t know. It’s coming from somewhere else in the codebase that I have to go discover, right?
So there are all these misdirections where it’s really hard to start to build out this thing. The new way of building things—we use Tailwind. If you go to Flexile, Flexile uses Tailwind. There is no CSS files. If you search for CSS, you only have a single CSS file in the entire thing, which basically just defines the overall themes.
And this way you never—the AI never has to think about what’s the foreground color, what’s the background color, what blue do we use, what red do we use. The entire design system literally basically is here. The visual design system is here. Like the font, the color, what else is there, right? Padding. There’s not much else, right?
And so super easy to understand. Like think about how much context is here, right? It’s 181 lines of code and you can basically build stuff within Flexile. But if you wanted to understand the design system in Gumroad, all of a sudden you’re not 100 lines of code. You’re at 100 files of which each one is going to have lots of code. Like you go to one of these files, you have all of this code that you have to think about, right?
And so Tailwind—and you can have this conversation with ChatGPT, like why is Tailwind better than global CSS for shipping features. By the way, nothing to do with AI, right? And if you really want a much faster response, you could ask ChatGPT without Pro turned on. But anything that basically is good for humans is good for AI and vice versa. So Tailwind is good for shipping for humans. It’s just much more noticeable because the rate of speed increase with AI is much more, right?
So if you make this change—and we basically, this is the first step I tell everyone to do if they’re moving to start to use AI more: they need to delete their CSS.
Aakash: Oh wow.
Sahil: You’re not going to be able to make these changes. So for example, “Devon, address this,” right? Like why was this so simple and easy? Let’s see the code. The code was one file change, right? Because there are no CSS files. There’s no CSS to change, right?
So in the case, let’s say we were using CSS. Well, you have to change this file, which is the component, the equivalent of HTML. Then you have to change the CSS file, right? There would be an equivalent CSS file, right? Well, that CSS file is referenced from every single TSX file. So now you have to effectively—it’s like as if you edited 300 files, right?
So in this case, only one file. You only have to—and all the CSS changes are right here. Class name, flex, item center, gap one, all of these changes. Like you want to make a button but with this color and you want to underline it on hover and you want the text to be small—all here, you know. And then reading this as a human, I can see all the changes. There’s only one file, right? It’s infinitely simpler to work on.
So that’s one thing about architecting the codebase. And you can actually see with Gumroad, we are leaving CSS behind and we have a task open to migrate every single one of our CSS files and delete them all. So all these files will be deleted soon. And to sort of calculate that for you—let me see if I can open up this. Find the file. So yeah, I could just ask: how many lines of code are all CSS files? And see what it does. You know, thousands of lines of code, right, will be deleted. So a huge amount—like a book’s worth of content will be deleted.
Aakash: 5,425 lines of code.
Sahil: Crazy.
The Large Workflow: Zero to Production (00:19:34 – 00:35:14)
Aakash: And so the powerful thing here is you define your design system using Tailwind, and then V0 can just pick up those components and V0 will, once it gets put into your codebase, it’ll have your design system in place.
Sahil: Yeah, exactly, exactly. And it’s just an industry standard, right? So just think of the difference of like—you hire an engineer and they’re used to 2x4s, right? They understand the system. The AI knows how this stuff—you know, there’s so much training data out there about Tailwind, etc. So it’s just really easy to get started and make progress.
Aakash: Amazing workflow. So that’s the second workflow. Now let’s look at the large workflow. How does it look like end to end if we’re building from scratch?
Sahil: Yeah. What do you want to build?
Aakash: It’s a great question. Let’s build something. Let’s say we were building a competitor to Kit or something like that, like an email provider for creators. How would we get started with that?
Sahil: Yeah, so normally I would frankly start in Apple Notes. That’s like my default. Something like Google Docs, right? And you just decide what you want to build. So you want to build a Kit competitor. So this is like an email newsletter kind of?
Aakash: Exactly. Really focused on creators is the audience and really helping them be easy to send stuff that delivers.
Sahil: So this is our PRD, right? Basically. I use V0. People have their own preferences, so use whatever you want.
Aakash: So you go straight into V0, getting the front end started. Not really a step needed in between like the four lines and V0—like creating a PRD or something like that?
Sahil: Yeah. In my opinion, a lot of people, they invest in the PRD because they’re going to give it to a human, right? And they want to make sure that they don’t waste that human’s time. If you’re just giving it to an AI, like why not? And by the way, ChatGPT now supports this, right? I think so. Like I think if you turn on Canvas—I think that’s how you do it. Oh no, Canvas. I think maybe if you just say build this. So now it created a PRD. I don’t want a PRD, just a prototype.
Let’s see what GPT-5 does here. I haven’t—yeah, I’ve heard generally good things about it, so hopefully—it’s powered by Codex, which people are loving. So yeah, you can iterate on it, right? You can say, okay, I don’t really like—it’s like send test or whatever. But you basically—it forces you to reckon with what are you—what’s unique about your idea, right? Like what are you building? You’re forced to not just say, oh, it’s an email newsletter thing, but like, okay great, how does it look? What is the name? What is the core functionality that is different about your system than somebody else’s system? Things like that.
So that’s sort of—try GPT, you know. Say like, you know, make it look like Stripe built it, you know, something like that. See what it does there. And it’s all what I do. I have like several open, you know, because it takes some time. I’ll often have like three or four different windows open and just kind of run through them and just kind of juggle different ideas. And it’s almost like having an army of assistants I’m kind of riffing with, trying to come up with an interesting idea. And I just kind of hop around.
Yeah, just think about this more—like some ways we can differentiate, right? It basically makes it really easy to create good landing pages, make it look really good. But they start with a paid plan. So I think we’re going to want to start with a free plan or something like that. It’s going to be the big thing. And I guess Kit is really good at driving—like allowing you to spin up lead magnets or different introductions to your newsletter versus like a Substack where there are no lead magnets or anything. So I think that’ll be the direction we take it.
Aakash: Gotcha. Yeah, it’s kind of slow. It’s the biggest problem. Things just can take some time. And you mentioned you’ve tested out a couple different tools. What other tools have you tested out for this? Why do you end up landing mainly on V0?
Sahil: Yeah, I just like the design sensibility. We use Shadcn a lot, so it’s just kind of pretty consistent with just like the—I have this sort of millennial design aesthetic, you know, Helvetica, Apple, black and white sort of. So I think it aligns with what I generally like and so that’s kind of why I tend to use it. But you could use Lovable. People like Bolt. People like—you know, you can also use Cursor directly, or Codex. I haven’t used Codex yet. I use Claude Code.
You could say, you know, build me a Kit.com competitor, creator focus. But you notice I’m not copy-pasting the PRD. I like starting from scratch a lot because it helps me refine my own thinking as I go.
And you mentioned lead magnets, which I think is interesting because I think that gives it more of a voice. Often tools are really important. So like you’re only as good as the tools you know you have access to. So what tools are you going to use to build this, right? What technology stack? This is a lot of where the software engineering background comes in. Generally software engineers will know more about the tools that exist to build websites than a non-software engineer, right? So I might say like use Next.js and even that alone will massively change the direction of the thing.
Working with Multiple AI Tools (00:23:44 – 00:35:14)
Sahil: So yeah, so this is V0 and started with—done way more work than GPT did. They actually created a nice landing page. I’m curious what other pages—GPT is—can be quite bad. I mean, that’s why I like V0 because it’s sort of built specifically for this purpose. Don’t—you know, super minimal. I would take another shot. I don’t know where the chat—the chat goes here though. There’s some other tab with chat somewhere. But yeah, that’s kind of the process.
And so let’s see what Codex is doing. So it creates using Next.js, is creating the React app first. You know, first thing it has to do is actually just set up the app locally. This is actually my first time like live using Codex, so I’m really excited to see the results.
Aakash: Yeah, I’ve heard good things about it. It’s super popular.
Sahil: Yeah. I like Devon a lot because it’s something I can use from Slack from my phone. I use Cursor still at the end of the day for a lot of things. Like you want an IDE for certain kinds of things. I tried Claude Code but I didn’t really stick with it. So I kind of went straight to Codex.
So if we look at what V0 is up to in the background as well—are they deleting?
Yeah, it’s rebuilding this based on my new prompt. Cool. I just asked it to be super minimal. I tend to think sometimes AI does too much stuff. So yeah, it shows you—yeah, you can create like a little thing like this and embed it on your website. You know, it really focuses on your subscribe form. So you can create your subscribe form and you can embed it.
Aakash: So if we were to say we love this, I think this is differentiated, we like this front end. How do we go from front end in V0 to production-ready app?
Sahil: Yeah, I mean you would want to deploy this to Vercel would probably be the easiest thing to do. So I would just find that button wherever that button is and deploy it. In this case, I guess create a new project. Say, you know, Subscribely I guess it’s called for now.
Yeah, so it’s compiling it. It’s using Bun. Interesting. That’s cool. Bun. I guess V0 uses Bun. Did you know that V0 uses Bun? I wonder if this is how they sped up. They’ve been reporting these speed gains in Next.js. I wonder if that’s how they did it. They just switched to Bun. This is new to me.
So yeah, deployed it, I think. And now you can visit this URL. So this is production. Anyone can visit this and you’ll see this page. So you could sync this with Git. So then you can open it up in Cursor and continue working on it in an IDE context, right? You don’t have to, which generally is what you want to do at some point. This is not the right interface to build software in. It’s nice to prototype. It’s nice to chat. But most engineers are not going to want to build without being able to see the code. And Cursor, having it locally on your computer is pretty nice, right?
But you can see this is how they work, right? Like how I showed you—they have a single CSS file with these themes. So if I wanted to make it look like Flexile, right, I could literally just copy-paste our theme here. And boom, it’ll look like Flexile, right? And I can even if you want, we can try it out, see if that works, just to kind of show people we’re not full of it.
And you know, there’s chance for mistakes too. But let’s say I’m just going to copy this entire file and say AI, follow the Flexile theme with this global CSS file, right? And then it will do it. It’ll figure out what parts of that file are Flexile-specific, change those out for the right variables for this project. So you can see here—but you can see a custom color palette, signature font.
Aakash: And so you take it into Cursor, and do you use Devon in Cursor?
Sahil: No, I use Devon through Slack or through their website.
Aakash: Okay, nice.
Sahil: So normally I use Devon for small stuff and Cursor for big stuff. That’s kind of the simple binary. Yeah, but you can—you know, it talks about, oh, border radius for example, our theme indicates stuff about how round things should be and all the different colors. So yeah, here the radius, the color of our links should be blue. The design system is actually pretty small. There’s actually not that many things that define a brand, right? If you think about it—the colors, the font, the padding, the shadows, the borders.
It’s pretty cool. So this—yeah, it’ll take some time, but it’ll run through it. And then yeah, pretty interesting. Let it continue doing this thing. Very powerful. So you can see it didn’t do much because we probably already have a similar theme, but it cleaned up these things.
You know, if you want, you could—there’s another thing people can do. You could literally just take a screenshot of like, you know, flexa.com. Say, let’s say it’s not blue enough. Make it look like this as a parent company, right? You want similar branding, right? Again, state why you want something. AI can reason. So if you state why you want something, it’ll actually help it think through the right approach.
Presumably V0 is probably using some Claude model since those are the best Claude models. But they probably have some mixture of models for different tasks I guess.
Sahil: Yeah, exactly. Exactly right. They have some generally framework for—it’s not that much more than a simple model, but there’s a little bit more of planning step, executing step, wireframing. Like they have a few of those. And some models they can use a cheap, fast model. Other things they want a slow smart one.
So yeah, I mean really—I feel like these models are effectively as intelligent as I need them to be. Not that much more is necessary for me to feel like they’ve sort of replaced most kinds of software engineering. The biggest thing is, as you see, the speed, right? Like humans are faster. So if this could be instant, like if this—really I feel like that’s the core problem. I actually—it’s just slow. So things just take a lot of time.
It’s like, okay, so now everything is blue. It did a pretty good job. It looks much more like Flexile now. Still not perfect. I would still mess around with it for a while. For example, like this thing—it would be cool if this like counted down. But again, the reason I’m always doing five different things at once, right? I’m answering email. I’m answering Slack. I’m PMing something. I’m doing something on Twitter. I’m—that way, all this dead time, I’m not waiting, right? I’m going out and doing something else and coming back like five minutes later.
And the demand for these AI services is so great that it’s kind of like LA traffic. There’s just a lot of demand to use these tools because they’re very useful.
Aakash: Yeah, I found that time blocking on my calendar doesn’t work nearly as well as it used to because I need to be doing four things at once with these AI tools.
Sahil: So here’s a good example of a failed PRD. It’s doing what I asked it to do. It added a countdown. I think that’s kind of cool. But really I meant for it to be animated and specifically with a specific React library called Number Flow.
Aakash: Okay.
Sahil: So I’m going to ask it to. So that was in my head—animated using Number Flow. But I didn’t say. And a really good front-end engineer would know that I meant this. So AI is not as good as a really talented front-end person who would understand that when I say countdown, I mean a metaphorical countdown. Like something that’s—I’m not adding it just for the function. I’m adding it to get the customer excited that we are good at software engineering and good software engineers can do animation. That’s sort of what I—all the stuff I didn’t say.
And it looks like it failed because there’s some error. So we’ll ask—just have to click this Fix button. Another part of being a software engineer.
Okay, it looks like this works. So let’s run this. And I’ll say run locally and see. Let’s see what—so yeah, it created a Next.js app. But I’ll run it locally and see. Yeah, there’s some—yeah, it’s doing some animation but it’s kind of weird. Oh yeah, it’s not as good as the example. It’s not as good as the example. Why not? All you got to do is copy and paste the example. Come on.
The reason is it did not actually use that library. It did it manually. So we’re going to try one more time and we’re going to literally say this. That’s the code. The code needs this import Number Flow. So now it should get it. So you can see that what PMing is, right? It’s just being incredibly explicit with what you want. And if you are incredibly explicit with what you want, then the software engineering intern, etc., will do what you want it to do.
Yeah, this is Flexile’s growth. Pretty cool. Things are working. The way we work is starting to work. We grew 50% month over month for some reason. I don’t know. I don’t really know what we’re doing that’s working, but that’s cool.
It tried. So let me just quit Codex. Say npm ls. Where did it create—oh yeah, creator newsletter. And Per wrote there. And it created it. So I’m going to open it up and see what it did. So this is why I don’t like Codex, right? It’s like a lot of trust. You don’t know until you open it up. So this is what it did.
Aakash: Wow, that’s pretty impressive.
Sahil: I think it did the most work. It did a lot of work. And that’s why people say it’s very industrious. It does a lot more than you would expect. It iterates on itself quite a lot. So this is pretty cool. I would say it’s all in one page. Step one, step two, step three. I don’t really like the UX. It kind of has this very old school template vibe. But it’s pretty functional. I assume this will update automatically. And if it all works—presumably for Codex we could have linked it up to the codebase at the beginning and the Tailwind CSS file that Flexile or whatever—if we had an existing product, if we were doing that, could have done that.
Sahil: Yeah, exactly. All the way—the way you use Codex is you just open it in any terminal, right? So if I’m working on Flexile here, right, I just run Codex and then all of a sudden I can—all of a sudden I’m using Codex, right? Whatever I want to do.
So like for example, I have that task of like remove the figure. I can just say generically—actually let me see just for fun how—and this is a good test of how good the spec is, right? Like you can just say—in theory, just do it, right? If it’s AGI it should do it. If it’s not, then there’s something I didn’t state I need to connote.
So yeah, something like this would take days, now would take hours. So that’s a pretty significant boost in productivity.
Aakash: Love it. So I think that’s it for the demos. I think we showed everybody a really comprehensive set of three workflows. You can go straight from Slack to Devon if you’re in a dictatorship. You can talk about it more if you’re a more mobile team or a bigger team in GitHub on an issue. You don’t even need to create a full PRD. Or you can iterate on your PRD with AI and a prototyping tool. Then connect it into your design system with something like Tailwind and make it much better, much faster to reveal what are all those things inside your head that you actually wanted to create. Amazing. That’s the demo section. This is how Sahil is running his company. Now you guys got an inside look. This is how you power an AI company with AI tools.
The Gumroad Story (00:36:01 – 00:37:30)
Aakash: I want to talk a little bit about Gumroad because it’s just got to be one of the most fascinating companies out there. Tell us a little bit about how you guys are structured. You have only one employee, but you have contractors. How did those contractors get work? You pay them? What is the structure for getting work done at Gumroad?
Sahil: Yeah, we’ve been through a lot. We started out as a sort of traditional venture-backed startup in 2011 up until 2015 when we failed to raise our Series B. That’s when I sort of did our first sort of major pivot. The product stayed the same, but sort of an operational pivot. So we downsized. We went to about three or so people, got to profitable, and sort of ran the business myself for a while. Did customer support, product support, fraud, risk, customer support, fixing bugs. Not that many new feature shipments. But basically just try to kind of keep the site up and respond to customers and stuff.
Then we started growing a little bit. COVID happened. That was a big boon. Crowdfunding round. So all of a sudden we had some more cash. We started growing the team again. But this time sort of differently. Primarily contractors, hourly, part-time, remote. And we have a core team now that’s full-time. So me and Ershot and we have maybe three or four people who work like 30 hours a week or so. And then we have the bounties that we do with the open source community now.
So all of our code is open source, which means we don’t actually need that many engineers on the team because you don’t have to be on the team to work on the code, right? So in theory you need a lot less people. And that’s kind of how we work now. So it’s sort of a small team. And it’s hard. We have an office that could fit 11 people, but it’s just tough to—our bar is really high and AI is so cool and there’s so much opportunity for everybody out there that’s hard to find the right people.
Aakash: So you aimed it sounds like at one point to build a billion dollar VC-backed company. What is your current goal for Gumroad?
Sahil: I mean, very practically, very boring. But we’re trying to get to $10 million in EBITDA. It’s just nice to have a goal. Nice to have a short-term goal for the year where the team and everyone can align on what we’re trying to do and the changes we’re trying to make and the sort of order of magnitude changes we need to make to make that goal happen. Which I think we’ll get to. It’ll be tight but that’s a good goal. I think it pushes you at the very end to work a little bit harder.
Beyond that I haven’t thought about it too much. Like open sourcing everything was a goal. But to be honest, we don’t have a lot of goals because if we want to do something we just do it. There’s not a long lead time to doing stuff. So we just started doing more frequent onsites. So one week a month where we get together in person and build stuff together.
I think a lot of my focus over the next couple years will be on—now I have a kid, I have a five-month-old. So balancing the two and structuring the company and the culture is such that I can be really productive and still do stuff with a team. But then also not have it be as intense and as all-consuming as it can be sometimes. And so that’s kind of the balance that I’m trying to strike. But yeah, nothing too crazy to be honest.
I feel like for the first time in a long time, which is the nice thing about having a profitable business doing dividends, is I’m not looking at the future. I get dividends every year. So I’m actually trying to operate the business slightly better—almost as a perfectionist. Can we just perfect the current business instead of doing other stuff all the time?
So we’ll see. Flexile is fun to work on. It’s growing. Chip away at that. Fix bugs. Improve the product. I just want to work on software, make the software better, have people use it, and just be proud of the work we do. Have some cool people to do it with. So I have structure in my life. Stuff like that.
Aakash: Honestly, I think that’s the new dream though. Everybody wants what you have now. A business working towards $10 million in EBITDA. Where are you guys at so far and the progress towards that?
Sahil: Yeah, I think we’re at like seven, seven or eight million. So still work to do. Like it’s not going to be a walk in the park. But I think we’ll get there by sometime next year.
Aakash: And how many dividends have you paid yourself in the last year?
Sahil: Last year I got about $2 million bucks.
Aakash: That’s really the life, right? Living, building a profitable software business, having a five-month-old, controlling your schedule, paying yourself $2 million. I think a lot of people want to aspire to that.
Final Takeaways
This conversation with Sahil Lavingia reveals a fundamental shift in how modern companies can operate. By embracing AI-first workflows and making critical architecture decisions like migrating to Tailwind, Gumroad has achieved what seemed impossible just a few years ago: a profitable, $10M ARR business run by a single employee.
The three-tier workflow system—small (Slack to Devon), medium (GitHub to production), and large (zero to product)—provides a blueprint that other companies can adapt. The key isn’t just using AI tools; it’s architecting your systems from the ground up to enable AI speed.
As Sahil demonstrates, the future isn’t about replacing humans with AI. It’s about removing coordination overhead, making architectural decisions that enable rapid iteration, and using AI as a 99th percentile contributor that can make good decisions when given clear specifications.
For founders and product teams looking to adopt these workflows, the message is clear: start by deleting your CSS files, embrace Tailwind, work on five things simultaneously, and remember that the PRD is dying. The winners in the AI era won’t be those with the most advanced AI—they’ll be those who architect their companies to move at AI speed.
