Ten years indie: the hard part was never shipping v1

An indie Mac and iOS developer just wrote up ten years of running a one-person software business. No launch story, no funding round, no acquisition. Just a decade of shipping, updating, and staying alive on platforms that changed underneath the work the whole time.

That's the part worth sitting with. Not the specific apps, not the revenue, but the fact that the interesting skill in indie development has almost nothing to do with writing code and almost everything to do with surviving ten years of someone else's decisions.

What actually changes in a decade

If you shipped an iOS app in 2016, here is a partial list of things that happened to you whether you wanted them to or not: three or four major Swift language revisions, the UIKit-to-SwiftUI transition, App Tracking Transparency rewriting how ads and analytics work, sign-in-with-Apple mandates, the EU forcing alternative payment and distribution rules, at least one Apple feature that quietly replaced something you were charging for, and several App Store review policy shifts that arrived with no warning and no appeal process worth trusting.

None of that shows up in a roadmap. It shows up as an afternoon you didn't plan for, repeated for ten years.

This is the actual skill of indie development: absorbing platform volatility without a team, without a legal department, and without the leverage to push back on any of it. Writing the app is maybe 20% of the job in year one and less than that by year five. The rest is maintenance against a moving target you don't control.

Why this gets underweighted

Most advice aimed at people who want to build an app focuses entirely on the launch. Validate the idea, build the MVP, get to the App Store, find your first hundred users. All of that is real, and all of it is front-loaded into a few months of a story that's going to run for years if it works at all.

The consensus failure mode is treating shipping as the finish line instead of the entry fee. A ten-year retrospective is valuable precisely because it's rare. Most public writing about indie development comes from people in year one or two, when everything still feels like momentum. The people who make it to year ten have quietly solved a different problem: how to keep a piece of software correct, compliant, and profitable while the ground moves every eighteen months.

Where faster app creation actually helps

There's a real temptation, watching AI tools compress the time to build a working app from months to days, to think the hard problem is finally solved. It isn't. It's a different problem than the one that determines whether you're still around in 2036.

What faster generation genuinely buys you is runway. If getting from idea to a working SwiftUI app with a real Xcode project takes a weekend instead of a quarter, you have more of your finite time and attention left over for the part that actually determines survival: watching what Apple changes, deciding which platform shifts are worth adapting to versus ignoring, and maintaining the discipline to keep a small app small instead of chasing every feature request into unsustainable complexity.

This is one of the reasons we built App Magic the way we did: an agent-planned spec, generated SwiftUI, and a real compiled Xcode project you own outright, rather than a walled garden you're renting. Getting to a working build faster doesn't remove the decade of maintenance ahead of you. It just means you spend that decade on the actual business instead of on the plumbing to get there.

The moat nobody markets

If there's a lesson in a decade of solo shipping, it's that the moat was never the code. Code is the easiest thing to replace, rewrite, or now, generate. The moat is showing up for ten years: keeping an app working through OS updates you didn't ask for, keeping customers through pricing changes you didn't want to make, keeping your own attention on one thing long enough for compounding to actually happen.

That's a much less exciting story than "I built an app in a weekend." It's also the only story that predicts whether you'll still be doing this in 2036. Anyone deciding how AI tools fit into their app-building workflow should ask a narrower question than "how fast can I ship." The better question is whether the tool frees up time for the maintenance decade, or just makes the first weekend more impressive without changing what comes after it.