Lazar Jovanovic: commitment

Transcript context

…And implementation plan is kind of in service of the future tasks.md, if that make ... All of these files are in service of building tasks.md. When you build tasks.md, then the rest is almost irrelevant. It's just the basis for you to build tasks to execute. The implementation plan is kind of the first layer, which is again, higher-level overview. It doesn't go into the depth of how to get there. It just goes into the explaining of, "Oh well, if we're building this, I think we should start with the backend, and we should start with tables and then later authentication. And then after that, we're going to bring in the API. And then after that, we're going to do this." It's like, again, just think of it as having ... I'm an ideas guy. I'm sitting with a technical guy. It's me and you. We're building our startup. I know you're a software engineer by background and I'm telling you my idea. I'm giving you the master plan. And you come to me back and you're like, "Okay, if you want to do this, it's doable. Here's how I would order it." You didn't have a roadmap, you didn't open your Linear and started writing features and RFCs and whatever. You're just high-level talking about the order of things. And then me and you, again, as two co-founders, we talk and say, "Okay, well, if we agree on this, how should this look like? How should this feel? Let's describe it high-level," but now because I use AI, I can go a little bit deeper. And that's where I like to see Lovable or any other tool. ChatGPT is good at it. I even have my ... I've built custom GPTs. So if people want to start somewhere before they even get into any tool, they can go to ChatGPT store for GPTs and just type Lovable base prompt generator or Lovable PRD generator and find those that I built and just brain dump in them and then get these files as output. Right? So I like to see some elements of CSS in design guidelines because with design, it's a little bit tricky. AI is sometimes overcreative. So that's where I'm doing a little bit more technical steering. And then finally, it's just the user journeys, just like if we know how things look like, if we know how they feel, if we know what we're building, high-level. High-level, just very high-level again, how do people navigate? What are some of the features in there and stuff like that? And then tasks.md gets into the nitty-gritty of, "Oh, if you want these user journeys and you want the backend built first, here's a set of tasks that I need to do." It just takes that as an input. I'm just making the tool do that gritty work that humans used to spend so much time on. I feel like with these tools, we're all becoming product managers on steroids. We're just leveraging AI, but good product managers, I think are not compensated for writing good PRDs. They're compensated, again for good judgment. Somebody else can do the writing. ers on steroids. We're just leveraging AI, but good product managers, I think are not compensated for writing good PRDs. They're compensated, again for good judgment. Somebody else can do the writing. You, as somebody who directs and builds this product, you need to know, again, what's going to be useful, what's going to be tasteful, what's going to be something that actually moves the needle. I will say one thing though, just because I put so much emphasis on, "Oh, you need to acquire taste. Oh," that doesn't mean you shouldn't build. You get better at this by building actually. So everybody listening to this should literally go and build something today. One, two, three, four, five projects, test all of these tools because that's how you get to clarity, not just by reading, but also by doing as well. Here's a puzzle for you. What do OpenAI, Cursor, Perplexity, Vercel, Plaid, and hundreds of other winning companies have in common? The answer is they're all powered by today's sponsor, WorkOS. If you're building software for enterprises, you've probably felt the pain of integrating single sign-on, SCIM, RBAC, audit logs, and other features required by big customers. WorkOS turns those deal blockers into drop-in APIs with a modern developer platform built specifically for B2B SaaS. Whether you're a seed-stage startup trying to land your first enterprise customer or a unicorn expanding globally, WorkOS is the fastest path to becoming enterprise-ready and unlocking growth. They're essentially Stripe for enterprise features. Visit workos.com to get started or just hit up their Slack support where they have real engineers in there who answer your questions super fast. WorkOS allows you to build like the best with delightful APIs, comprehensive docs and a smooth developer experience. Go to workos.com to make your app enterprise-ready today. I'm imagining people hearing this may start to feel like this is so much work. "I just have to sit here and create all these rules and figure out all these little details." In one sense, it is. In another sense, this is like you spend a few hours, maybe a day planning and then you have AI build this thing that would've taken somebody weeks, months, right? The amount of investment to achieve this thing is absurd, the ROI. Also, this shows you just what professional vibe coding looks like. Everyone imagines vibe coding, "I'm just sitting here typing stuff, and go and do this." If you want to actually build something really great that moves the needle, as you said, that solves people's real problems, that lasts, that scales, this is how you do it if you really want to do this as a job, and also if you want to build things that are really great.…

Stored transcript either side of the excerpt. The highlighted words are the published quote; the surrounding text is unedited source, never generated.