Dear founder,
I’ve been using Claude Code for over half a year now, pretty much exclusively, to build my platform. Haven’t really deviated much to other tools. And I think I’ve gathered enough experience with the system that it’s time to share what I’ve learned about using Claude Code effectively to build a non-trivial Software as a Service application.
Here’s what I’ve found: a lot of the value of Claude Code is in its configuration and correct prompting. When you’re just starting, you think the value is really in the code it generates. But honestly, most of the value of Claude Code is in the code it doesn’t generate—so you don’t have to throw it away. The better you are at setting a really solid system prompt, at executing the agentic loop correctly with the right permissions, the right interceptions, the right restrictions, the better your experience with Claude Code will be.
Let Claude See Your Application
First off, any plan of Claude Code will work for whatever you might need. But the moment you start using it more heavily—for feature building, for testing, for background processing—you’ll likely exceed the $20 a month plan. The Max plan tends to be what I’d recommend at this point, because then you can just keep it running. You’ll see why this matters in a second.
Claude Code released an integration with Chrome a couple months ago. You can start Claude with the --chrome flag so that it connects to your Chrome instance. This creates a bridge to the browser that allows Claude to operate within a browser for you.
If you don’t do anything else from the things I tell you today, do this one thing: allow Claude to see your application. To literally be able to click around in it, take screenshots, move things, investigate the DOM and the variables that run within it.
It is incredibly smart to connect your Claude instance to a running version of your software. Within the prompt and within the operational loop, it can be tasked with things like: “Look at this page, scroll down a little bit, and see how this one component overlaps with the other.” Or: “Look at this page, inject some data, and see how it shifts the layout in weird and unexpected ways.”
And Claude will do this. It will recreate the situation, take screenshots, and actually investigate what’s going on by diving into both the visual and the hierarchical structure of the page.
I’ve done things over the last couple of weeks like asking Claude to go into the navigation on the left, click on each item, and see if all the first pages look similar—or which one looks slightly different and might need to be changed to create a consistent design language. Claude is incredibly good at this because it can navigate your website easily and build an internal representation of that structure.
It also makes it easy to build features that have visual components. Instead of hoping that it looks right, you can task it to build something, look at it, and then refine it. Really enjoyable.
The Ralph Wiggum Loop
One of the biggest inventions in agentic usability is called the Ralph Wiggum plugin, or the Ralph Wiggum loop.
This might sound surprising. Obviously Ralph Wiggum is a character from The Simpsons. What does that have to do with agentic coding?
Well, Ralph embodies the philosophy of persistent iteration despite setbacks. You try something, it doesn’t work, you try again, it doesn’t work, you try again—until eventually it does work. That’s the whole idea of this loop approach.
It’s not “try it and then stop if it doesn’t work.” Instead, you set a goal, set a completion promise, and only until that promise is fulfilled do you repeat working on it—forever if necessary. If you need three iterations to get there, great. If you need thirty, okay, maybe that’s what it takes. If you need three hundred, maybe it takes that.
It’s a very mindless but very thoughtful approach, because it puts the idea of failing as information at the center of its core. Failure is a good thing because it teaches us another way of how it’s not to be accomplished. Success is when we ultimately reach the state of the promised goal. But every failure state along the way removes one further potential state that we need to check.
The way it works: you describe your task, and then Claude works on the task. It tries to exit the task, but there’s a stop hook that blocks the exit. The stop hook feeds the same prompt back, and until the task is completed, that loop just keeps going.
This is a different approach than what Claude Code currently does by default. Right now, it tries the thing, and the moment there’s a problem, it exits and asks you to do something. The Ralph Wiggum plugin allows it to keep working and iterating on a solution by trying new things without your intervention.
I have a strong feeling Claude Code will adopt this methodology eventually into the main loop. But right now, this plugin is how you get that behavior.
Permissions: What to Allow, What to Restrict
Allowing things and restricting things for Claude Code—these are pretty critical. You don’t want to have to be there all the time saying “Yes, you can do this. Yes, you’re allowed to run this command.”
For commands you know are perfectly fine to run automatically without confirmation, you want to persist them as permissions in the allow array in your settings.local.json. Claude Code will do this for you if you say “Yes, and allow this in the future”—it will automatically add that line.
You probably want to have a couple of commands in there: the Ralph Wiggum script, particular skills you know you want to use, particular build commands in your framework of choice.
But just as importantly, you want to look into the deny array in your permission settings.
There might be commands—particularly when it comes to testing and setting up environments—that could be quite dangerous. Most of the time, it’s fine if we wipe the test database, which is just created for the sake of testing. But your local development system might have state in your development database that you want to keep.
You want to prevent your framework’s tooling from wiping your database, from re-migrating all the migrations, from seeding it with data that overwrites what you’re currently working with.
If you’re using PHP and Laravel like I do, you probably want php artisan db:wipe, migrate:fresh, or the db:* commands in the deny list. The moment it’s in the deny list, Claude will try it, it will fail, and then it will stop and ask you. At that point, you can figure out what the agent is currently trying to do. Is it really trying to delete my database? If so, which one? The test one? That’s fine. My dev one? Probably not. My prod one? Dear God, no.
That’s what deny permissions really help with.
Here’s something important, though: Claude is very smart. It might see that you’re blocking a command with a rejection, so it tries to create a new bash file that contains the command, then tries to run that bash file. If you’ve allowed running all bash files it wants, it can circumvent your restrictions.
So you have to be very restrictive, even in what you allow Claude Code to run, because it might find alternative ways around your restrictions. Since we’re talking about a completely agentic system, this vigilance matters.
Testing Is Where Claude Code Shines
My final tip for using Claude Code effectively: ask it to write tests for every single thing it builds.
Testing is extremely easy with Claude Code. It knows how to write tests for the language, for the framework that you’re running. It knows how to execute them. It knows how to safely execute them if you define it well.
If you have a testing environment variable and a testing database that’s isolated from your development and production and staging systems, then you can ask Claude to test for you. If you already have a collection of tests, it will keep them working. And if you’re building a new feature, you should always—in the prompt you’re inputting, or in the system prompt you should have to begin with—ask it to create tests and make sure all tests pass after new features have been built.
One thing I’ve learned: you tend to want to iterate a little before you add tests. Usually, it’s smarter to build the feature first, then build the tests. If you go test-first with an agentic system, iteration becomes problematic. The moment Claude Code starts experimenting and tests start to fail, it becomes this weird interference loop.
So let it build the feature first, but then make sure—before you commit—for it to build tests around it. That’s what works best in my experience.
Build a Solid System Prompt
For the system prompt to be effective, it has to stand on its own. If you look at the tools provided by Augster they have a repository on GitHub that contains the Augster prompt, which I’ve been using for the longest time. It’s a very specific system prompt that encourages Claude Code to run in a loop, kind of like what Ralph Wiggum does, but more specifically as a definition of what good code looks like. It’s more of a description of the output than just the process.
I still recommend building a solid system prompt for your project. A good system prompt should contain:
A description of what the project is and its capabilities. Maybe more importantly, a description of the people who are going to be using it—the ideal user. This allows Claude to build tools and functionality that are aligned with what people might need.
It’s very helpful for Claude to know who this is for. Then the automated systems that build features have a better understanding of user capabilities and user expectations.
Putting It All Together
Obviously all of this changes almost on a weekly basis. But right now, with a system prompt that encourages testing, a couple of things you allow to be automated, a couple of things you restrict to not nuke your local system, an operational loop like Ralph Wiggum or the Augster prompt, and browser access using the Chrome flag—you’re probably going to be in the top one or two percent of Claude Code users at this point.
The real insight here isn’t any single tip. It’s that the value of agentic coding comes from how you configure and constrain it, not from the raw code generation. Set up your environment right, and Claude becomes a genuine collaborator. Leave it unconfigured, and you’ll spend more time cleaning up messes than building features.
I hope this gives you some insight into what you can do to level up your Claude Code workflow. If there’s more to share as the tooling evolves, I’ll keep you updated.
We're the podcast database with the best and most real-time API out there. Check out podscan.fm — and tell your friends!
Thank you for reading this week’s essay edition of The Bootstrapped Founder. Did you enjoy it? If so, please spread the word and share this issue on Twitter.
If you want to reach tens of thousands of creators, makers, and dreamers, you can apply to sponsor an episode of this newsletter. Or just reply to this email!
