Coding with Cursor: Session 3

What should we build or do? We could look at all these things that people have reported. I was thinking we could start with adding the balance back into the dashboard. People wanted that badly.

Do you want to put it back where it came from or on the analytics page?

I think we should put it back on home. We hid some information from the payouts page, which we used to call the balance page. We removed 10 things. People complained about one of them being gone. The good news is we won't have to bring most of it back, but the people wanted a balance section. You can see your next payout on Gumroad, but you cannot see the money you've started collecting that will get paid the next payout. If you're, you have a drop of a product and you want to see it, see how it's doing in real time. People weren't using it as a balance per se. It was more just like analytics. And things like that. And so I was thinking we could bring it back here. This is a little weird because we normally have this like 4 sections. If you go here or some other pages, we actually do on this page.

I think you're not seeing it because you don't have active subscribers. If you look at my screen, it's active members and MRR.

Got it. Cool. We should have 4 boxes. Remove number of sales. That's not really that important. I think we have analytics for other places, but I think showing balance on the left and last 7 days, last 28 days in total. 4 boxes, I think would be a good way to bring that back. Would get creators to this page. I want more people spending time here in the future. There should be a single dashboard. Putting the balance right here makes sense. So if we had done something like that, it would basically be adding this extra section. Let's say there's 2 more sections. It would look like this. Yep.

That's what it looks like roughly.

Balance. Imagine if we didn't have to edit the code. I could do this and AI figured out how to update the repo.

Yeah, it could be super cool if there was an AI tool that made the browser like a WYSIWYG editor where if you just change the HTML in the browser, it figures out how to update the code on the backend that's generating that HTML.

Doesn't feel like we're that far from that. It'd be super cool. One thing we should fix is this thing.

Oh yeah, that seems broken. That used to adjust the size of the number so it would fit. Somewhere along the way it probably got broken, but we can fix that.

Nice. If we change this, it would mess up other things, but nice. I think that's a good one to start just to show you can see this here. Let me take a screenshot. If you refresh, it's gonna go back to this. We're gonna make that change. We have more stuff. Let's see if I can share this URL with myself. I created a list of things to do. We're gonna start with the balance one, but let's see how many PRs we can open up in a couple hours.

And so you, for this first one, you think that we should add it to the homepage and we already have the 4 boxes. So are you thinking we just have 4 boxes underneath those 4 boxes, or are you thinking we replace the 4 boxes we have?

I, ideally we replace them. We should have a maximum of 4, but we can look at the code and see what makes the most sense. I only sell 2, but that might be because I don't have subscribers. Yeah.

The first one needs to be their balance. It's confusing that it's called balances. It should be called sales because It does seem to be getting saved. I'm going to change that for now. Balances we're going to get from different locations. It looks like I'm looking at your old PR where you deleted everything. The stats came from countOverviewComponentProps, but the actual data was passed into the presenter. Yeah. We just need to use this.

If you go to BalanceController, maybe it's gone.

I think it's gone. Oh wait, no, it seems like we're still getting them.

I feel like that seller stats thing has to be—

That is what it is.

Hello everybody. Any questions on this? An hour ago, our customer support team is now shipping features thanks to Cursor Tailwind and Cloud 3.5 Sonnet. Someone asked what was their first ship. Someone in the chat also asked about letting CS people— funny, I think computer science, so I was like confused. I was like, yeah.

That's what I think too. I was like, that didn't seem that weird.

Not that weird, right? But how do they know what to change, know the code is functional? Helper is a smaller codebase with a much more modern tech stack. It does have two languages, unfortunately, Python and TypeScript. But you can see an example, a couple PRs just to start small. Always highly recommend starting small. You can see small PRs like this, for example, bots added. This is a good example. These are just HTML pages for our help docs. It's really easy to test. You run npm run dev, you run it locally, and then you visit the URL, make sure it works, right? Something like this. Andy is— left the office, but she is also on our customer support team. So I, this is— I opened the first PR for keyboard shortcuts. Ba ba ba. So this is a feature where we're adding keyboard shortcuts to Helper. So for example, you can mark— you— and I reviewed this in another one, but it does the shortcut key thing. I added this. Nice. See, this is what engineers are good at doing. Some systemic changes. Let's give him a little rocket. Now do it to— so that was the first one. Andy contributed. She's on customer support team. She took a shot with cursor and edited it, added more shortcuts here. A lot of this was probably not working exactly right. She spun this out into a separate file. Sean came in and you could see this. Andy from the support team, and then Sean came in and fixed all of our mistakes in a sort of deterministic way. And this is what the final PR looks like. You can see a lot of Andy's changes were pretty solid. This was my change, render label. Nice to know I didn't do anything super stupid. Add to Slack, clean that up. You see how I was passing a whole div. Now it just passes the strings, much nicer. The B does bad reply here. OnKeyDown, stopPropagation. An engineer still needs to review everything. I would not recommend going straight to production with these changes, but it allows anyone who could have been a product manager can now actually just write the code. Analytics, I mean, this was all her except Jack Zerby went in. So Andy did the first shipments, which is great because it's, she's the one using this a lot. Uh, so she built this thing out. And then Jack and Sean came in. Jack came in as our designer in-house and made this little page header and then probably pinged Sean to make it work properly. And he came back, added specs, and Jack updated the design. This is analytics as part of helpers. This is 450 lines of code, mostly specs probably, and then the file, which is the actual What's gonna be probably the app, presumably members page. So yeah, so this is an example of imagine you were thinking about the Ruby land and the translation layer into the front end. Now compare that to all the props and stuff you're specifying. Now compare that to this. One page touches data, gets the props and renders the front end. There's still some backend because we have Python. So you see this Python code, but imagine if this Python code was right here at the top, or maybe you don't even need this here. It actually went only in the people table. You'd have it right at the top to get this data. And all of a sudden you can do all sorts of cool stuff.

Yeah.

That's an example. And I will go back to letting Connor share his stuff. Could you open the PR?

I will.

Let me share my screen. I'll review it so we can go through everything.

Yes, I'll open it in the next 5 seconds.

Awesome. All right. So I just did merge one of them, this cursor rules thing. So we have these rules. So now hopefully when Cursor writes code for us, it's incorporating our, some of our system, design system, code system, whatever preferences you can add them to this file. We got 3 PRs done. This one is a replacement for this one. Do that. And then we have 3. I opened one, which was in our list, which is just a fix. We have this issue where if you go to your library and go here, these buttons are too long. The reason is there's 100% width on here that isn't necessary. So I fixed that. I just removed those. That was one of the— ideas that was in the list of things to do. This one we finished, so that's this one. And then we also did the balances on the dashboard and the user level toggle. That's 1, 2, 3, 4, 4 or so things that we did. Not too bad. And then to review them all, we'll start with the most recent one. You can see the changes we made. Think about 14 files changed. In a code base of millions of lines, there's 14 diamonds. Each of these is just one or two lines of code changes. A software engineer is still employed for now, right? This is not trivial stuff to know where to change the Discover controller, Links controller, Main controller, three controllers, the card grid. The most obvious place, we're just removing it from there. You don't need to specify these params anymore. That's all going to happen by the time the results come to the front end. We have to add a flags for some backend stuff. So this is the backend stuff. This is now a flag on the DB, show NSFW products. This is edited. This is some of this magic of 2H values. You don't need the key anymore because this is simplified. The show NSFW is no longer there. You can simplify it to this single line of code, which doesn't have this name because it was only being used for that. Specified that in the presenter. This is part of that translation between the backend and the frontend. The spec for the main controller, we deleted this. And then the filtering spec, this is the most important, the automated QA, the end-to-end test. Instead of using the toggle in the params and the URL params, we now use the login user's show NSFW products. We remove it from there. And the way we remove, don't need it anymore. This is the new toggle. The new toggle sets. OnChange, it does update user settings. This is simplified because we no longer need this param name. So this is all— you could have probably said just remove param name from all this and it would get closer. And then some controller specs. This is the presenter, the translation layer between backend and frontend. It's just boilerplate show equals show, right? And then most important is the specs. The specs actually test that it works and your changes are valid. So we have this whole new spec to make sure that the— they can toggle because it's a new feature, right? It's a new feature now that we didn't have before. And then this is an updated spec that instead of testing the checking and unchecking of the toggle, instead what it does is it checks if this field is set on the user in the backend and what products to show or not show based on that. 14 files changed for that relatively simple feature, as Connor said, but it's a, it's, it touches the front end. It touches the backend. It's the settings. There's a lot of places and 14 files changed about 140, 160 lines of code. We did the balance page before we showed sales, total revenue, active members, and MRR. Now we show balance, last 7, 28, and all time. Makes a lot more sense to me. Hopefully creators like it. Oh, we can also look at the diff for that. So that's a 220-line diff, 5 files changed, just basically passing in different data, showing different data, the currency helper so that we can format it nicely. Maybe one day we move all this formatting to the front end instead of the back end, let the, the user's CPU do it instead of our CPU, save money. Some tests. And the admin changed to show the bundle. This was mostly done by Andy, but you could see how we updated it just to fix this. This is indented over one, so it matches this if. So if a bundle, do that, else do what it was doing before. And not bad for 3 hours. We shipped distinct features and small things while streaming and talking. If we had a crazy AI, how much more could we have gotten?

Done. You could move faster if you weren't stopping to narrate. Totally.

And sometimes we're contrived in our use of cursor. If you're just okay doing what you normally do, we could have done maybe double is my guess roughly. But these are the 3 things that we did. Plus the NSFW toggle.

I think this sort of thing is helpful because when someone's watching, you're more in the mode of rethink it, like thinking, oh, is there a better way I could be doing this? Than you would be grinding away.

I feel like I'm leveling up as a coder, even doing these streams, because I have to make sure that I'm presenting, like, the right way to do things. And then, yeah, basically what I would do next is sort these from easiest to hardest. If you're using AI, you could start from the top and build momentum. A lot of these are small-ish. Improve user search sounds good. Visual indicator for failed payouts. That's probably pretty simple. Move it up here. Admin stuff generally is pretty simple. This is a hard admin feature. Flagging, sure. We can move that up. This is going to be tough. Mass transfer. But actually that specific part, the non-active Gumroad accounts, that's hard to do. I don't know how we're going to do it. So I'm going to add a question mark here. This easy. Move this up. This is a question mark. So move it down. Search bar. That's a whole thing. Move it all the way down. This is easy. I wish we got to it, but I don't hate toggling this. I'm going to move it to the top and put it here. This is easy too. Probably put it up here. Sure. Enable. Oh, did we do this one? The issuing payouts stuff?

No, that's different. Related but different.

I'll move it up.

We did a different thing though that is not listed in your list. Yeah, it was the stopping that.

Oh yeah.

Basically you can't republish a product unpublished by admin if you're not compliant. Pretty straightforward.

We also changed 30 days to 28 days, which is a nice win. When you have people thinking about that, writing code, it'll make the products better. So I'm going to move this up here. Or this one. But that's basically what I do. I just sort things from easiest to hardest and then by most valuable and try to get to a nice little mathematical equation. And then we just go through these and bang them all out. But you can see this is like a list of a bunch of— I just asked the team, hey, what should we work on? What would be small wins, low-hanging fruit. And there's 15 things in here and we got done with maybe 20.

How many?

That's 5, 10. Yeah, there's about 20 in here and we got rid of 25%. Imagine 3 more streams, 3 more streams and we're done. Quality of life goes up. People have an easier, faster time, more having more fun answering support tickets. People get answers to their support tickets faster. Everyone's