7 days to App Store
109 git commits
5 major pivots

On March 8, 2026, I opened a blank Xcode project. On March 14, I submitted to App Store review.

Between those two dates: a complete iOS app, fully built — Apple Screen Time integration, system-level app blocking, a custom shield extension, website blocking across all browsers, a streak tracker, a daily check-in system, a full SOS crisis flow with breathing exercises and coping activities, a Firebase backend, StoreKit 2 subscriptions, Fastlane automated screenshots, and a privacy manifest.

The tool I used for almost all of the implementation: Claude Code.

This is the full story — day by day, pivot by pivot, including the parts that didn't work and the decisions I had to make myself.

What I Was Building

Anchor - Bet Blocker is a gambling blocker for iOS. It uses Apple's official FamilyControls and ManagedSettings APIs — the same Screen Time framework parents use to limit kids' screen time — to actually block gambling apps and websites at the operating system level.

When someone tries to open a blocked gambling app, instead of a generic lock screen, they see a roast message. Something blunt. Something that short-circuits the impulse before it becomes action. That's the product's signature feature.

The idea came from a simple observation: most gambling blocker apps look like they were built in 2014, require you to create an account before you can block anything, and offer generic "you've got this!" messaging that nobody finds convincing at 2am when an urge hits. There was a real gap for something modern, private, and honest.

I'd been aware of the FamilyControls API for a while. Getting it approved by Apple requires an entitlement, but it exists, it works, and it's the right tool for this job. The question was: how fast could I actually build something real?

The Setup: How Claude Code Actually Works Here

Before the day-by-day breakdown, some context on the workflow.

Claude Code is Anthropic's agentic coding tool — it runs in your terminal, reads your actual files, writes code, runs commands, and iterates. It's not autocomplete. You describe what you want, and it figures out how to implement it across whatever files it needs to touch.

The key practice I adopted from day one: a CLAUDE.md file at the project root. This file acts as Claude Code's persistent memory between sessions. It holds the architecture decisions, the design system, the naming conventions, the Firebase schema, the current state of the app. Every time you start a new session, Claude Code reads this file first. Without it, every new conversation starts cold.

With it, I could end a session at midnight, sleep, and pick up the next morning with Claude Code immediately oriented — knowing what we'd built, what the current task was, and what patterns to follow.

The developer's job shifts from "write the code" to "make the right product decisions." The AI handles implementation. You handle judgment.

Day by Day

Day 1 · March 8 22 commits
Architecture, App Blocking, First Real Device Test
Claude Code scaffolded the entire project structure from scratch: SwiftUI app architecture, design system with color tokens and typography, Firebase integration with Crashlytics, localization setup, and — most importantly — the FamilyControls and ManagedSettings integration for actual app blocking. By the end of day one, I could select a gambling app using Apple's native app picker and have it blocked at the OS level on a real iPhone. That's the hardest part of the whole app, done on day one.
Day 2 · March 9 17 commits
Roast Messages, Spending Onboarding, Anchor Contact
Built the roast message system — the custom Shield Configuration Extension that intercepts blocked app launches and shows a confrontational message instead of Apple's default screen. Hit the first major constraint here: the Shield Extension runs in a heavily sandboxed environment. 6MB memory limit, no network access. Tried using Firebase AI (Gemini) to generate roast messages on the fly. Didn't work. Pivoted to pre-cached messages stored in Firestore and synced to the device at launch. Also built the spending onboarding flow and anchor contact management.
Pivot #1 — AI-generated roasts → cached messages

The Shield Extension environment is extremely restricted by Apple — no network, minimal memory. Real-time AI generation was a dead end. Batch-cached Firestore messages solved it and, as a bonus, gave us full editorial control over the tone and quality of every roast.

Day 3 · March 10 5 commits
Dashboard Redesign, Session Blocking Killed, SOS Flow Begins
Fewer commits, bigger changes. The original blocking model let users start and stop "blocking sessions." I killed it. Blocking should just be on — full stop. The fewer decisions a user has to make when they're fighting an urge, the better. Redesigned the entire dashboard. Started building what I was calling a "panic button" — which by end of day had grown into the skeleton of a proper multi-step crisis flow.
Pivot #2 — session blocking → always-on blocking

Session-based blocking sounds flexible. In practice, it adds friction exactly when you don't want friction. If someone is fighting an urge at 2am, they shouldn't need to think about whether their blocking session is active. Always-on is simpler and better for the user.

Day 4 · March 11 17 commits
Dropped Authentication Entirely, Shipped SOS + Website Blocking
The biggest day, philosophically. I'd built full authentication on Day 1 — email + Apple Sign-In, the whole thing. On Day 4 I deleted all of it. The reasoning: a gambling blocker that requires you to create an account before you can block anything is a bad gambling blocker. If someone is trying to quit and they hit a sign-in wall, you've already lost them. Zero accounts, local storage only. Same day: the complete SOS flow shipped (trigger identification, breathing exercise, physical challenges, creative challenges), the streak calendar, and the website blocking system with 2,500+ domains.
Pivot #3 — authentication → no authentication

This one hurt. A day of work, deleted. But it was obviously right. The target user is someone fighting addiction at their most vulnerable moment. Friction is the enemy. No accounts means instant setup, full privacy, and no password recovery emails landing in their inbox for the rest of time.

Day 5 · March 12 31 commits
The Grind — Domains, Daily Check-in, Subscriptions Begin
Thirty-one commits. Firestore uploads for the gambling domain catalog, pagination system, daily check-in flow (the swipe-to-log interaction), message caching, rating request flow, force update system, challenge content caching, SwiftLint configuration, release build setup. Started the subscription infrastructure. This was the day the app became a real product rather than a collection of features.
Day 6 · March 13 7 commits
StoreKit 2, Paywall, Subscription Gating
Full subscription system: StoreKit 2 integration, monthly and yearly products, feature gating (app blocking, website blocking, SOS flow, anchor contact all require subscription), and the spending impact screen before the paywall. That screen was deliberate — users enter their gambling frequency and average spend during onboarding, and before hitting the paywall we show them a visualization of their annual losses. If their numbers are below the average for their currency, we show the average instead. The goal is to make the number real before asking for a credit card.
Pivot #4 — user numbers → average data fallback

Problem: casual gamblers entered small numbers. Small numbers didn't land. Solution: if your number is below the average gambler in your country, show the average. The paywall conversion goal is for users to feel the real weight of the habit — not just their own minimized version of it.

Day 7 · March 14 10 commits
App Store Prep and Submission
Fastlane snapshot configuration for automated screenshots across iPhone 14 Pro, 14 Plus, 8 Plus, and iPad Air M3. Privacy manifest (required by Apple for apps using certain APIs). Bug fixes surfaced from real-device testing. Final polish pass. Submitted to App Store review at end of day.

What Claude Code Is Actually Good At

Boilerplate, especially SwiftUI boilerplate, is nearly free. Setting up navigation structure, design system components, Firebase configuration, localization keys, Crashlytics — things that would take a day or more to get right from scratch — Claude Code handles in minutes.

Refactoring without attachment is the other superpower. When I decided to drop authentication on Day 4, Claude Code deleted every auth-related file, updated every view that referenced it, cleaned up imports, and rebuilt the local storage layer. No hesitation, no "but we spent a day on this." The AI has no emotional attachment to code it wrote yesterday. That's a feature.

The CLAUDE.md pattern — keeping a running document of architecture decisions and conventions — is what makes multi-day projects coherent. Without it, each session starts cold. With it, Claude Code can pick up exactly where you left off and stay consistent with decisions made three days ago.

What It's Not Good At

Product decisions are still entirely on you. Claude Code will implement whatever you ask it to build, but it won't tell you that your blocking model is wrong, that your sign-in wall is hurting conversion, or that your "panic button" needs to be a full SOS flow to actually be useful. Those insights came from thinking about the user, not from the AI.

Apple's more obscure APIs still require real research. FamilyControls, Shield Configuration Extensions, and ManagedSettings are niche enough that Claude Code's implementation needed more guidance and iteration than, say, a standard networking layer. I had to understand the constraints myself — 6MB memory limit, no network access in Shield Extensions, entitlement requirements — and communicate them clearly.

Testing judgment is yours. Claude Code doesn't know whether a coping activity actually feels helpful, whether a roast message tone is right, or whether the paywall placement is converting. Real device testing and product intuition still matter.

The Bigger Point About Speed

A solo developer building this traditionally — SwiftUI app, FamilyControls integration, Firebase backend, StoreKit 2 subscriptions, custom Shield Extension, 2,500+ domain database, full SOS flow — is looking at two to three months minimum. That's assuming they already know the APIs and aren't learning as they go.

Seven days compressed that by roughly 10x. The compression didn't come from cutting corners on features — the feature list is real and fully implemented. It came from removing the gap between "I know what I want" and "the code exists."

The speed of pivoting is where this really shows. Dropping authentication, redesigning the blocking model, rebuilding the dashboard, expanding the panic button into a full SOS flow — each of those would have been painful and time-consuming decisions to reverse-engineer in a traditional codebase. With Claude Code, they happened in hours, not weeks. The cost of changing your mind is almost zero.

When changing your mind costs almost nothing, you make better product decisions. You don't defend bad choices because you spent three weeks on them.

On "Vibe Coding" — A Realistic Take

The term gets used loosely. Some people use it to mean generating one-off scripts. Some mean full production apps. What I'm describing is closer to the latter: a real iOS app, submitted to the App Store, with real users in mind.

It's not magic. You still need to understand what you're building. You need to understand the APIs well enough to know their constraints. You need to make product decisions. You need to test on real devices. You need to think about edge cases.

What changes is where your time goes. Less time writing boilerplate. Less time context-switching between implementation and product thinking. Less time stuck on syntax. More time on the decisions that actually matter.

For a solo developer with a clear product vision and enough technical context to guide the AI, it's genuinely transformative. For someone learning to code for the first time, I'd expect a messier experience — the judgment layer still requires understanding.


Key takeaways if you want to try this

01 Use a CLAUDE.md file religiously. Update it with every architectural decision. It's the AI's memory between sessions.
02 Start with the hardest, most uncertain technical piece first. If I couldn't get FamilyControls working on Day 1, there was no app. Validate the risky stuff early.
03 Don't defend code just because it took time to write. The auth system took a day. I deleted it in an afternoon. That was the right call.
04 Know the API constraints yourself. The Shield Extension memory limit and network restrictions aren't things Claude Code could guess — you need to bring that knowledge.
05 Product thinking is not outsourceable. The AI builds what you describe. Describe the right thing.

What's Next

Anchor - Bet Blocker is live on the App Store. The core loop — block gambling apps, block gambling websites, track your streak, use the SOS flow when urges hit — is working. The roast messages are doing their job.

From here: Android (the gambling demographic skews heavily toward Android in some markets), more languages, and improvements to the SOS flow based on real user feedback. The domain catalog will grow. The roast messages will be refined.

If you're a solo developer looking at a product idea and thinking "this would take months" — it might not. The tools have changed. The bottleneck is increasingly the product thinking, not the implementation.

That's worth sitting with.

Try Anchor - Bet Blocker

Free to download. App blocking, website blocking, SOS flow, streak tracking. No account required.

Download on the App Store