Small apps actually ship

A big idea has a hundred features standing between you and launch, and you will build most of them before you ever learn whether anyone wants the thing at all. A small app has one clear job. You can build it, ship it, and get real-world feedback in days or weeks instead of years. Shipped-and-learning beats unshipped-and-perfect every single time, because an app in the store is generating information and an app on your hard drive is generating nothing but anxiety. The faster you ship, the faster reality starts correcting your assumptions.

Each app is a cheap bet

Think like a portfolio, not an all-in wager. Every small app is an inexpensive bet on a hypothesis: “people want private, offline transcription,” “people want a cute endless arcade game.” Most bets return little. Some return a lot. The math of this is what makes it work, you only need a couple to hit, and the only way to find which ones hit is to place enough bets. You can only afford to place many bets if each one is small, which is the entire argument in one sentence.

A big-idea founder makes one bet with everything. If they are wrong about the market, and most people are wrong about the market, they find out after years and at enormous cost. A portfolio builder is wrong constantly, cheaply, and quickly, and that turns out to be a massive advantage.

Learning velocity compounds

Every app teaches you something the last one could not: a new market, a new technical constraint, a marketing channel that works, a kind of user you did not understand before. Ship ten small apps and you have run ten experiments across product, distribution, and craft. Spend the same time on one big app and you have run exactly one. The person who ships ten learns ten times as fast, and in a game where nobody knows the right answer in advance, learning speed is the edge. It is the whole edge.

Lower risk, faster feedback

When a small app flops, you have lost a couple of weeks, shrugged, and moved on, a little wiser. When a big app flops, you have lost years and possibly your savings, and the lesson cost a fortune. Small apps fail cheaply and quietly, which means you can afford to be wrong, and being wrong repeatedly and cheaply is precisely how you eventually get it right. Risk that would be reckless on one giant bet is perfectly reasonable spread across many tiny ones.

Skills stack across the portfolio

The apps are not really separate projects. The auth flow, the on-device inference, the store listing, the privacy architecture, the analytics setup, each one carries directly into the next. My offline AI chat app and my on-device transcription app share a whole thesis and a lot of hard-won technique, and the second one was far faster to build because the first one taught me the pattern of running models on a phone. Even a casual game sharpened instincts about feel and polish that followed me right back into the serious tools. Nothing is wasted. The portfolio compounds into a body of skill that no single project could have built.

A niche emerges that you did not plan

Build enough small things and a thread quietly appears. Mine turned out to be on-device, privacy-first AI, taking capabilities people assume require the cloud and proving they fit in your pocket. I did not start with that thesis. I found it by shipping, by noticing which of my bets resonated and why. One big idea locks you into a guess you made before you knew anything. A stream of small ones lets the right direction surface from real results, which is a far more reliable way to find a direction worth committing to.

The honest trade-off

I want to be fair about the cost. Small apps will not make you a unicorn overnight, and each one individually looks unimpressive next to a grand vision. If your single goal is to build one world-changing company, this is not your path, and you should ignore me. But if your goal is to keep shipping, keep learning, build real income across several products, and dramatically raise your odds of stumbling into something that genuinely takes off, then a portfolio of small, fast bets beats betting the farm on one idea you cannot yet validate.

It also fits the reality of being one person. You can hold a small app entirely in your head, ship it without a team, and support it without it consuming your life. Ten of those is a sustainable practice. One enormous thing is a gamble that can quietly eat years.

Small is not the same as careless

To be clear, building small is not building careless. Each app still earns real design, real polish, and an honest privacy stance, because a portfolio of sloppy apps just fails ten times instead of once. Small is a statement about scope, not about standards. The discipline is to ship something genuinely good with a deliberately narrow surface area and then stop, rather than letting one app quietly sprawl into the very multi-year commitment you were trying to avoid. Done right, each small app is complete and proud of itself, not a half-built fragment of a bigger dream. That is the line that separates a focused portfolio from a graveyard of abandoned prototypes, and it is the part most people get wrong when they hear “build small.”

Ship small, ship often, and let traction tell you where the big idea actually was all along. For the part right after shipping, finding the first people who care, see getting your first 100 users with no budget.

The two accounts and what they cost

• Apple Developer Program: $99 per year, recurring.
• Google Play Console: $25, one time.

So budget about $124 for your first year to publish on both stores, and $99 a year after that. That is entirely separate from anything you spend building the app. These fees are cheap. The real cost, as you will see, is time, not money.

Apple Developer Program (iOS)

1. Create an Apple ID with two-factor authentication enabled. You need to be 18 or older to enroll.
2. Enroll in the Apple Developer Program at developer.apple.com.
3. Choose Individual or Organization:
   • Individual is the fastest path, and your legal name appears as the seller on the store.
   • Organization shows a company name as the seller, but you first need a D-U-N-S number for the business. It is free to request, but verification can take several days to a couple of weeks, so start it early if you want to publish under a company.
4. Pay the $99 and wait for approval, usually quick but occasionally a day or two.

You will also need a Mac with Xcode to build, sign, and submit your app, or a cloud build service such as Expo EAS or Codemagic if you use a cross-platform framework and want to avoid buying a Mac. Apple’s signing system (certificates and provisioning profiles) is genuinely confusing the first time, so budget an afternoon just to get a build onto a real device. Your listings, builds, and submissions are all managed in App Store Connect, and TestFlight, built into App Store Connect, is how you distribute beta builds to testers before going live.

App review: Apple reviews every app and every update, typically within a day or two, and it is the stricter of the two stores. Read the App Review Guidelines before submitting. The usual rejections are broken features, missing or inaccurate privacy details, misleading screenshots, and the dreaded “this app does not provide enough lasting value.” Expect a rejection or two on your first app, respond politely in the Resolution Center, fix what they flag, and resubmit. It is a normal part of the process, not a catastrophe.

Google Play Console (Android)

1. Use or create a Google account.
2. Go to play.google.com/console and register as a developer. Pay the one-time $25.
3. Choose a personal or organization account. Organizations need a D-U-N-S number here too.
4. Complete identity verification. Google now requires this for all developers: legal name, address, phone, and sometimes a government ID. Start it early, because it can take a few days and you cannot publish until it clears.

The gotcha that surprises everyone: for new personal developer accounts, Google requires you to run a closed test with at least 20 testers for 14 continuous days before you can promote the app to production. That clock is unavoidable and it does not start until you actually have testers opted in, so line them up early, friends, a community, a dedicated testing group, and start the closed test the moment you have a working build. Treat those 20 testers as a real task on your launch checklist, not an afterthought. Organization accounts are currently exempt from the 20-tester rule, which is one reason some people choose that route despite the extra D-U-N-S step.

You will also fill out a Data safety form and a content rating questionnaire. Google’s review is generally faster and more lenient than Apple’s, but it still reviews apps, and updates can take anywhere from a few hours to a few days.

What both stores require from you

Before you can publish on either, have these ready, ideally prepared during development rather than scrambled together at the end:

• A clear app icon and screenshots for each required device size.
• A title plus short and full descriptions. This is also where App Store Optimization begins, so the words are worth real thought.
• A privacy policy URL. Both stores require one, even for a simple app. This is one practical reason a small website is handy: somewhere stable to host the policy where it will not disappear.
• A content and age rating questionnaire.
• Data disclosures: Apple’s “App Privacy” labels and Google’s “Data safety” form. Answer honestly about exactly what you collect. If your app runs on-device and collects nothing, say so loudly, because “we collect no data” is a genuine selling point that the store will display to users.

A sane order to do this in

1. Register both developer accounts on day one of the project, not the week you want to launch. Verification and D-U-N-S delays are the silent killers of launch dates.
2. If you are taking the organization route on either store, start the D-U-N-S request immediately, since it is the longest pole in the tent.
3. For Google, start the 20-tester closed test as early as you have a build, so the 14-day clock runs in the background while you finish the app instead of after.
4. Prepare your store assets, icon, screenshots, descriptions, privacy policy, in parallel with development, not after.
5. Submit to Apple expecting a possible rejection, and to Google expecting the testing requirement, so neither one surprises you.

The takeaway

Building is the fun part, but the publishing setup is where first-timers lose weeks they never budgeted for. The accounts themselves are cheap, about $124 for year one across both stores. The real cost is time: identity verification, D-U-N-S numbers, Apple’s review, the signing setup, and Google’s 20-tester rule. None of it is hard, but all of it has a clock, and the clocks run in serial if you start late and in parallel if you start early. Kick off the slow, bureaucratic pieces at the very beginning of the project, and a multi-week surprise turns into a quiet background task that is already done by the time your app is ready.

Once you are live, the next problem is getting found, which is where App Store Optimization and getting your first 100 users with no budget take over.

Free

A free app with no monetization is not a business model, it is a gift. That is fine if the goal is portfolio, learning, audience, or a funnel to something else. Free maximizes installs because it removes every ounce of friction, which makes it a legitimate strategy when your real goal is reach rather than revenue.

The trap is drifting into free by default because pricing felt scary, then resenting the work when nobody pays. Choose free deliberately, knowing what you are trading away. If you genuinely want income from this app, free with no plan attached is usually the wrong starting point.

Paid up front

The user pays once to download, then owns it forever. This model is honest and simple: no ads, no nagging, no subscription guilt. People who pay up front tend to be higher-quality users who actually wanted the thing, and your reviews often reflect that.

The downside is brutal install friction. A price tag, even a small one, cuts your downloads dramatically compared to free, because most people will not pay for something they have not tried. Paid up front works best when the value is obvious before installing, when you have a clear niche audience who already wants the solution, or when “no ads, no subscription, no tracking” is itself the selling point. For a focused utility with a clear job, a one-time price can be a feature, not a barrier.

Freemium

The app is free to download, with a paid upgrade that unlocks more. This is the dominant model for a reason: it removes install friction like free, while still creating a path to revenue like paid. People try before they buy, which suits anything whose value is hard to convey from a store listing alone.

Freemium lives or dies on where you draw the line. Give away too little and the free tier feels like a crippled demo that generates angry reviews. Give away too much and nobody ever upgrades because they already have everything they need. The art is making the free tier genuinely useful and complete for casual users, while the paid tier solves the problems that only your most engaged users have. A good test: would you be happy if someone used the free version forever and told their friends? If yes, you have probably drawn the line well.

Subscription

The user pays repeatedly, monthly or yearly, for ongoing access. Subscriptions produce the best revenue per user and the most predictable income, which is why so much of the industry has moved to them. For an app with genuine ongoing value, a service that keeps delivering, content that keeps updating, costs that recur, a subscription is fair and sustainable.

But subscriptions carry real obligations and real risk. Users increasingly resent subscription fatigue, and they will punish you in reviews if your app does not clearly justify a recurring charge. The honest question is: does this app deliver continuous value, or is it a one-time tool wearing a subscription costume? A flashlight app should not be a subscription. A service with ongoing server costs or constantly refreshed content reasonably can be. If you cannot articulate why the value recurs, neither can your users, and they will cancel.

On-device apps and the cost question

One factor people forget: your costs shape your honest pricing options. If your app runs on a server, every user costs you money every month, which pushes you toward subscriptions just to stay alive. If your app runs entirely on-device, with no servers to pay for, you have far more freedom. You can give it away, charge once, or offer a small upgrade, without a recurring bill forcing your hand. That freedom is one of the quiet advantages of building on-device, which I wrote about in why I build small apps.

How to actually decide

Work backward from two questions. First, where does the value live: is it obvious before install, revealed during use, or delivered continuously over time? Second, what does each user cost you to serve? Map those answers onto the models:

• Value obvious before install, low cost to serve: paid up front can work.
• Value revealed during use: freemium, with a generous free tier.
• Value delivered continuously, real ongoing costs: subscription, clearly justified.
• Goal is reach, not revenue, costs are near zero: free, on purpose.

You can change it later

Pricing is not a permanent tattoo. Many successful apps started free to build an audience, then introduced a paid tier once they understood who their users were and what those users valued most. Others launched paid and moved to freemium when they realized the price was the only thing standing between them and a much larger base. You will almost certainly get the first guess somewhat wrong, because you are pricing before you have the data that pricing decisions really need. That is fine and expected. Ship a reasonable model, watch how people actually respond, and adjust with what you learn. The goal is to start with something defensible, not to agonize forever toward a perfect number that does not exist yet.

The honest closing

Whatever you pick, price with respect for the user. The fastest way to tank an app is a pricing model that feels like a trap: a free tier that is secretly useless, a subscription for a one-time tool, an upgrade nag every thirty seconds. Pick the model that matches where your value actually lives, make the deal obvious and fair, and let people feel good about paying you. Good pricing is not extraction. It is an honest exchange where both sides come out ahead, and apps built on that hold up far longer than ones built on dark patterns. When you start charging, revisit getting your first 100 users, because price and acquisition are two halves of the same decision.

Start with a problem, not a feature

The strongest ideas begin with a problem you have personally felt or watched someone struggle with, not with a cool feature looking for a use. “Wouldn’t it be neat if” is a weak foundation. “I keep running into this specific annoyance and so do others” is a strong one. Before anything else, write down the problem in one plain sentence, and the specific person who has it. If you cannot, that is your first signal to slow down.

Check that the problem is real and shared

A problem you have is a hypothesis, not a market. The cheapest validation is finding out whether other people have it too, and you can do that without writing any code:

• Search where people complain. If your problem is real, people are already asking about it in subreddits, forums, and reviews of existing apps. Read those threads. The language people use is gold, both for confirming demand and for your future store listing.
• Read the one-star and three-star reviews of apps adjacent to your idea. Those reviews are a free list of unmet needs and frustrations, written by people who care enough to complain.
• Ask people directly, but ask about their problem and their current behavior, never about your idea. “How do you handle X today?” tells you the truth. “Would you use an app that does Y?” only tells you people are polite.

Watch what people do, not what they say

This is the single most important validation skill. People will enthusiastically tell you they would use your app, download it, and pay for it, and then do none of those things. Stated intent is nearly worthless. Revealed behavior is everything. So look for evidence of what people already do: the workarounds they have cobbled together, the spreadsheets they maintain, the competing apps they actually pay for, the time they already spend on the problem. A clumsy workaround that people use every day is far stronger validation than a hundred people saying “great idea.”

Look at the competition honestly

Finding existing apps that solve your problem is good news, not bad. It means the problem is real enough that someone built for it and someone pays for it. A completely empty market usually means no demand, not untapped opportunity. The question is not “is there competition,” it is “can I serve some slice of these users meaningfully better, cheaper, simpler, more private, or more focused?” Read their reviews to find the gap they are leaving open, and aim there.

Build the smallest possible test

Once you believe the problem is real and shared, validate the solution as cheaply as possible before committing months. Options, in rough order of effort:

• A landing page describing the app with a “notify me” or store link, shared in the communities where your users already are. Do people click and sign up?
• A tiny prototype that does the one core thing, ugly and incomplete, put in front of ten real people. Do they reach for it again unprompted?
• A manual version where you solve the problem by hand for a few people first. If they will not accept the solution done manually for free, an app will not save it.

The goal is to get a real signal with days of effort, not months. You are trying to be wrong cheaply, fast, on purpose.

Know what a real signal looks like

Validation is not a single yes or no, it is a strengthening or weakening of your confidence. Strong signals: people use your rough version more than once without you nudging them, people get visibly frustrated when you take it away, people ask when they can have more, strangers share it. Weak signals: polite encouragement, “I would totally use this,” likes on a post, your friends being supportive. Learn to discount the weak signals ruthlessly, because they are the ones that feel best and mean least.

Do not let validation become procrastination

A warning, because this cuts both ways. Validation can curdle into an excuse never to ship. You will never get certainty, and at some point the only remaining test is to build the real thing and put it in the store. The point of validation is not to eliminate risk, it is to avoid the obvious, expensive mistakes before you commit. Once you have a real problem, evidence others share it, and a cheap test that pointed the right way, stop researching and start building. Shipping is itself the ultimate validation, which is exactly why I favor building small apps: each one is a real test in the market, not just a guess on a whiteboard.

A quick gut check before you commit

When you think you are done validating, run one last honest check. Can you name the specific person who has this problem, in one plain sentence? Can you point to evidence that they currently do something, anything, to solve it today? Did your cheap test produce actual behavior, not just encouragement? And would you, personally, reach for this thing if someone else had built it? If you can answer yes to all four with a straight face, you have done enough, and more research is just fear wearing a productive disguise. If you cannot, you have found exactly where your idea is still a guess, and that is the precise part to test next, before you write a single line of code.

The takeaway

Validation is the difference between betting weeks on a hunch and betting them on evidence. Find a real problem, confirm other people share it, watch what they actually do instead of what they say, study the competition for the gap, and run the smallest possible test before you commit. Do that, and most of your build time goes toward things people genuinely want, which is the whole game when your time is your scarcest resource.

Accept that you cannot do it all, then choose

The first mental shift is accepting that there is genuinely more to do than you can ever do. That sounds bleak, but it is freeing, because it means your job is not “finish everything,” it is “choose the few things that matter most right now and let the rest wait.” Solo founders who try to do everything do everything badly and burn out. The ones who last get ruthless about priority. On any given day, a small number of tasks actually move the needle. Find them, do them, and forgive yourself for the rest.

Protect maker time fiercely

Building requires long, unbroken blocks of focus, and those blocks are the most valuable and most fragile thing you have. An hour chopped into six pieces by notifications, emails, and “quick checks” produces almost nothing. So protect it. Pick the hours your brain works best, guard them like an appointment with your most important client, and do your hardest building then. Email, support, and admin can fill the shallow hours. Never spend your peak focus on shallow work, because that is the trade that quietly kills solo projects.

Batch the context switches

Every switch between coding, marketing, support, and admin has a hidden cost: your brain has to spin down one mode and spin up another, and that reload is expensive. Doing a little of everything all day means paying that tax constantly. Instead, batch. A block for building, a block for support and email, a block for marketing. One mode at a time. You will get more done in a batched four hours than a scattered eight, and you will end the day less fried.

Use the tools that compress the work

Solo founders win by getting more done per hour, and the right tools are a genuine force multiplier. AI coding assistants let you ship features in a fraction of the time, which is the whole premise of vibe coding. Boring, well-documented frameworks mean less time fighting your stack. Static hosting and on-device architecture mean no servers to babysit. Every choice that removes ongoing maintenance gives you back hours you can spend building or living. Optimize relentlessly for less to maintain, not more to manage.

Decide what not to build

Half of shipping is saying no. Every feature you add is a feature you have to build, test, support, and maintain forever, alone. The backlog will always be longer than your life, so the skill is cutting it down, not working through it. Keep a running list of ideas so they stop nagging you, then deliberately pick the smallest version that delivers the value, and ship that. Scope creep is the silent killer of solo projects, because there is no one to push back on you except you.

Manage energy, not just hours

Time management is really energy management. A burned-out hour produces nothing useful, while a fresh hour can move a project forward dramatically. So treat your energy as the real resource. Sleep is not a luxury you trade for productivity, it is the input that makes productivity possible. Take real breaks, get outside, and stop working before you are empty, not after. Pushing through exhaustion feels productive and is usually the opposite, because tired code is buggy code and tired decisions are bad decisions you pay for later.

Build a sustainable rhythm, not a sprint

The romantic image of the founder grinding eighteen-hour days is a great way to ship for three months and quit. Solo building is a long game, often years before a real hit, so the goal is a pace you can hold indefinitely. That means a rhythm with room in it: focused work, genuine rest, and a life outside the app. Consistency beats intensity over any timeline that matters. A steady four good hours a day, every day, for a year, will out-build heroic all-nighters that end in collapse.

Watch for the warning signs

Burnout does not announce itself politely. It creeps in as dread about opening your editor, resentment toward the project you used to love, shipping slowing to a crawl, and small problems feeling insurmountable. Learn your own signs and treat them as data, not weakness. When they show up, the answer is not to push harder, it is to rest, narrow your scope, and reconnect with why you started. The project can wait a few days. Your ability to keep going for years cannot be rebuilt as easily.

Separate the urgent from the important

A specific trap deserves its own warning: as a solo founder, the urgent constantly drowns out the important. Support emails, a small bug, a notification, these feel pressing and demand immediate attention, while the important work, building the next core feature or the marketing that will actually grow the app, has no deadline and so never screams for you. Days disappear into urgent trivia while the important work quietly stalls. The discipline is to schedule the important first, in your best hours, before the urgent has a chance to fill the day. Let some small urgent things wait, or drop them entirely. Almost none of them matter as much as they feel like they do in the moment, and protecting the important from the urgent is most of what good solo time management actually is.

The takeaway

Your time and energy are the entire budget of a solo company, so spend them like the scarce resources they are. Protect your focus, batch your modes, lean on tools that compress the work, say no to most things, manage your energy as carefully as your hours, and set a pace you can hold for the long haul. The founders who win solo are rarely the ones who worked the hardest in any given week. They are the ones who were still shipping, calmly, a year later, when everyone else had burned out and quit.

First: it is normal, and it is not personal

App review is a checklist process, often partly automated, run by a reviewer who spends a few minutes with your app against a long list of rules. A rejection is the system catching one item on that list, not a judgment that your app is bad or that you failed. Even experienced studios get rejected regularly. Internalize this early, because the developers who take rejections personally burn enormous energy on something that is just a normal step. Treat it like a failing test: information about what to fix, nothing more.

The common reasons apps get rejected

Most rejections fall into a handful of buckets, and knowing them helps you both fix and prevent:

• Bugs and crashes. The reviewer hit something broken. The most common and most avoidable cause, often from not testing on a real device or a fresh install.
• Broken or incomplete features. A button that does nothing, a sign-in that fails, a placeholder left in. Reviewers explore, and they find the cracks.
• Missing or inaccurate privacy information. Wrong privacy labels, a missing privacy policy, or data practices that do not match what you declared.
• Misleading metadata. Screenshots or descriptions that do not match what the app actually does. Stores take this seriously.
• Not enough value, or “spam.” Apple in particular rejects apps it considers too thin, too similar to others, or lacking lasting value. This one stings because it is subjective.
• Permissions without justification. Asking for the camera, location, or contacts without a clear in-app reason.

How to respond without spiraling

When the rejection lands, resist the urge to fire off a defensive reply. Instead:

1. Read the reason carefully. The notice tells you the specific guideline and usually the exact problem. Read it twice before reacting, because the real issue is often more specific than your first panicked reading.
2. Reproduce it yourself. If they say a feature is broken, go find the break. Often the reviewer is right and you simply missed it, and fixing it quietly is faster than arguing.
3. Fix it, then resubmit. For most rejections, the path is fix and resubmit, and the second review is usually faster.
4. If you genuinely believe they are wrong, reply politely with specifics. Stores have a resolution or appeal channel. Calmly explain, with steps or screenshots, why the app actually complies. Sometimes a reviewer misunderstood, and a clear, respectful explanation resolves it. Never be hostile, because a human reads your reply.

When you disagree, pick your battles

Sometimes you are right and the reviewer made a mistake, and a clear appeal is worth it. Other times you are technically right but it is faster and cheaper to just give them what they want, a clearer screenshot, an extra sentence of justification, a small change, than to win an argument that delays your launch by a week. Ask yourself whether being right is worth the time, and often the pragmatic move is to comply and move on. Save your appeals for the cases that genuinely matter to your app.

Prevent most rejections before you submit

The best way to handle rejections is to avoid them, and most are avoidable with a short pre-submission checklist:

• Test on a real device, from a fresh install, the way a reviewer will, not just in your comfortable development setup.
• Walk through every feature as if you had never seen the app, looking for anything broken, placeholder, or dead-ended.
• Make sure your privacy labels and policy are accurate and match what the app actually does. This trips up a huge share of submissions.
• Check that your screenshots and description match reality. No promising features that are not there.
• Justify every permission with a clear, visible reason inside the app.
• Read the relevant guidelines before you submit, especially for anything unusual your app does.

Doing this honestly before you submit catches most of what reviewers would catch, and turns the review into a formality instead of a coin flip. It also pairs naturally with the setup work in getting started publishing mobile apps.

Work with the process, not against it

It helps to reframe app review entirely. The reviewer is not your adversary, and the guidelines, frustrating as they sometimes are, mostly exist to keep the store safe and usable, which benefits you too. Developers who approach review as a fight, firing off angry replies and trying to sneak things past, have a worse time and often invite more scrutiny on future submissions. Developers who treat it as a collaboration follow the rules, communicate clearly, and fix what is flagged, building a track record of clean, compliant submissions that tends to make every later review go smoother. Your relationship with the store is a long one, spanning every update of every app you ship. Investing in being an easy, trustworthy developer to review pays off across years, not just on this one submission. Patience and professionalism here are not only virtues, they are strategy.

The takeaway

Rejections are a normal checkpoint, not a verdict. Read the reason calmly, reproduce the problem, fix it or appeal politely with specifics, and resubmit. Better still, run a real pre-submission walkthrough so most rejections never happen. The developers who ship steadily are not the ones who never get rejected, they are the ones who treat a rejection as a quick, routine fix rather than a crisis. Keep that mindset and the review process stops being scary and becomes just another step on the way to live.

The market has shifted

People are tired. Tired of being tracked, tired of data breaches, tired of finding out the free app was selling their information all along. That fatigue is now a buying signal. A meaningful and growing share of users will actively choose the app that respects them, and many will pay for it. Privacy has moved from a niche concern of the paranoid to a mainstream preference, and most apps have not caught up. That gap is where an indie developer can win, by offering the respectful option in a category full of extractive ones.

“We do not collect your data” is a feature

Walk through any app store category and notice how few listings can honestly say they collect nothing. Now imagine yours can. “Your data never leaves your device. No account, no tracking, no servers.” That is not a disclaimer, it is a headline. It is concrete, it is rare, and it speaks directly to a worry your user already has. The stores even display data practices prominently now, so “collects no data” becomes a visible badge that sets your listing apart from competitors burying a long list of collected data types.

On-device is how you make the promise real

The catch is that privacy as a strategy only works if it is true, and users and reviewers are increasingly able to tell. You cannot credibly promise privacy while quietly shipping data to your analytics provider. The cleanest way to make the promise real is architectural: build so the sensitive data never leaves the device in the first place. On-device AI makes this possible for whole categories that used to require the cloud, transcription, chat, classification, and more. I dug into the trade-offs in on-device vs cloud AI, and told the build stories in my offline chat app and my transcription app. When the architecture guarantees privacy, your marketing claim is just a description of how the app works, which is the only kind of privacy claim worth making.

Privacy simplifies your business

Here is the part people miss: choosing privacy does not just help your marketing, it makes your life as a solo builder easier. If you never collect user data, you have:

• No data to breach. The scariest operational risk in software, a leak of user data, simply cannot happen to data you never have.
• Less compliance burden. Many privacy regulations are fundamentally about how you handle collected personal data. Collect none, and a great deal of that complexity falls away.
• No data infrastructure to build and secure. No user database to protect, no pipeline to maintain, no servers logging sensitive information. That is less to build and less to break.

Privacy by architecture is not just ethical, it is operationally lighter, which matters enormously when you are a team of one with no security department to lean on.

The honest limits

Privacy as a strategy is not free or universal. Building on-device is harder than calling a cloud API, smaller local models are less capable than frontier ones, and some features genuinely require data to leave the device, syncing across devices, collaboration, anything inherently social. Be honest about where privacy fits and where it does not. The goal is not privacy absolutism, it is collecting nothing you do not truly need, being transparent about the rest, and defaulting to the device whenever you reasonably can. A privacy strategy you cannot actually keep is worse than none, because broken promises destroy the exact trust you were trying to build.

Trust compounds across your portfolio

The deepest payoff of privacy is trust, and trust compounds. A user who learns that your app genuinely respects them extends that goodwill to everything else you make. For a solo developer shipping a portfolio of small apps, a reputation for privacy becomes a durable asset that travels from one app to the next. People will try your new thing because they trust your old thing, and that trust is far cheaper to keep than to win again from scratch.

Communicate it without overclaiming

A privacy strategy is only as strong as how honestly you describe it. The temptation is to reach for absolute language, “100% private, totally anonymous, we can never see anything,” but absolutes invite scrutiny and are usually not quite true. Far better to be specific and verifiable: say exactly what stays on the device, exactly what, if anything, leaves it, and why. “Your audio is transcribed entirely on your phone and never uploaded” is a stronger claim than a vague “privacy-focused” badge, precisely because it is concrete enough to check. Users have been burned by privacy theater, companies that say the right words while doing the opposite, so they reward specificity and punish vagueness. Match your words exactly to your architecture, claim only what is literally true, and your privacy story becomes something people can trust rather than one more slogan they have already learned to ignore.

The takeaway

Treat privacy as a product decision, not a legal afterthought. The market increasingly rewards it, “we collect nothing” is a genuine feature, on-device architecture lets you make the promise real, and collecting no data quietly removes whole categories of risk and complexity from your business. For an indie developer competing against companies whose model depends on extraction, respecting your users is not just the right thing to do. It is a position those competitors structurally cannot copy, and that makes it one of the strongest strategies you have.