Congrats on Shipping
If you've taken any builds past http://localhost:3000/ — congratulations.
Many people don't push past the point of ideation. You did. Now, I'm here to walk you through what comes next: iteration.
I'm working on a few things right now: iOS apps, websites, personal tools, you name it. It's never been more fun to program. But something I've learned along the way:
V1 usually sucks.
There's bugs. It's clunky. You need feedback. But that's not an issue; that's what we have Claude for. Users give us feedback, and we adjust.
How to Make Something Good?
You iterate. Fast.
Claude Code makes building feel like magic. Type a few sentences, see something real. That's what got you to V1.
But V1 is just the start. Now you need to improve it. Fix bugs. Add features. Respond to feedback.
The question isn't can you improve — it's how fast?
That's where your dev loop comes in.
So What's a Dev Loop?
A dev loop is the process of moving a bug or feature from your head to your users' hands.
The tighter the loop, the faster you learn. The faster you learn, the better the product.
- Think about it:
- Slow loop = make a change, wait hours/days, see if it worked
- Tight loop = make a change, see the result in seconds
Which one lets you iterate faster?
FWIW, I think we can all agree a tight loop is preferred.
I'm no expert. I'm learning just like you. But, I've released a couple apps (shameless plug): Tim (your personal finance buddy that shames you for using your credit card) and SwitchFlip (a marketplace for goofy and regular skaters to swap shoes). And now I'm in the process of refining and improving them.
The Principle
Here's what I've learned:
Remove yourself from the process. Every manual step is friction. Every "wait for it to build" is time you're not iterating.
The goal: once you define the fix, let automation handle the rest.
- Automate the boring parts
- Script the repetitive steps
- Let code do the waiting
- While its running, build more things
This applies everywhere — iOS apps, websites, backends, you name it.
Here's a quick example:
If you're looking to launch an app on the App Store, there are two ways to ship updates: OTA (over-the-air) or the traditional Xcode → TestFlight route.
OTA lets you push changes straight to users' phones. No App Store review. No waiting. You fix a bug, users get it in seconds. This is great for UI tweaks or bug fixes — basically anything that doesn't require Apple's built-in features.
Xcode/TestFlight is the traditional route. It's slower. Every update goes through Apple. But it gives you access to native features (the stuff built directly into iOS that requires Apple's own code to work). Think: widgets on your home screen, health data, Apple Pay, etc.
The tradeoff: speed vs features.
If you don't need native features, use OTA. You'll save hours on every single iteration.
If you need widgets or Apple-specific integrations, you're on the TestFlight path — but there are ways to make it less painful. Stay tuned for more on that in future posts.
What's Next
This is part one of a growing series on tightening your dev loop.
- Coming up:
- **iOS**: OTA updates vs TestFlight — and how to make TestFlight less painful
- **Web**: Hot reload, deploy previews, CI/CD
- **Automation**: Fastlane, GitHub Actions, and removing yourself completely
I'll share what I learn as I go. We'll learn together.
The Point
V1 is just the start. What makes a product great is how fast you can iterate.
Tighten your loop. Automate the boring stuff. Remove yourself from the process.
Smooth is Fast.