How Do You Stay Fast?  🔗 **Source:** [How Do You Stay Fast?](https://share.snipd.com/episode/e895958e-e946-495d-93bf-4362538cb824) ## Highlights - **Fast Work Often Produces The Best Results** - Adam observes that the best creative work often happens quickly and feels effortless. - He argues that speed is a repeatable advantage, not just luck, when supported by process. Transcript: Adam Doesn't feel like we can move as fast as we used to. I remember back in the day, early Tailwind days, I could just like bang out a new feature for the framework in like 10 minutes. Or, I mean, a specific example I remember that sticks out in my mind is I was in Australia for Laracon AU. Or no, maybe this was Spain for Laracon EU, Madrid. Okay, we were in Spain, that's right. And I was with my wife and my daughter, who was two at the time. And they were in bed, and we were all kind of jet-lagged and messed up. And I just stayed up on my laptop. And in a couple of hours, just by myself, messing around, just from idea to a real package, I created the initial version of the ToeN CSS, like Forms plugin. And that just happened like in a couple hours, one night. And I feel like the best stuff always kind of happens fast like that. If I'm making an analogy to like music, you'll always hear musicians say that the best songs that they have ever written are the songs that got written in half an hour you know the songs That like almost write themselves um and there's a little bit of that magic with some of the things that you work on but if you're trying to ship fast and move fast, I don't think it's reasonable To expect or rely on magic, you know, that magic happening. So how can you make it happen consistently? Or how can you at least be quick and be fast ([Time 0:00:51](https://share.snipd.com/snip/716313e2-4c83-4947-a228-4dda08387f37)) - **Ship Fast To Reach Quality Faster** - Ship fast and iterate with customer feedback to reach quality sooner. - Prioritize frequent releases so real users reveal issues you can't predict in isolation. Transcript: Adam I don't know. Saw a uh a tweet from the CEO of ramp the other day that kind of did the rounds that really really stuck with me where he was talking about how um speed is not like the opposite of quality because I think a lot of people myself included honestly have this sort of like preconception in their head that if you just like move fast and ship fast you're just going to release like sloppy Shit and if you want to do really good stuff you have to just work on it until it's good enough to release and then put it out the door but that's starting to feel like a bit of a uh a shield or Something for moving slow uh to me because what he was talking about in this tweet which i thought made a lot of sense uh his point was basically that speed is how you get to quality and that If you have two teams where one is just focused on building the perfect thing and the other one just focused on shipping as fast as possible. The team that's shipping as fast as possible might ship the first version of a feature in a week and then customers are going to start giving them all sorts of feedback. They're going to tell them what's broken and then they're going to fix those things and respond to that feedback and have a new improved version out the next week and this cycle might Go for four or five weeks and then five or six weeks into the whole thing you have something that feels like really robust that's solving customers needs that's you know just solving The problem really well whereas the team that was focused on building the perfect thing, you know, maybe they don't ship anything for six weeks. And the thing that they shift is maybe really good in theory, but customers still don't like something about it or they misunderstood the way customers work or forgot to, you know, just Didn't anticipate this point of friction that real customers would run into that's hard to anticipate when you're the one working on it and now it's been six weeks to build that first Thing they spend another four weeks polishing up a new version that's in response to feedback and they go through that cycle three times and it's been you know 12 or 16 weeks before they Get to something that works as well as the thing that the other team got to in five or six weeks. And this makes a ([Time 0:06:02](https://share.snipd.com/snip/fc1b9064-64ed-4041-84cd-afa139689f33)) - **Musk Data Center Story Inspires Urgency** - Adam recounts an Elon Musk story of breaking into a data center to move servers quickly. - He uses it to illustrate creating urgency and being unafraid to break things to force faster fixes. Transcript: Adam Took away from the Elon Musk biography, too. Like, I think he really has this urgency, you know, built into everything he does. Like, there's this, like, classic story in there about they wanted to move some twitter servers or something and he was told it was going to take them like four months to do it and uh he Just had his pilot on his private jet like turn around and drive straight to the data center and he broke into the data center and started unplugging servers and moving them himself um To get it done faster and i think they had it all like operational in a couple of weeks or whatever but i think like the interesting thing i took away from that and i think honestly you sort Of noticed this when he took over twitter was um he's like really unafraid of uh breaking things and i think his sort of, the way he sort of sees it is things that are broken in production Get fixed faster than things that are broken in staging, which is totally true. You know, if something is out there and broken, you're going to fix it as fast as possible. And it doesn't feel like you're fixing it slower when you're fixing it in staging, but you just simply are. Because if it was in production, you would find a way to fix it faster. ([Time 0:09:06](https://share.snipd.com/snip/b534ac5a-c807-43c0-9649-13db5f6a2af9)) - **Use Incremental Releases As A Forcing Function** - Release incrementally instead of waiting for a big splash to avoid long delays. - Make public shipping an obligation that clarifies what “done” truly means. Transcript: Adam So we're working on this tone plus redesign we're doing these new kits and we kind of just made the decision yesterday because it feels like we're behind and it feels like we're not going To get this thing done by the end of the year to not wait until all three or four of these new kits are built and the new like website experience is designed to ship something so we set a goal To finish and ship this first kit by the end of the week and we've had the goal of finishing it by the end of the week for a while but not the goal of shipping it so our plan now is just sort of Like release it as if it were a template in Tailwind Plus in its current form. It's going to be a much deeper and more feature-rich template than the other templates that are in there. But it's going to live in that sort of harness, you know, in this current version of Tailwind Plus. And I'm trying to think, like, why i didn't want to do that in the first place or what i think the risks are and also like if that even is the right way to move faster or if it even solves the Problem of moving faster um I think originally we wanted to just have a big splashy launch, you know, whereas like here's a new site, here's new products inside of it. It's really great. Get people excited. But, and then I guess the fear is if we just release the kit on its own, well now when we finally release the redesign of the site, it doesn't have anything new. It's just a different experience. And is that exciting the same way? Also like if the the kit is released in its current form as part of the existing 10 plus sort of package where we aren't able to sort of break out all the components and and show you some of The interesting things that we've made possible um does it not seem like as cool of a product as it would have if we waited to release it as part of the new experience and i think um i don't Know the more i think about it or when i talk about it out loud it just sounds just sounds stupid to wait and bundle all that stuff together um like this doesn't seem like there's any benefit It feels much more beneficial to me to just get this first thing out Because then it's in production, right? And again, there's such a big difference between calling something done internally and calling something done publicly. It's easy to feel like something's done internally. ([Time 0:10:46](https://share.snipd.com/snip/571aabd6-0d9b-468e-946a-8679d23773be)) - **Marketing Experimental Releases Matters** - Public experimental releases create urgency and attract feedback if marketed openly. - Silence around test releases means few users will try them, delaying meaningful feedback. Transcript: Adam It's easy to feel like something's done internally. There will actually be still like some loose ends or stuff that's not finished that you kind of like discount in terms of effort almost slipped again i see out here whereas like if you Want to release it it's like very clarifying like what actually needs to be done versus versus not done so i'm hoping that being more incremental with shipping this stuff um will help Us feel like we're moving faster but i guess the other question is like why not go even more incremental and i think that's where, um, the fear of embarrassment, I guess, really starts To show up because, uh, you know, what if we just had to release this kit today, you know, instead of at the end of the week, um, it would be, it would feel quite incomplete, but is that the Fastest way to make it feel complete is by putting it out there incomplete and just like feeling the pressure of that sort of embarrassment so that it forces us to move faster? I don't know. Like, I'm so uncomfortable with that idea that maybe it means it's the right thing to do that's the sort of thing that i'm wondering in my head right now i think a lot of this too is like uh In open source and i mean this might be just an excuse too but in open source it really does feel like you can't operate this way because if you put something out and you need to change it You have to tag a new major version of the framework you know and uh people value stability so you really really feels like you have to get things right before you put them out there and Tag them and you can do things like um put experimental features in or mark things as like unstable so people can experiment with them and stuff like that. And I do think this has some value, but my experience is that nobody tests this stuff. We've had like versions of Tailwind where like version four was basically out and usable for like six months or something before it actually came out and we just basically got no feedback On it because there's like 11 people using it and then as soon as you put it into the stable channel and make it the main branch you get all the feedback because everyone's using it. So even if you put something out there early in open source and let people test it, they just don't. So yeah, I don't know. I guess like open source has conditioned me to be sort of afraid of releasing things that I need to change a little bit. But maybe that's an excuse too because I feel like Next.js actually does a pretty good job with this stuff and people do seem to use like the experimental features Next pretty early I Don't know if they just maybe do a better job marketing it and maybe maybe that's actually a big part of it. Because for us, I feel like when I'm putting stuff out there for people to test, we're really quiet about it. And I think the next team is not. They'll write a blog post about an experimental feature and make it seem like a release. But sort of call it experimental to give themselves the flexibility to fix things and make breaking changes if they have to based on the feedback they get. And maybe that's the right way to do it. Because yeah, now it's like out there, and that puts that pressure on you. But it can also put you in a situation where, uh, the, even if something becomes high quality over time, people still sort of start to think of you as people who move a little too like fast And loose and break things and ship things that don't fully work. And, um, that's part of your brand, you know. And I really value having like a brand that's associated with quality and stability. So it's, it's, I don't know, it's tough to, to reconcile and figure out what, what we could be doing differently that sort of achieves everything we need to achieve. I think another company who does a pretty good job of maintaining a brand of quality, but also moving fast, is Linear. So maybe I need to study what they're doing a bit as well. Like one thing we've talked about a lot at our company for a long time that I was really inspired by Linear was they have this like change log. And I don't think they quite update it every week. But earlier on, it used to be like every week where they just sort of had this thing in their culture that's like okay we need to post once a week or once every two weeks a big list of all the Ways that our product got better and i love that as sort of like a forcing function for getting stuff done or ([Time 0:13:40](https://share.snipd.com/snip/83fd7812-77bb-47cc-a6ae-252094ea592f)) - **Ship Weekly Changelogs To Maintain Momentum** - Publish regular changelogs as a cultural forcing function to ship consistently. - Use a central company changelog to reflect steady cross-product progress. Transcript: Adam A bit as well. Like one thing we've talked about a lot at our company for a long time that I was really inspired by Linear was they have this like change log. And I don't think they quite update it every week. But earlier on, it used to be like every week where they just sort of had this thing in their culture that's like okay we need to post once a week or once every two weeks a big list of all the Ways that our product got better and i love that as sort of like a forcing function for getting stuff done or finding ways to make things smaller or finding ways to ship things more incrementally Or whatever just because it's like we're putting out this post they better have stuff in it or we're all going to feel bad you know and i've wanted to introduce sort of like a company-wide Public change log at our company for a long time and we've just like never quite prioritized it or gotten to it but maybe we should prioritize that like right now there's obviously the Tailwind css changelog the headless ui changelog tailwind plus has its own changelog but because they're all so scattered and separated it doesn't really feel like uh it doesn't feel The same as having ([Time 0:18:44](https://share.snipd.com/snip/1ca8793b-0a50-4904-a9b2-bdec2154df62)) - **Carousel Blocker Slowed Kit Progress** - Adam describes building a testimonial carousel and hitting a blocker because HTML support lacks reusable components. - He felt stalled having to build a generic carousel for the HTML baseline instead of using React tooling. Transcript: Adam And we want to do that because we want to have some sort of lowest common denominator that anyone can build from regardless of the tools that they use. And HTML seems like the obvious choice. And we built like the tailwind plus elements library, which is kind of like Headless UI with web components. And that works anywhere. It even works like in React and Vue projects, which is kind of neat. So we've been working on this new starter kit, this marketing site kit that I've been working on with Jonathan. And we're actually building the React version with 101 plus elements instead of like how the UI or something specifically because we just want to use like the same technology for the HTML version and the React version, if we can, because it just makes it easier. But it also feels a little bit weird, because you're building something in React, it feels a little weird to use a web components thing, when you could just use a React library. I don't know where I'm going with this, other than we were working on a testimonial component the other day, and it's like a carousel. So you can imagine it supports multiple testimonials that it sort of like iterates over and you can click a little button at the bottom to toggle between them and stuff and we got this Design from Steve and we started thinking about building it and we kind of quickly realized that like we have no way to build this that will work in the HTML version with the tools that We have. Because we don't have like a tailwind plus elements component that could sort of be used for this. Like the closest thing would be like a tabs component. But i don't know how we can like animate between the tabs or anything like that because it's not really built to support that stuff and of course like we could build a carousel component Into elements and that would be cool like if i could wave a magic wand i would love for that to exist but i couldn't help but feel like fuck me like I just trying to get this fucking kit done And now I have to take I have to hit pause on the kit and spend like three weeks building this goddamn carousel component for 10 one plus elements just so I can build this one component like No wonder it feels like we're moving so fucking slow um so that kind of like made me pissed off at the html version of this product because if we were just supporting react there's a million Carousels we could use you know we could use like motion which has great support for building those types of experiences and it would be really nice and delightful and battle-tested And bulletproof. But instead, I feel like we have to reinvent the wheel just because we want to support this HTML version. And the goal of the HTML version is that if someone's using Svelte or someone's using Rails or whatever, that they can chop that up and use it in their project and it'll work fine. And that seems like a good idea but i also can't help but feel like the lowest building for the lowest common denominator is almost like building for no one because there's no such thing As like an html version of a ui kit like you can't componentize things. You know, you can't design APIs because it's just static HTML. How do I reuse a button? You know, you copy and paste it and have two copies of it. That doesn't feel like nice compared to something like React or Vue or anything where literally anything, right? Every templating language in the world supports reusing chunks of HTML, but HTML on its own does not support reusing chunks of HTML. So kind of like a realization that me and Jonathan had was that it's actually easier for someone to port uh our react version to view than it is to just create their own view version on top Of the html and that makes sense right because there's so much more information in the react version the react version uh shows you what we think the apis should be and how things should Be broken up and stuff like that, where all that gets lost in sort of the flattened HTML version. So it got us wondering, like, should we even build this HTML version? Is this HTML version actually useful to basically nobody? Because we're trying to build something that's useful to everybody but by doing ([Time 0:21:06](https://share.snipd.com/snip/a9b48d78-a6c2-4b88-8ee5-248df10ce8c0)) - **Lowest Common Denominator HTML Often Fails** - Building a lowest-common-denominator HTML version flattens API intent and often serves no one well. - Framework-specific versions carry richer API signals and are easier for others to port. Transcript: Adam Of a ui kit like you can't componentize things. You know, you can't design APIs because it's just static HTML. How do I reuse a button? You know, you copy and paste it and have two copies of it. That doesn't feel like nice compared to something like React or Vue or anything where literally anything, right? Every templating language in the world supports reusing chunks of HTML, but HTML on its own does not support reusing chunks of HTML. So kind of like a realization that me and Jonathan had was that it's actually easier for someone to port uh our react version to view than it is to just create their own view version on top Of the html and that makes sense right because there's so much more information in the react version the react version uh shows you what we think the apis should be and how things should Be broken up and stuff like that, where all that gets lost in sort of the flattened HTML version. So it got us wondering, like, should we even build this HTML version? Is this HTML version actually useful to basically nobody? Because we're trying to build something that's useful to everybody but by doing ([Time 0:24:42](https://share.snipd.com/snip/769cba8c-cacf-47b0-a0ba-cd899acd2978)) - **Release React First And Let Demand Drive Ports** - Prioritize shipping the React kit first and gauge demand for an HTML version. - Let public demand create urgency for ports instead of speculatively building them. Transcript: Adam HTML version. So it got us wondering, like, should we even build this HTML version? Is this HTML version actually useful to basically nobody? Because we're trying to build something that's useful to everybody but by doing so it's not like specific enough to be useful to anybody it makes me think of this uh story that like i think Seth godin talked about once in a book or a podcast or something uh if they get this i think it's like the origin of like the adjustable airline pilot seat and uh they were first designing Seats for pilots and airplanes I guess they would I guess what they did is they sort of took measurements of everybody and tried to figure out sort of like what's the range of heights and Leg lengths and whatever of all these pilots and then they kind of just built a seat that felt like it would fit the average pilot you know and um in practice it turns out it was like not comfortable For any pilot because uh even though the seat reflected like the averages of all these measurements no one pilot actually had those measurements themselves so this is when they sort Of like invented the adjustable seat and people could make adjustments to it and make it fit them properly and i kind of feel like that's what we're doing with the html stuff it's you're Trying to make something it's like okay well what's the one thing that everyone understands that everyone can use but it turns out like even though that's the thing everyone has a shared Understanding of not a single one of these people build websites with just html because it's an insane way to build websites because you can't reuse anything so you build this whole Thing and it's actually like useless because it's not what anybody needs you know in theory it sounds like it'd be useful to everybody but a svelte developer doesn't want html they want Svelte view developer doesn't want html they want view so i think for this back to the topic of speed i think what we've decided is not to release the html version of this yet and just release The react version even if we think the html version might be valuable and kind of just put it out there and just react and see what the market says you know do people complain do people beg For an html version uh do people get pissed off at us and tweet horrible things about us creating that sort of pressure and urgency to get us to do the html version And maybe that's the way To go. I also think like, ([Time 0:25:50](https://share.snipd.com/snip/95edee2e-4422-460b-bf00-ddc001dabd70)) - **AI Lowers The Cost Of Framework Ports** - LLMs may reduce porting cost, making framework ports feasible after a single authoritative implementation. - AI could automate translations so one well-built version becomes the source of truth. Transcript: Adam That sort of pressure and urgency to get us to do the html version And maybe that's the way to go. I also think like, with LLMs now, I mean, one of the reasons we only ever, one of the reasons we sort of like resisted supporting tons of different frameworks in Tailwind Plus in the past Is because of the horrible maintenance burden of doing it and also just like having to understand how all these frameworks work and whatever but um now with llms i feel like we can really Automate a lot of the porting across frameworks or at least make it so fast to do that um that it doesn't really feel like a huge problem like it did before so i think that's something else We're interested in experimenting with instead of building like an html version what if we just use ai to help us port the react version to svelte or to view or whatever because that version Is going to be way more useful to the people who use those tools than the html version and maybe that's easy now maybe that's something that's changed so i don't know that's that's where I'm at trying to figure this stuff out trying to figure out how it can feel like we're shipping faster without looking like we're putting out shitty half-assed half-baked things and Then fixing them in public where we've already spoiled that chance to make that good first impression i'd love to sort of crack that um yeah i don't know i see a lot of people out there that I feel like are doing an amazing job at moving fast and i'm trying to figure out what what I can learn from what they're doing differently than what we're doing. Matt Perry who works on motion like formerly framer motion is just insane at the velocity that he puts things out and the perceived quality too like he he's like working entirely by himself On motion and motion plus which is like the commercial side of it and it just feels like every couple days he's launched like a brand new thing um like he's working on like a marketplace Or i don't know he redesigned the whole like onboarding experience and i don't know where he's finding the time for all this stuff because it's just him he's got a baby at home. And yeah, ([Time 0:28:40](https://share.snipd.com/snip/acabc838-394f-4444-83c7-1a7663c3c2a4)) - **Solo Ownership Boosts Velocity** - Solo builders often ship faster because ownership creates urgency and clarity. - Team size brings collaboration benefits but can dilute the immediacy to finish tasks quickly. Transcript: Adam Than what we're doing. Matt Perry who works on motion like formerly framer motion is just insane at the velocity that he puts things out and the perceived quality too like he he's like working entirely by himself On motion and motion plus which is like the commercial side of it and it just feels like every couple days he's launched like a brand new thing um like he's working on like a marketplace Or i don't know he redesigned the whole like onboarding experience and i don't know where he's finding the time for all this stuff because it's just him he's got a baby at home. And yeah, I don't know. I feel like there's something about like, I feel like Caleb Porzio is like this too. Like sometimes I'm jealous of people who are working just entirely by themselves. Because there's something about working entirely by yourself that makes it clear that this isn't going to get done unless you do it and it just gives you this like sense of control and Ownership that maybe it does help you move fast in some way but obviously there's a limit to it and I love having a team another team that I think is doing a really good job is the AMP code Team which is like spun out of sourcecraft they're building like a CLI agent and it's just the amount of stuff that they change in that thing and the speed at which they pivot and iterate On that thing is wild like it went from being a VS code extension to a CLI introducing a free ad-based plan that seemed like it happened in like a week. I don't know, just wild. Anyways, ([Time 0:30:28](https://share.snipd.com/snip/ac4c582a-734b-4c6a-9da6-0fe63ee9b6f7))