How do you build apps while working a full-time job?

The key is eliminating unnecessary work. Use a stack that removes backend maintenance (SwiftData + CloudKit for sync, StoreKit 2 for payments, local notifications only), target only the latest OS to avoid compatibility code, ship the smallest useful version first, and only build things you personally use so motivation stays high. With 10-15 hours a week, every hour saved on infrastructure is an hour spent on features.

Can you make money as an indie app developer on the side?

Some indie apps generate decent side income, but most won't replace a full-time salary. The real value compounds over time — each app teaches patterns that make the next one faster (SwiftData, StoreKit, scoping skills). Having a portfolio of shipped apps you built and use yourself is worth more than the revenue alone.

What tech stack should I use for a solo iOS app?

For solo developers with limited time, SwiftData + CloudKit eliminates backend infrastructure entirely — Apple handles the database, sync, and servers at zero cost. StoreKit 2 handles billing with minimal setup. Local notifications avoid the need for push servers. This stack lets you focus entirely on building features instead of managing infrastructure.

Should I support older iOS versions in my indie app?

Targeting only the latest iOS version (e.g., iOS 26 exclusively) means no backwards compatibility code, no conditional API checks, no multi-version testing. You lose some potential users, but users who keep devices updated tend to be more engaged and more willing to pay. The cleaner codebase ships faster with fewer bugs.

How I Ship 5 Apps as a Solo Developer with a Full-Time Job

I work full-time as a senior engineer. Nights and weekends, I run Torres Labs and build apps. Five so far: Mati (calendar), Pressed (compression), Fescue (lawn care), Forecastly (cash flow), and TechSheet (vehicle maintenance).

I’m not writing this to sell you a productivity system or tell you to wake up at 5am. I’m writing it because people ask how I ship anything at all with limited time, and the honest answer is less about hustle and more about the decisions that let me skip work I don’t need to do.

Build things you actually need

Every app I’ve shipped started as a problem I was personally annoyed by. Mati exists because I didn’t want to pay $40/year for a calendar app. TechSheet exists because I was tracking my car maintenance in a Notes app like an animal. Fescue exists because I kept forgetting when I last fertilized my lawn.

This matters for two reasons. First, you already understand the problem deeply — no customer interviews, no guessing about what features matter. You’re the customer. Second, motivation is easy when you’re building something you’ll use tomorrow. Side projects die when the builder loses interest. I don’t lose interest in apps that are open on my phone every day.

Make boring infrastructure decisions

The single biggest unlock for shipping apps with limited time is choosing a stack that eliminates backend work. For my iOS apps, that means:

SwiftData + CloudKit for data and sync. Apple handles the database, the sync engine, the conflict resolution, and the server infrastructure. I don’t run a single server for Mati, Fescue, or TechSheet. My infrastructure cost for those apps is zero.
StoreKit 2 for subscriptions. Apple handles billing, receipts, and subscription management. I define two products and I’m done.
Local notifications only. No push notification server, no background task scheduler. The app checks what’s due on launch and schedules local notifications. It’s simple and it works.

Every hour I don’t spend debugging a deploy pipeline or provisioning a database is an hour I spend building features. When your total available time is maybe 10-15 hours a week, that tradeoff is everything.

Target the latest OS only

All of my apps target iOS 26 exclusively. No backwards compatibility with iOS 17 or 18. This is a deliberate choice that most people think is crazy, but here’s what it buys me:

I get to use the latest APIs without conditional checks. No if #available blocks scattered through the codebase. No testing on three different OS versions. No worrying about deprecations. The code is cleaner, simpler, and faster to write.

Yes, I lose some potential users. But the users who keep their devices updated tend to be more engaged and more willing to pay for apps. And practically speaking, by the time most people find my apps, they’re on the current OS anyway.

Ship small, then iterate

The first version of every app I’ve shipped was embarrassingly minimal. TechSheet v1 was a service log and nothing else — no OBD-II, no document storage, no reports. Mati launched without tasks integration or calendar sets. Pressed started with basic image compression and added video later.

When you have limited time, scope is your enemy. I’d rather ship something useful in three weeks than plan something ambitious that takes six months and never launches. Once the app is live, real usage tells you what to build next. It’s almost never what you would have guessed.

Bring in help where you’re weak

For TechSheet, I brought on two partners. They handle social media and customer support — two things I’m bad at and don’t enjoy. I stay focused on building the product. It’s a small team, but it means I’m not spending my limited hours writing Instagram captions.

You don’t need partners for every project. But be honest about what you’re bad at and find ways to not do those things.

The business reality

I’m not going to pretend this is a path to quitting your day job. Most indie apps don’t generate life-changing revenue. Some of mine make decent side income. Some barely cover the developer account fee.

But here’s what I’ve learned: the portfolio compounds. Each app teaches you something that makes the next one faster. The SwiftData patterns I built for Fescue carried directly into TechSheet. The StoreKit integration I figured out once works across every app. The muscle of scoping, building, and shipping gets stronger each time.

And there’s something satisfying about having a body of work that’s yours — apps in the store that people use, that solve real problems, that you built because you wanted them to exist. That’s worth more to me than the revenue.

If you’re thinking about starting

Pick a problem you have. Build the smallest thing that solves it. Use whatever stack eliminates the most busywork. Ship it before you think it’s ready. Then decide if it’s worth continuing based on whether you and anyone else actually use it.

That’s the whole system. It’s not complicated. The hard part is protecting the time to do it — and being honest about what you can realistically build with the time you have.