No Figma. No Jira. No docs. How Gusto built a new product line with Claude Code | Eddie Kim (CTO)

0:00We had no meetings. We had no tech specs. We had no figmas. We had no JIRA board where we tracked stories or tracked work. We had nothing. We used Cloudflare worker for the actual agent loop and Vercel AI SDK. That's it.

0:14Eddie Kim:People get really intimidated by the idea of building an agent. And I'm like, literally, it's an agent SDK running somewhere in the cloud. And if you use AI SDK, you get to switch your model. That's it. It can look up files. It can have tools. It's really not that scary and complicated. Co-founder was primarily built by five folks over the course of 10 weeks from initial idea, zero code to a tier one launch at Gusto. How did you all make those precious decisions that only genius product managers can make about in or out of scope? Will this matter? We would build features and we just have a discussion.

0:50Like, does this make sense to have or not? If it is, then it would get code reviewed right then and there. And if not, we would just delete it.

0:56Eddie Kim:I call this the trashcan method of software engineering right now, where you can actually trash all the code, start like a slash V2 branch and rebuild it from scratch. And it's totally reasonable to do because the cost of the code is so low. Welcome back to How I AI. I'm Claire Vo, product leader and AI obsessive here on a mission to help you build better with these new tools. Today, I have Eddie Kim, CTO and co-founder of Gusto, and he's going to show us how he, three engineers and one designer completely rebuilt their app in just 10 weeks. This is not a small company and yet they're shipping like they're a startup.

1:34Eddie Kim:Let's get to it. This episode is brought to you by Magic Patterns. Today's engineers use cursor and cloud code to shift features in hours that used to take weeks. If you're a designer or PM, you've probably felt a shift too. The pressure to move faster, validate sooner, and keep up with a team that's operating at a completely different speed. You've already tried AI prototyping tools to close that gap, but if your prototypes don't look like your actual product, it doesn't matter how fast you can build. You still end up redrawing it by hand. Magic Patterns takes your product team from idea to production and works from your real design system.

2:12Eddie Kim:When you build a prototype, what you get back actually looks like your product. You'll validate faster, get alignment sooner, and when it's time to build, engineers can connect your prototype to cursor or cloud code with the Magic Patterns MCP to pick up where you left off. Your eng team has their AI advantage. Make Magic Patterns yours. Try it today at magicpatterns.com slash howiai. Eddie, thank you for joining How I AI. I'm so excited you reached out to chat because one of my favorite themes that I'm seeing right now is CEOs, CTOs, founders, executives, getting back to building product. And you're here to tell us how you built some product with the team, both very fast and in a completely different way.

3:03Yes, thanks for having me. And great to connect again.

3:05Eddie Kim:Yeah. So tell us the story of co-founder and why you think this is, you know, given all your experience, you know, running this company, being a leader, being a builder, why this is so different than what you've seen before? So first of all, the product is really different from anything that we've built before. But what I'm actually really excited is kind of more of how we built this and how we can take the learnings that we had in building co-founders, the quality and the speed in which we built this and apply this to, you know, the rest of our R &D organization here at Gustav, which, you know, we have over a thousand people.

3:41And so I think we're just, you know, I feel like I just discovered on something like really incredible. And I just want to like kind of figure out how do we spread the word to not just our company, but to any kind of engineering design or product management discipline person.

3:57Eddie Kim:And so you say you have about a thousand people in your R &D organization, but remind me, how many people did it take to build this product? Gusto co-founder was primarily built by five folks, myself, three engineers, I count myself as an engineer, so four engineers and one designer. So we had one designer and four engineers and we built it over the course of 10 weeks from initial idea, zero code, to 10 weeks shipping it to a tier one launch at Gusto. It's got to feel so much, so fun. I don't know if you're like me. I spent the past couple of years pre-AI spending so much of my time like prioritizing and planning out quarters and saying, can this come in Q1 or is this going to be a next fiscal year thing?

4:47Eddie Kim:And now where you can take, you know, peel off less than half a dozen folks and ship a real product line completely net new in less than a quarter. It's pretty amazing. It is incredible. And the origin of this was not on it wasn't on any roadmap. It was not anything that we really thought about. It kind of just came about because I was actually on vacation in February and I was flying back from Madrid. my flight had a layover in London and my the mid the flight from Madrid to London was delayed and I just barely missed my flight from London to San Francisco and I had this like five hour layover now because I missed the flight and they had to book me on the next flight and I was kind of pissed about it because I was so close and so I was like okay now I have like five hours to like waste i'm gonna get home super late in san francisco what do i do and i had been like kind of playing around with cloud code i was probably one of those like tech leaders that you sometimes hear about that like vibe code something over a weekend and then comes to their engineering team is like look i built this whole thing why can't you do it yourself you know like and then just kind of like pisses people off because you know first of all that was like completely vibe coded.

6:09It's not production ready. But that was my start into it. I started using cloud code a lot more first to prototype things and just kind of like, you know, materialize random ideas that I would have. And so in this like five hour layover, I just took out my computer and started cloud coding this idea that had been percolating in the back of my mind and just seeing how far I can get with it. And by the time I had actually landed in San Francisco, I had this like prototype of what but ultimately became Gusto co-founder. And I just took it to a few engineers that I talked to regularly, our senior engineers.

6:47And I talked to Katie Kavalchen, our designer. And we just started like riffing on the idea a little bit. The ultimate materialization of Gusto co-founder is a little bit different from that prototype that I had made. But that was really the origin of this all. And 10 weeks after that, we shipped this thing.

7:06Eddie Kim:So what I love about this story, I'm going to take a little detour because I've heard this over and over again from friends is, you know what I think companies need to give just a little bit more time off parental leave and like long flights. That is where I have heard the vibe coding magic happens over and over again. Like I was on vacation, but I clawed something awesome. Or I was on parental leave and I've got like a baby in one arm and like codex in the other. And I've shipped something. I just think it's going to trickle down into like maker schedules a little bit more where if you can give people just a block of time where they're not in meetings, we can move product forward a lot more meaningfully.

7:50Eddie Kim:So that's a little a little hypothesis that I have about how some of our work might need to shift. I totally agree. Like now after going through this experience, I mean, I kind of want to take more vacation, honestly, because like I actually I actually went to my wife. We should take another vacation because like this huge thing came out of the last vacation that that that we took. And so maybe like another thing will come out of it. So let's go. Like, let's figure out where to go. And then, you know, if I have a five hour layover, I'm actually going to be really, really happy about that. Okay, this is how every CEO or executive can land the AI adoption pitch.

8:26Eddie Kim:It's like, look, if you go on vacation and Vibecode something awesome, we're happy to give you more. Well, let's go back to how you built this. So you were on a layover. You had this idea. It was kind of like percolating in the back of your mind. You built a prototype. You brought it back to this like council. I call them a council of elders, like this council of product builders or engineers just saying like, what would it take? Like, tell me, though, how you how those 10 weeks actually happened and maybe show us some of the process and some of the artifacts along the way that were a little bit different.

8:58Yeah, I mean, there was no like official council. It was like just senior engineers that I regularly like I see that I regularly talk to. And, you know, I recorded a loom of this thing and I just started sharing it around. And these are the folks that kind of like engaged a little bit more in the conversation. Like, what about that? What about that? That's pretty cool. And then so we have at our company this thing called Anchor Week, which happens quarterly. We all kind of the senior leaders and senior ICs across the company, they meet in one of our offices. This particular one was in March in Denver, Colorado, in our office up there.

9:32And so we just reserved a room that Thursday. I think it was like March 20th or something like that. And we just started whiteboarding with this group of five that had expressed some interest in this. We just whiteboarded what this would potentially look like. And it was just literally a page of the Gustav Co-Founder app. And we just got to building. The crazy thing is this was more defined. Our build process was more defined by what we didn't do versus what we did. we actually just zeroed everything out we had no meetings we had no tech specs we had no figmas we had no jira board where we track stories or tracked work we had no stand-ups no retros we had nothing the only thing we decided to keep was a 24 7 perma zoom which is basically a zoom room that we just keep because everybody's remote on in this particular group and we just had this zoom room that's going 24 7 and some people like like to honestly stay in there all day and just like do their work they just kind of like sit there quietly um and some people will like kind of pop in and out when they need something that was the only structured thing that we had was this zoom it was like literally just zoom a lot of cloud code tokens and some like really passionate people about turning this thing into reality.

11:03And that whiteboard, which I took a photo of, was like literally the only documentation that we ever produced in this whole 10-week process. And I can't tell you how many times I loved, as people like caught wind of this thing getting built, they were like, oh, can you send some documentation on how this works? And I love just saying, we don't have any documentation.

11:21Eddie Kim:Okay, so this is the whiteboard. And just for folks that are not listening, it's a Scribble wireframe that says chat. It's a chart. It's a thing that says task name. And then like a couple of components on the side that are not very well specced out. And what you're telling me as CTO is we built the entire product basically off this cloud code in a permazume. Yeah, totally. And if you look at, obviously things have evolved a bit, but if you look at sort of the core primitives and core functionality of Gusto Co-Founder, it's largely the same. They kind of like change the names of things, but one of the main things in Gusto Co-Founder is what we call now an automation.

12:07And it's basically you just create these automations that like run these workflows for you. That's what you see here on this whiteboard called tasks, right? So it's like tasks have task runs. Um, and that, that's exactly what we have in co-founder today. Um, we have assets. So, so tasks runs can produce these, um, charts or documents or markdown files. We call those in this whiteboard here assets, but eventually those got, got, got renamed to artifacts. Um, and then you obviously have chats, you have like suggested tasks. So like, basically this, like, if you look at co-founder today, it is like the, the actual like materialization of what you have on this whiteboard.

12:46Looking back on it, I'm actually kind of surprised right now how close we stuck to this.

12:51Eddie Kim:So I have to ask you a couple of tactical questions about how you pulled this off, because that's what people listening are going to want to know. So my first observation is you said you had four engineers and a designer. I don't hear a product manager in there. So how did you all make, you know, those precious decisions that only genius product managers can make about in or out of scope? Will this matter? I mean, this sort of feels like the thing where you just had conviction and knew you needed to build it. But, you know, in this world where there was no actual titled product manager on the team, how did you approach product decisions across this team of five?

13:28Yeah, I would say everybody was kind of a product manager. We would build features and we would go in that perma zoom and sort of share it with each other. and we just have a discussion. Like, does this make sense to have or not? If it is, then like it would get code reviewed right then and there. And if not, like we would just delete it. And normally that would be really, really hard to do because like it takes so long to build something. But these days with Cloud Code, we literally like write a feature. We submit, we open a pull request and this is not a draft pull request. This is actually a pull request that is ready for a human code review and we discuss it we discuss if that's the thing that we want to have a functionality that we want to have um and we're okay with deleting that pull request if if the answer is no right you have a perfectly good pull request that was written that's like ready for human review it's not slot you actually like spend time to like you know make sure this code works and is written really well and then you just close it sometimes that was like the that was like how we figured out what decided what goes in and what doesn't go into this feature like the cost to write code is now so low that you can actually uh build uh products in in this way and whereas i think you couldn't

14:48Eddie Kim:do that you know six months ago yeah i call this the trash can method of software engineering right now where you build code and you're like actually literally okay with throwing it in the trash and I see two models of this one is exactly what you say like a PR and maybe a preview branch to even validate is this the thing we want to build and if the answer is no you just close the PR the other version of this that I do quite frequently is let's say we ship this v1 in 10 weeks customers start to use it and then we actually have a sense of what the product shape and architecture should be like it's very cheap to just build again from zero you don't even have to build on top of what you've built you can actually trash all the code start like a slash v2 branch and rebuild it from scratch and it's totally reasonable to do because of the cost the cost of the code just is is so low yeah i have a funny story about that because um this prototype that i brought to the team um i was you know i was pretty pretty happy with it like and when we decided in that whiteboarding session to actually go ahead and build this.

15:58My assumption was that we're going to continue to build on my prototype. And so one of the engineers brought up, hey, what do you think about building this in TypeScript and using a Cloudflare worker and kind of like making the actual agent sort of a stateless thing that sits in its own repo? And I was like, I really didn't want to do it. I felt like this is my code, like it was good code. and here they were suggesting to start from scratch and ultimately like i i you know i trusted them so i we agreed to it we deleted my code and then we started from from scratch on that day um in hindsight that was like absolutely the best decision and now but i think back then i had a lot of discomfort with that because like i had invested you know um that was my code i like i don't like you don't like to delete perfectly good code like throwing something some good food in the trash uh but now like i'm totally used to it right it's it's there's no like sense of loss

16:51Eddie Kim:when that happens anymore it's it's totally it is just totally wild to me how how frequently i find myself writing lines and lines of code that ultimately are are great and never make it either because they don't hit my product bar or they just aren't technically how we want to implement. And then how often I'm just like taught like major red diffs all the time to just re-architect stuff. I do want to ask you a quick question about architecture. Tell us a little bit about CoFounder and kind of some of the primitives behind the scene. I heard you say Cloudflare workers. People are actually pretty interested in how to technically build agentic products.

17:33Eddie Kim:And so I'm curious kind of what stack you all landed on and why and how you how you chose that architecture? Our stack is surprisingly simple. We build on, we use Cloudflare Worker for the actual agent loop and Vercel AI SDK. That's it. We don't have any other harness on top of that. Everything else was built in-house. You know, in the past, I would have thought about how to use, you know, some third-party tool for memory or planning or things like that. And it's really just, you know, memory to us is a tool that writes to a database column called memory. And that's simple, right? Everything is just like all the harnesses and things that we used to build like to as complex like AI agent loop stack, I think is no longer needed.

18:26It was literally just Cloudflare worker and Vercel.

18:32Eddie Kim:I love it. That's very similar to my stack at ChatPurity. So it's good to hear that, you know, people get really intimidated by the idea of building an agent. And I'm like, literally, it's an agent SDK running somewhere in the cloud. And if you use AI SDK, you switch your model. That's it. Like, it can look up files. It can have tools. It's really not that scary and complicated. Yeah. I was like blown away because it was my first time using it that there's not even a loop. There's not a while loop somewhere, right? It's just like it's called stream. And it takes care of the loop for you. It's crazy.

19:10Eddie Kim:Yeah. Well, I have another question technically on how you ran this because PR as like the PRD is almost what I'm hearing, which is PR is the proposal of what to build, how it gets built, the solution. You look at it in code. And so you've almost compressed that loop. were you merging those into your production app and putting them behind a feature flag and just is that how you were technically managing this development process yeah exactly so i mean that that is one of the benefits of like kind of a zero to one type thing you may not be able to do that in all instances but we had essentially a hidden page in our web app and we would land stuff into that hidden page it would be on production and then we would sort of like chip away at it like I think the analogy we use a lot was like we started with a block of marble and we're just slowly kind of like chipping at this thing and forming it into like a piece of art over time.

20:05And we're doing that in production in place. So one of the really cool things that we did, which I would highly recommend, is Katie, our designer, she actually started shipping to production like a faked experience, essentially. So it had like the UI, the thing that we whiteboarded. But if you go in and like, you know, put in some text into the text field and hit submit, it would just give you the same response like every single time. Right. It's not actually going to any kind of agent loop. It's not hitting any kind of database. The pure front end. It's kind of like what you would maybe build as a first pass on lovable or something like that.

20:40And that actually got shipped to production behind this feature flag. And then in parallel, the engineers would start to build up the data models. uh they build the agent loop and they would start to connect this to the faked front end experience and the front end would stay the same but the canned like responses would get slowly and in place not even better like they would actually be like real right and so you would see this thing kind of like morph from like um a literal prototype that you wouldn't normally have thrown away because like it's just for demonstration purpose but it would actually turn we would like like literally breathe life into this thing over time and that's kind of how we how we built this at the same time we would have engineers like build features and they would you know have to do some front end stuff they would they would ship the design for this right and the functionality on the back end would work really well but then you know the front end probably could use some improvement there and we would ship that too right and then and then katie the designer would then go in and sort of like, you know, make the experience a lot better on the front end.

21:48And so that was another example of like just shipping something into production and then like continuing to chip away at it to make it better over time. So if you look at it at any given time, there was always something wrong with it, like in production. But then over time, like it turned into like this really nice thing.

22:04Eddie Kim:And tell me a little bit more about Katie. We might have her on the podcast. But Katie, the designer, is shipping stuff into production. Her code is the skeleton on which a lot of this functionality is being built. Tell me how, you know, was she technical? Is she technical? Was she a software engineer? How did she come to shipping code? Like what blew your mind about her role in this team? What blew my mind was that she turned into this incredible engineer. And I was just looking at our PR stats, which we use a tool called DX for it. she across our entire R &D org, she is in the 94th percentile of true throughput, which is a measure of like how many PRs you're landing into production.

22:54And that includes every single engineer, like classically trained software engineer in the company, right? She's out of 20, she's a top, right? Which is kind of insane. And it's really good code. Like I asked her, like how, how, what is special about you and how do we get more of this, like across, you know, design and product management? And her answer was basically twofold. One is that she, she's not an engineer. She's not a software developer, but she feels like she was a little bit more like technically curious than, than most designers. So just kind of has a little bit of that more technical bent.

23:28And then most importantly is that she had a team of like three or four engineers, particularly on this team that was willing to actually you know review her code like give her feedback um sure like how to prompt Claude a little bit better and like also how to judge um that taste of like what is actually good code that is producing and what is not we took the time to kind of like you know uh pair pair with her right whereas I think a lot of engineers what I hear them say is like well it just slows us down and like designers should just focus on uh producing Figma so that we can like really focus on turning that into real products.

24:05And yeah, that's true in the short term. But like now I think once you make that investment, you have a support event, a software developer around her or any designer. I think dividends pay off really, really quickly.

24:17Eddie Kim:This makes my heart grow 10 sizes. As someone who folks don't know, I did not get a software engineering degree. And yet I believe I can cook. And I've been coding for over 20 years. I've run very large engineering organizations. And a lot of that was early in my career. Folks, shout out to like Dave and Yeland and Jeremy, like were willing to sit with me and pair with me and answer questions and tolerate where my ambition outstripped my technical ability. Now, you know, even with these AI tools, you sort of have that very patient pair programmer next to you. But I do think culturally, it's very, very important for software engineering teams to extend that mentorship and guidance and feedback loop to their non-engineering partners.

25:09Eddie Kim:And this is a stress test I give to a lot of teams because I hear a lot of teams being really overwhelmed by code review and being really overwhelmed by like what maybe they'll call like slot PRs from non-technical folks. and I just say like on average is your engineering team's PRs getting faster review than your non-engineering team's PRs and like across the board people are like yeah of course they are I'm like that is an anti-pattern you need to prioritize reviewing these non-engineering PRs just as high as you do your engineering ones because you can get feedback you can create systems that improve code quality a lot of those PRs are actually really good ideas and so I do think there's this cultural aspect to it that I'm really pleased to hear you've unhooked because I think it's going to pay dividends over the long term.