Krishna Goutham

A http://bolt.new tip - Reduced my http://bolt.new token usage by 70% while building a complex project (Context: My current project has a 35-page PRD and 16 database tables)! From: 1M tokens for 3-4 prompts To: Same 1M tokens now handling 10-12 prompts In my experience working with http://bolt.new, successful execution comes through precise problem-solving - knowing exactly what's breaking and where. Being a developer helps here, as it's easier to pinpoint issues and fix them. But if you're a non-developer like me, I've found that setting up Claude as your "software architect" is the key to achieving this precision. Building on my previous tip about having a detailed FRD (Functional Requirements Document), here's the structured system I've developed: File and Folder Structure in Bolt: Start with a File Structure Map. I ask bolt to create a "http://fileNames.md" that lists every file and maintains the folder hierarchy. Each entry includes a one-line description of the component's purpose and functionality. This becomes our project's map. Claude Projects: Set Up a Dedicated "Issue Resolution" Project in Claude. I created a separate Claude project specifically for handling fixes and updates. Under project knowledge, I've added: - The complete file structure (from http://fileNames.md) - Master functional requirements document - FRD split by components (based on user flow) - A document explaining http://bolt.new's capabilities Streamlined Problem-Solving: For every fix or new feature, I go to this Claude project and use a specific prompt structure. Here's my workflow: - First, I set the context with my "system prompt". - Then, for each fix/feature request, I use the "execution prompt". This specific format I use to describe the issue/feature, which helps Claude write optimized prompts for http://bolt.new, identify relevant files, and suggest the most token-efficient approach and even provide you with the exact steps to fix the issue. Using .bolt/ignore: I worked with Claude to identify files that don't need to be in the LLM's context and added them to .bolt/ignore. This significantly reduced token usage while maintaining development efficiency. Note that we need to do this multiple times, depending on what you're fixing. The result? I've essentially created a two-tier system: - Claude acts as the "software architect," analyzing issues and designing solutions - http://bolt.new becomes the "developer," implementing those solutions efficiently This approach has transformed my development process. Instead of getting stuck in token limits or unclear prompts, I can focus on building and improving features. Yes, the initial setup takes time. Yes, you'll face challenges with token limits and error loops. But giving up when things get complex means missing out on what http://bolt.new can really do. This structure pays for itself in reduced token usage and clearer development paths. @stackblitz is already shipping features and optimisations at the speed of light - all we need to do is to figure out a way that solves most of our issues. If you'd like to implement this for your project or need clarification, happy to help. Just drop a reply or DM. P.S. Still wonder sometimes if I should make a video about this setup. Let me know if that would be helpful.