# Better First Drafts: How to Build Apps Fast Without Infinite Iterations > True efficiency with AI tools isn't a hack. It’s a continuous practice of structured sprints, timeboxing, and leaning into the friction of a blank canvas. **Published by:** [Hard Mode First](https://hardmodefirst.xyz/) **Published on:** 2026-06-17 **URL:** https://hardmodefirst.xyz/better-first-drafts-how-to-build-apps-fast-without-infinite-iterations ## Content Yesterday I attended a demo day for Decoded Futures by Tech:NYC, a NYC-based organization that helps nonprofits build and deploy their own AI tools. It’s always incredible to see how far people can go with just 6 or 8 weeks of focused building. But one participant shared a piece of reality that really stuck with me. While they ultimately got the exact output they wanted, it took 40 drafts across different versions and Claude prompts to get there. This led to a conversation about “tokenmaxxing” (the art of squeezing the absolute most value, context, and efficiency out of every single AI prompt) and how to optimize your build time. Engineers talk a lot about ways to optimize model usage, context windows, compute cost, and prompt efficiency. But one thing that particularly helped me in the beginning was much simpler: Better first drafts. Whether you’re writing an essay or making an app, getting better at first drafts is one way to optimize what comes next (image source: NanoBanana) 5 Ways to Get Better First Drafts In the 18 months since I’ve been building with AI, I’ve gotten much better at first drafts. I’ve noticed that the price of iteration, while seeming low, has long-term effects and how important first drafts are to developing the long-term technological architecture of anything that you build. The question is: How do we get better at first drafts? There are a couple of things that seem to be working for me: 1. Starting with clear problem-oriented outcomes in mind. Before building anything, I like to spend a lot of time making sure I’m actually building the right thing. I do this often by having long conversations with a separate AI tool or human, or both, about what I want to build. If I can’t get it to a crystal-clear outcome that I can describe first in just a single paragraph, then I’m probably not ready to start building yet. A framework that really helps me is one that we conceptualized during the first iteration of Decoded Futures back in 2024: POP-IT. This problem-centric framework helps you focus back on an outcomes-oriented approach to building and has enabled me to build everything from my personal business operating system to mobile apps. POP-IT is a design framework that helps you shape your problems in a better way for AI to understand, interpret, and think alongside you 2. Working with my AI on order of operations. As a non-classically trained engineer, this has been the hardest thing for me to learn over the years. How do I know what has to happen in which order first? I’m starting to develop a better intuition for this, but again, without having it in my head, it’s sometimes harder for me to know the right mode. My favorite way to figure this out is to ask for help along the way. Here’s a brief infographic to get you started. A simplified “order of operations” framework for software builders, as generated by NotebookLM 3. Timeboxing of any kind. Today I work in three-hour morning blocks where I get things built, and then my afternoon blocks are where I work with humans. If I can’t complete a project in a morning block, that means I probably scoped it too big for the morning. If I can’t complete a bigger project in a week, that means I scoped too big. Just like having a bunch of half-finished blog posts in a Google Drive is worthless to me, having a bunch of half-finished apps is also worthless to me, so I’m trying to get better at pushing publish before I’m done, and that means timeboxing. 4. Practice, practice, practice. Yesterday on LinkedIn, my friend Saadiq posted a counterpoint to AI slop generation, noting that it’s only after working through what “slop” feels like to you can you move past it to create AI-enabled artifacts that don’t feel quite so sloppy. What he’s calling out is the importance of practicing. Without practice, you won’t improve outcomes. This has certainly been true for me. Most of my best apps and AI-enabled builds that I still use today are actually projects that began with multiple first drafts, often starting with the exact same prompt. I like to look at it like how a writer might emulate the style of someone else: take note of what you like, take out what you didn’t like, and then try again. When I rebuilt my website last year, it took me about six first drafts over the course of several months in order to get to a first draft that felt good enough to continue iterating on. 5. Structured sprints. The way that we run every workshop and builder experience at Build First is through an AI Power Hour that includes a structured sprint. It includes: Context: The first third is the context gathering sprint. You need to understand what your problem is and teach the AI about that problem. Logic: The middle bit is the logic layer. You need to decide what you want the AI to create, decide, or take action on your behalf. Interface or Integrate: Once you can build this out, you can then decide whether you’re trying to build something that’s an interface-oriented, like an app or a website, or something that’s more integrated, like a headless autonomous agent. Over time, I’ve noticed this feels like a flow state of building. Like a Vinyasa yoga class, the core sequence remains the same whether you are a beginner or an expert, and whether you're building a fresh codebase or a tiny feature. It treats software development as a continuous practice, rather than a one-off task. 40 First Drafts No matter if you’re a writer, a developer, or a regular at the yoga studio, the truth is that you can’t shortcut your way toward perfection. The iterative process of learning how to work from a blank state to a final product is the work. And on some level, this friction is an essential part to learning. And what took you 40 first drafts the first time will likely take you 10 or less the second time. So if you’re currently finding yourself in the midst of an iterative rabbithole, don’t stress too much. Take a deep breath, take a break, and give yourself a pat on the back. Sometimes we all need a little reminder: This is what it feels like to learn something new. ## Publication Information - [Hard Mode First](https://hardmodefirst.xyz/): Publication homepage - [All Posts](https://hardmodefirst.xyz/): More posts from this publication - [RSS Feed](https://api.paragraph.com/blogs/rss/@bethanycrystal): Subscribe to updates - [Twitter](https://twitter.com/bethanymarz): Follow on Twitter