The Solo Builder's Playbook

Everything I learned shipping SwipeClean, SipStreak, and VaultSnap as a solo developer. No team. No funding. No "growth hacker." Just one person, three apps, and a lot of mistakes that turned into patterns.

This is the resource I wish existed when I started. Specific enough to be useful. Short enough to actually finish.

Part 1: Lessons From Shipping 3 Apps Solo

1. Scope is the only thing that kills solo projects.

Not motivation. Not skill. Scope. Every app I shipped started with a feature list twice as long as what launched. SwipeClean originally had social features, leaderboards, and cloud sync. None of that shipped. What shipped was swipe-to-delete with gamification. That's it. And it was enough.

The pattern: write your feature list, then cut it in half. Then cut it again. What's left is your v1.

2. Pick one monetization model and commit before you write a line of code.

SipStreak is a one-time Pro purchase. SwipeClean is freemium with ads plus a lifetime Pro unlock. VaultSnap is a one-time Pro purchase. I decided this before building anything. If you figure out monetization after the app works, you'll bolt it on and it'll feel bolted on.

The decision tree is simple: Is the core value ongoing or one-time? If someone uses it daily (water tracking, photo vault), one-time purchase works because retention is built in. If usage is sporadic (photo cleanup), ads bridge the gap.

3. SwiftData is ready for production, but only if you treat it like a database, not magic.

Every data bug I hit came from treating SwiftData like it would just handle things. It won't. Define your schema explicitly. Use @Model with intention. Never access ModelContext from Views. Never. Put it in a Service, mark the Service @MainActor, and access it through your ViewModel. The architecture is rigid but the bugs disappear.

4. Ship the ugly version first, then make it beautiful.

SipStreak's first working build looked like a wireframe. No animations, no themes, no polish. But it tracked water and it worked. I used it myself for a week before touching the UI. That week told me what actually mattered (the streak counter, the daily reset, the one-tap logging) and what I thought mattered but didn't (detailed charts, weekly summaries).

If you polish before you validate, you'll polish the wrong things.

5. The App Store review process is not your enemy, but it is unpredictable.

SwipeClean got rejected twice. Once for a screenshot that showed "mock" data that looked too much like real user photos. Once for a metadata description that used a competitor's name. Both fixes took 10 minutes. The reviews took 48 hours each.

Build review time into your timeline. Assume at least one rejection. Have your screenshots, privacy policy, and metadata ready before you submit, not after.

6. One-person CI/CD is still CI/CD.

I don't have a build server. I don't have automated deployments. But I do have a process: XcodeGen regenerates the project file, I build for simulator, I run the tests, I archive and submit. Same order every time. No skipping steps.

The point isn't automation. The point is that the process exists and you follow it even when you're tired and just want to ship.

7. Privacy-first is a feature, not a limitation.

All three apps store data on-device. No cloud sync. No analytics beyond what Apple provides. No user accounts. This wasn't a philosophical choice; it was a practical one. Cloud infrastructure costs money, takes time to build, and creates an entire category of bugs and security concerns.

VaultSnap encrypts everything with AES-256-GCM locally. SipStreak uses HealthKit for the health data and SwiftData for everything else. SwipeClean never touches your photos outside the standard PhotoKit flow. "Your data never leaves your device" is a selling point, and it's also the easiest architecture to maintain solo.

Part 2: The Decision Framework

Solo development is a continuous stream of binary choices. Here are the ones that matter most, and how to think about them.

Ship vs. Polish

Ship when:

The core feature works correctly
You've used it yourself for at least 3 days
The bugs are cosmetic, not functional
You're adding features to avoid submitting

Polish when:

The first 30 seconds of the app feel broken or confusing
Onboarding doesn't exist and the app isn't self-explanatory
The icon and screenshots look like a homework project

The test: show it to someone who doesn't know what it does. If they can figure it out in 30 seconds, ship it. If they can't, that's not a polish problem, that's a clarity problem.

Add Features vs. Cut

Add when:

Users are asking for the same thing repeatedly (not just once)
The feature directly supports the core loop (not adjacent to it)
You can build and test it in under a week

Cut when:

The feature requires a new framework or dependency
You're excited about it but no one has asked for it
It adds a settings screen or configuration step
You've been "almost done" with it for more than 3 days

The rule: if it doesn't make the core experience better for 80% of users, it's a v2 feature at best and a distraction at worst.

Pivot vs. Push Through

Pivot when:

You've been building for 4+ weeks and can't explain the value in one sentence
You're the only person who would use this, and even you don't use it daily
The technical foundation keeps fighting you (wrong framework, wrong platform)

Push through when:

The idea is clear but execution is hard
You have a working prototype and the problem is polish, not product-market fit
Other people get excited when you show them, even if the UI is rough

The distinction: pivoting is about the product being wrong. Pushing through is about the work being hard. Don't confuse the two. Hard work on the right product is the job. Hard work on the wrong product is waste.

Part 3: The Stack Checklist

Everything you actually need to ship an iOS app solo. Nothing you don't.

Required (non-negotiable)

Item	What I Use	Why
Apple Developer Account	$99/year enrollment	You cannot submit to the App Store without it
Mac with Xcode	Xcode 26 (latest stable)	The only official way to build iOS apps
Physical test device	iPhone running latest iOS	Simulator misses real-world performance, haptics, camera
Source control	Git + GitHub private repos	If your laptop dies, your code survives
Project generation	XcodeGen	Eliminates .xcodeproj merge conflicts, keeps project config in YAML

Strongly Recommended

Item	What I Use	Why
AI coding assistant	Claude Code (CLI)	Faster iteration on boilerplate, tests, refactors
Design reference	Figma (free tier) or paper sketches	Having a target prevents wandering UI decisions
Privacy policy generator	Free template + host on your site	Required for App Store submission. Not optional
Support email	Dedicated email (not personal)	Apple requires a support URL. Use a simple mailto link
Analytics	App Store Connect only	Free, built-in, no SDK to maintain
Crash reporting	Xcode Organizer	Free, already there, no third-party dependency

Only If Your App Needs It

Item	When	What I Use
In-App Purchases	Monetization beyond ads	StoreKit 2 (native, no third-party SDK)
Ad network	Freemium model	Google AdMob via SPM
Health data	Fitness/health tracking	HealthKit (native)
Encryption	Sensitive user data	CryptoKit AES-256-GCM (native)
Widgets	Home screen presence	WidgetKit (native)
Push notifications	Re-engagement	UNUserNotificationCenter (native, local only)

What You Don't Need

A backend server (unless your app requires cloud sync)
A database service (SwiftData handles local persistence)
A CI/CD platform (manual process works fine for solo)
CocoaPods or Carthage (SPM handles everything)
A project management tool (a text file with checkboxes is enough)
A landing page builder (your portfolio site works, or a single static page)

Part 4: The Pre-Submission Marketing Checklist

Do all of this BEFORE you hit "Submit for Review." Not after. Not "when I have time." Before.

App Store Metadata

App name (30 character limit, include one keyword if possible)
Subtitle (30 characters, different keywords than the name)
Description (first 3 lines visible without "more," make them count)
Keywords field (100 characters, comma-separated, no spaces after commas, no duplicates of name/subtitle words)
Category and secondary category selected
Age rating questionnaire completed

Screenshots

6.7" (iPhone 15 Pro Max / iPhone 16 Pro Max size, required)
6.5" (iPhone 14 Pro Max size, recommended for coverage)
iPad screenshots if your app supports iPad
First screenshot communicates the core value in under 2 seconds
Screenshots show the real app, not mockups
Text overlays are concise (5 words or fewer per screen)
Rich backgrounds, not flat colors (gradient, atmospheric, layered)
Complete device frames (never cut off the phone)

Privacy and Legal

Privacy policy URL (hosted and accessible, not a dead link)
Support URL (can be a mailto link to your support email)
App Tracking Transparency declaration (even if you don't track, you must declare it)
Data collection declarations in App Store Connect (be accurate; Apple checks)
If using AdMob: ATT prompt implemented, IDFA usage declared

Technical

App icon exported at 1024x1024 (no alpha channel, no rounded corners)
Build tested on a physical device, not just simulator
All StoreKit products created in App Store Connect and tested in sandbox
Crash-free session on a clean install (delete app, reinstall, go through onboarding)
Dark mode tested (if supported)
Dynamic Type tested at largest accessibility size

Launch Prep

App Store Connect listing fully filled out and saved as draft
"Prepare for Submission" version created
Binary uploaded via Xcode (Product > Archive > Distribute)
TestFlight build verified (install from TestFlight, not Xcode)
Release type chosen: Manual or Automatic after approval
Promotional text ready (this can be changed without a new review)

The One Rule

Ship something real. Not a tutorial project. Not a clone. Something you'd actually use, solving a problem you actually have, built to a standard you're not embarrassed by.

Everything in this playbook exists to support that one rule. The frameworks, checklists, and decision trees are just guardrails. The work is still yours to do.

Nobody is coming to build it for you.