Shipping Solo: What Publishing Your Own Apps Teaches You

Shipping solo means taking an app from an empty folder to a live App Store and Google Play listing entirely on your own — acting as product manager, designer, engineer, marketer, and support desk at once. It is arguably the fastest way for a developer to grow, because the market delivers feedback no manager can: in downloads, refunds, and store-review rejections. The work that ambushes most engineers is not the code. It is store review, privacy policies and data-safety forms, in-app purchase configuration, App Store Optimization, onboarding flows, paywall placement, and analytics. Modern tools make one-person shipping feasible: Expo and EAS handle builds and submission, Supabase provides a backend without servers, and RevenueCat reduces cross-platform subscriptions to a single SDK. This article is the honest version of what publishing my own apps taught me, and why it made me a better team engineer.

For most of my career, someone else handled the parts of software that are not code. A product manager decided what to build. A designer handed me screens. A marketing team worried about whether anyone would ever download the thing. My job was to take a ticket, write good code, and move on. It felt like the whole job. It was not even half of it.

You only discover the other half when you publish your own app, alone, from an empty folder to a live listing on the App Store and Google Play. Suddenly you are the product manager, the designer, the marketer, the support desk, the finance person, and the engineer, all in the same afternoon. I have now shipped several apps this way, and I am convinced it is the single fastest way to grow as a developer. Not because the code is harder, but because everything around the code is so much harder than I ever gave it credit for.

This is the honest version of what solo shipping teaches you. Not the highlight reel, the actual grind.

Why is shipping end to end the fastest way to grow?

When you work inside a team, the system protects you from your own blind spots. If you build something that does not make sense for users, a PM catches it. If your feature is technically clever but pointless, someone in a planning meeting quietly kills it. You get to be a specialist, and specialization is comfortable.

Shipping alone strips that protection away. Every decision is yours, and every decision has consequences you personally feel a week later. Build the wrong feature and you waste your own nights. Pick the wrong monetization model and you make zero dollars. There is no one to blame and no one to hide behind, and that pressure compresses years of learning into months. You learn what actually matters because the market tells you directly, in downloads and refunds, instead of a manager telling you in a review cycle.

Working on a team teaches you how to build software well. Shipping alone teaches you what is worth building at all.

How do you scope an MVP you can actually finish?

The first app I tried to ship solo never shipped. I scoped it like a funded startup: accounts, social features, a settings screen with twenty toggles, offline sync, a beautiful onboarding flow. Six weeks in, I was exhausted and nowhere near a store submission. The lesson landed hard. When you are one person, the enemy is not competition, it is your own ambition.

A finishable MVP is smaller than you think and probably smaller than your ego wants. The question I now ask before writing any code is simple: what is the single thing this app does that someone would open it for? Everything that does not directly serve that one thing gets cut, or parked in a note for version two that may never come.

The apps I actually shipped were embarrassingly simple compared to what I first imagined. That is the point. A shipped simple app teaches you infinitely more than an unshipped ambitious one.

What are the unglamorous parts nobody teaches you?

Here is the gap between tutorials and reality. Every course teaches you how to build a screen. Almost none of them teach you what happens after the code is done, which is where most of the real work lives. This is the stuff that ambushed me.

App store review is its own project

Getting your build to compile is not shipping. Apple and Google both review your app, and both will reject it for reasons that have nothing to do with whether it works. My first submission bounced because my privacy policy URL returned a 404 for a fraction of a second during their check. Another was rejected because a paywall did not clearly explain what the subscription unlocked. Review is a relationship with a reviewer who has seen ten thousand apps and has no patience, and you have to design for that person, not just for your user.

Privacy policies, data disclosures, and the paperwork

You need a privacy policy hosted at a stable URL before you can submit. You need to fill out App Privacy details on Apple and the Data Safety form on Google, honestly describing what data you collect and why. If you use analytics or ads, that is data collection, and you have to declare it. This is boring, it is legally meaningful, and no one warns you it exists until the submission form demands it.

In-app purchases are a configuration nightmare

Setting up in-app purchases is not a few lines of code. It is creating products in App Store Connect and Google Play Console, filling in tax and banking information, agreeing to paid apps contracts, waiting for products to propagate, testing with sandbox accounts that behave differently from production, and handling the dozen edge cases of restore, refund, upgrade, and expiration. This is where RevenueCat earned my loyalty. It sits between your app and both stores, gives you one clean SDK, and handles receipt validation and subscription status so you are not writing store-specific purchase logic twice. It turned the single most painful part of shipping into something manageable.

Screenshots, ASO, and the store listing

Your store listing is your entire marketing funnel for organic users, and it is almost all design. You need screenshots in exact device sizes, ideally with captions that sell the benefit rather than just showing the UI. You need a title and subtitle chosen for App Store Optimization, because the keywords in them decide whether anyone finds you. I underestimated this completely on my first app and used raw screenshots with no captions. Downloads were flat. On the next app I treated the listing as seriously as the code, and it changed the numbers.

Onboarding, paywalls, and analytics

Users decide in the first thirty seconds whether your app is worth their time. Onboarding is not a formality, it is where you either earn a user or lose them forever. The paywall is where you either earn money or do not, and its wording, timing, and design matter enormously. And without analytics you are flying blind: you will not know where users drop off, which onboarding step loses people, or whether anyone even reaches the paywall. Instrumenting these was the difference between guessing and knowing.

How do indie apps actually make money?

Two ways to make money from a phone app dominate everything else: ads and subscriptions. Both are worse than the internet makes them sound, in different ways.

Ads pay almost nothing at small scale. To make meaningful money from ads you need serious volume, tens or hundreds of thousands of daily active users, and as a solo developer you almost certainly do not have that at launch. Ads also degrade the experience, which hurts retention, which shrinks the very audience the ads depend on. For most indie apps, ads are a rounding error that costs you goodwill.

Subscriptions are where the real money is, but they demand real ongoing value. People will not pay monthly for something they open twice. A subscription is a promise that your app keeps being worth paying for, which means you are signing up for maintenance and improvement, not a one-time build. The upside is that even a small number of subscribers can matter, because the revenue compounds. A hundred people paying a few dollars a month is a genuinely different outcome than a hundred thousand ad impressions.

Doing design and marketing when you are just an engineer

I am an engineer. For years I told myself I was not a designer and not a marketer, as if those were fixed identities. Shipping solo forced me to admit that these are skills, not talents, and skills can be learned to a useful level even if you never become world class.

On design, I stopped trying to be original and started stealing shamelessly from apps that already work. Good spacing, a restrained color palette, one accent color, consistent corner radii, and system fonts get you eighty percent of the way to something that looks professional. You do not need to be a designer to avoid looking amateurish, you just need taste and restraint, and both improve by copying good examples until the patterns become instinct.

On marketing, the reframe that helped me was to stop thinking of it as selling and start thinking of it as being findable and being clear. A clear one-line description of what the app does, an honest listing, a handful of posts explaining the problem it solves, and showing up where your potential users already hang out. That is not manipulation, it is just making sure the people who would genuinely benefit can actually find you. It is uncomfortable for an engineer at first, and then it becomes just another part of the craft.

You do not have to be a great designer or marketer to ship. You just have to stop using not being one as an excuse.

Rejections, low downloads, and the emotional part

Nobody prepares you for the feeling of launching an app you poured a month into and watching it get eleven downloads. That happened to me. The store review rejections sting because they feel like a gatekeeper telling you your work is not good enough. The low downloads sting more, because they feel like the market itself shrugging.

What I eventually understood is that both are information, not verdicts. A rejection is a checklist item you missed, fixable in an afternoon once you stop taking it personally. Low downloads mean either the wrong people saw it, or the listing did not communicate the value, or the thing genuinely does not solve a real enough problem. Each of those is diagnosable and each points to a different fix. Treating a disappointing launch as a data set instead of a judgment is the difference between quitting and iterating.

The apps that eventually did well were almost never right on the first launch. They got better because I shipped, watched, learned, and shipped again. Solo development is a long game of small corrections, and the developers who win are simply the ones who did not stop after the first quiet launch.

How does shipping solo make you a better team engineer?

Here is the part that surprised me most. Shipping my own apps made me dramatically better at my day job, in ways that have nothing to do with the specific technologies involved.

A specialist who has only ever done their one slice of the pipeline is valuable. But an engineer who has felt the whole pipeline, who knows what happens to their code after it ships and what it costs to acquire the user who runs it, thinks about problems differently. They make decisions with the whole picture in mind. That perspective is genuinely hard to teach in a standup, and shipping solo is the most direct way I know to earn it.

Which tools make solo shipping possible?

A decade ago, shipping a polished mobile app alone would have meant learning two native platforms, running your own servers, and building payment infrastructure from scratch. Today a small stack of tools removes most of that overhead, and choosing them well is part of the skill.

Expo and EAS for building and shipping

Expo lets you build for iOS and Android from one React Native codebase without touching Xcode or Android Studio for most work. EAS, its build and submit service, compiles your app in the cloud and pushes it straight to the stores. As a solo developer, not owning a Mac build farm or fighting native toolchains is the difference between shipping and giving up. Over-the-air updates also let me push fixes without waiting on another review cycle for small changes.

# Build and submit an iOS release entirely from the cloud
eas build --platform ios --profile production
eas submit --platform ios --latest

Supabase for the backend

When an app does need a backend, Supabase gives you a Postgres database, authentication, storage, and instant APIs without you standing up and maintaining servers. For a solo developer, the value is not just the features, it is not having a backend to babysit at two in the morning. Row-level security lets you keep data safe without writing a whole authorization layer by hand.

RevenueCat for monetization

I mentioned it above and it is worth repeating: RevenueCat is the tool I would least want to give up. It abstracts the entire mess of App Store and Play Store purchasing behind one SDK, handles receipt validation and subscription state on its servers, and gives you a dashboard of revenue and conversion that would take weeks to build yourself. Checking whether a user is subscribed becomes a single call instead of a platform-specific ordeal.

import Purchases from 'react-native-purchases';

// One call tells you whether to unlock premium, on either platform
const info = await Purchases.getCustomerInfo();
const isPro = typeof info.entitlements.active['pro'] !== 'undefined';

None of these tools write your app for you. What they do is remove the undifferentiated heavy lifting, the parts that are hard without being valuable, so that one person can plausibly cover the whole surface of shipping a product. That leverage is what makes solo indie development feasible at all in 2026.

Key takeaways

If you have never shipped something with your name on it and nobody else to catch your mistakes, do it once. Pick something small, take it all the way to a live listing, and pay attention to how much you did not know you did not know. It is humbling, it is occasionally miserable, and it will make you better at this than any tutorial ever could.