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 problem with “free” transcription

Online transcription is rarely free in the way that matters. You pay with your audio. It gets uploaded, processed on someone’s servers, and frequently retained, sometimes to improve their models. For casual voice memos, maybe you do not care. For anything confidential, you absolutely should, because once audio leaves your device you have lost control of it forever.

The promise I wanted to make, and keep, was simple: your audio never leaves your phone, and the app never uploads your audio or transcriptions to any server. You can only make that promise credibly if the app genuinely has no server in the loop. So it does not. The absence of a backend is not a limitation here, it is the entire product.

Whisper on a phone

The thing that makes this possible is Whisper, the open speech-recognition model that is remarkably good across languages. Private Transcribe handles 99+ languages through multilingual models, which is a feature you simply could not offer affordably if every minute of audio had to round-trip through your own servers. On-device, languages are free.

The engineering challenge, like with any on-device AI, is fitting a capable model onto a phone without melting it. Whisper comes in sizes, and the size you choose is a direct trade between speed, accuracy, and storage. Rather than guessing for the user, I expose that choice as a quality tier:

• Tiny (75 MB): fastest, great for quick notes where rough accuracy is fine.
• Base (142 MB): a balanced default that suits most people.
• Small (466 MB): noticeably higher quality for important recordings.
• Medium (1.5 GB): professional-grade accuracy for when it really matters.

Someone on an older phone who wants speed picks Tiny. Someone transcribing a crucial interview on a newer device picks Medium and waits a little longer for a better result. Giving users the dial, with a sane default already selected, beats pretending one size fits everyone. It also respects that people know their own situation better than I do.

The UX around the model

The model is the engine, but the app is everything around it, and that wrapper is where most of the product work actually lives:

• Tap to record with real-time progress, so transcription feels responsive instead of like staring into a black box wondering if anything is happening.
• Local storage of every transcription, with search, so you can actually find that note from three weeks ago instead of scrolling forever.
• Sharing for the moments when you do want to send a transcript out, on your terms, by deliberate choice, never automatically.
• A clean dark interface that is comfortable for reading long blocks of text.

A surprising amount of “AI app” work is exactly this: making the model’s output findable, usable, and trustworthy. The intelligence is table stakes. The product is the wrapper around it, and a brilliant model behind a frustrating interface is a brilliant model nobody uses.

Handling the unglamorous edges

Real recordings are messy. People pause, they ramble, they record for forty minutes. A toy demo transcribes ten seconds of clean speech. A real app has to handle long audio without running the phone out of memory, show sensible progress on a file that takes a while, and never lose a transcription because the app got backgrounded. None of that is glamorous, and all of it is the difference between a demo and something people rely on.

Where vibe coding fit

The AI assistant was a genuine force multiplier on the surrounding app: the recording screen, the progress UI, the local database with search, the model download and storage management, the share flow. All of that is well-trodden territory it could scaffold quickly, which freed my attention for the parts that mattered.

What stayed firmly on me was the careful work: running Whisper efficiently on-device, handling longer recordings without choking on memory, and, most importantly, making sure the privacy promise was actually true end to end, with no sneaky analytics call quietly shipping audio off the device. When your entire pitch is privacy, the privacy has to be real, and that is precisely the kind of thing you verify by reading every line yourself, not by trusting generated code. I dug into that division of labor in my vibe coding toolkit.

Why on-device was worth the extra work

Building this on-device was harder than wiring up a cloud API would have been. There was no shortcut, no someone-else’s-server to quietly offload the difficult part onto. But that difficulty is exactly the moat. Anyone can wrap a transcription API in a weekend, and a thousand people already have, which is why those apps all blur together. Almost nobody ships something that genuinely keeps your audio on your phone, because it is more work and there is no usage to bill for at the end of it. The hard path turned out to be the defensible one, and the privacy promise that came with it is the precise reason a user would choose this app over the dozen cloud-based ones above it in the search results.

Lessons

• Privacy is a feature you can build a whole product around, but only if you mean it architecturally. “On-device” is a promise you have to earn in the code, not a sticker you slap on the listing.
• Expose the real trade-off. Speed versus accuracy is genuine and personal, so let users choose their model tier instead of deciding for them.
• The wrapper is the product. Search, storage, sharing, and a calm interface are what turn a model into something people open every day.

Private Transcribe is part of a clear pattern in what I build: take an AI capability people assume requires the cloud, and prove it can run privately in your pocket. If that idea interests you, I did the same thing for chat in how I built an offline AI chat app, and I wrote about the strategy behind it in why I build small apps.

Describe the outcome, not the implementation

Amateur prompt: “add a useState and a button that calls saveDraft.” Better prompt: “users should be able to save a draft and come back to it later.” Tell it what should be true for the user, and let it propose the implementation. You will often get a cleaner approach than the one you would have dictated, because you stopped constraining it to your first idea, and you stay focused on the product instead of the syntax.

The deeper reason this works: when you specify the implementation, you cap the quality at your own first guess. When you specify the outcome, the model can bring patterns you did not think of. You are hiring it for its breadth, so do not handcuff it to your narrowest instruction.

Give it the context it cannot see

The model does not know your stack, your conventions, or last week’s decisions unless you tell it. Most “the AI did it wrong” moments are really “I did not give it the context to do it right.” Up front, hand it:

• the language and framework, and the key libraries you are using,
• the relevant files or patterns to follow, for example “match how auth.ts does this,”
• any hard constraints, like “no new dependencies” or “this must work offline.”

Context is the cheapest quality improvement available. Thirty seconds of setup prevents an hour of fixing a technically-correct answer that ignored how your project actually works.

Work in small, reviewable slices

Ask for one thing at a time. A single function, screen, or behavior produces a diff you can actually read and verify. Giant “build the entire feature” prompts produce output you will either rubber-stamp, which is dangerous, or spend longer untangling than you would have spent writing it yourself, which defeats the point. Small slices keep you in control and keep the AI’s mistakes small and obvious instead of large and buried.

Show, do not just tell

If you have an existing pattern, point at it: “do this the same way the settings screen handles state.” Concrete examples constrain the model far better than adjectives ever will. “Make it clean” means nothing, because the model has no idea what clean means to you. “Follow the structure of this file” means everything, because now it has a target. When in doubt, give it an example to imitate rather than a quality to aspire to.

State the constraints and the “do not"s

Models default to adding things, more libraries, more abstraction, more cleverness. If you do not want that, say so explicitly: “do not add a dependency,” “do not change the public API,” “keep this component presentational.” A few clear guardrails prevent most of the scope creep that quietly bloats a project over time. The model is not going to guess your boundaries, so draw them.

Ask it to explain, not just produce

When a change is non-trivial, ask “why this approach?” or “walk me through what this does.” You get two wins. First, you catch flawed reasoning before it ships, while it is still cheap to fix. Second, you actually learn the code you are responsible for, instead of accumulating mystery. And if the explanation comes back hand-wavy or contradictory, that is a loud signal to slow down and look harder, because the model may be papering over something it does not actually understand either.

Treat the first output as a draft

The first response is a starting point, not a verdict. “Good, but handle the empty case.” “Simplify this, it is overengineered.” “That works, now do the boring version.” Iteration is the normal, expected path, not a sign you prompted wrong. Some of the best results come from three rounds of “almost, but” rather than one perfect prompt, so do not treat the first answer as final just because it looks finished.

Keep a context file you reuse

Maintain a short document, your stack, your conventions, the things to never do, and feed it at the start of sessions. It stops you from re-explaining yourself every time and stops the model from re-introducing the same mistakes you corrected yesterday. It is the single highest-leverage prompt you will write, because unlike every other prompt, you write it once and it improves every session that follows.

When the AI gets stuck, change the question

Sometimes the assistant loops, producing slight variations of the same broken thing. That is your cue to stop repeating the prompt and change it. Give more context, break the task smaller, paste the actual error, or describe the goal a different way. Hammering the same prompt harder rarely works. Reframing it almost always does, because the model was missing information, not effort.

Verify before you trust

One habit underpins all of the above: never let good prose lull you into skipping verification. A confident, well-formatted answer is not evidence that the code is correct, only evidence that the model writes fluently, which it always does. So after every non-trivial change, run it, read it, and check the part that actually matters against reality: the real API, the real data, the real edge case. The assistant’s job is to produce a strong draft, fast. Your job is to be the one who confirms it is actually true before it ships. Keep that division of labor sharp and the speed of vibe coding never curdles into a steady stream of confident, plausible bugs.

The mindset

Good prompting is just good delegation: a clear outcome, enough context, a tight scope, and verification at the end. Treat the assistant like a fast junior developer you trust to draft but not to decide, and you will get most of the speed of vibe coding with little of the mess. The broader philosophy behind all of this is in what vibe coding actually is, and the specific traps to avoid are in 9 vibe coding mistakes.

AI coding: the engine

This is the heart of the whole operation. I lean on an AI coding assistant that can read my entire project, not just a single file, so it understands context and can make changes across the codebase, run commands, and check its own work. A tool that only sees one file at a time is a glorified autocomplete. One that understands the whole repo is a collaborator.

But the tool matters less than the skill of using it. Small slices, clear outcomes, and reading every diff will beat a fancier tool used carelessly every single time. A great assistant with lazy prompting still ships bugs, fast. If you take one thing from this list, make it that. The details are in what vibe coding actually is.

Frameworks I reach for

The rule here is boring on purpose. Boring means well-documented, which means the AI has seen a million examples and gets it right, and means Stack Overflow already has the fix when something breaks.

• Mobile: a cross-platform framework so one codebase ships to both iOS and Android. As a solo developer, maintaining two separate native apps is a non-starter. One codebase, two stores.
• Web tools: whatever is mature and conventional. I avoid the framework that came out last month, no matter how exciting, because the AI does not know it well yet and neither do I.
• Static sites (like this blog): Hugo. Markdown in, fast static HTML out, free to host, and nothing to patch at two in the morning. Perfect for content and for app splash pages.

Hosting and infrastructure

The guiding principle: the best infrastructure for a solo developer is the infrastructure you never have to think about.

• Static hosting: a CDN-backed static host (Vercel, Cloudflare Pages, Netlify all have generous free tiers). My blog and every app splash page live here for free.
• DNS and CDN: Cloudflare. Cheap, fast, and the dashboard does not fight me.
• Backend, only when needed: a managed backend-as-a-service so I am not running and patching servers. Many of my apps need no backend at all, which is the cheapest and most reliable backend there is.

A lot of my apps run entirely on-device, which means there is no server to scale, no database to secure, and no monthly bill that grows with users. That is not an accident. It is a deliberate choice that keeps a one-person operation sane.

The splash-page pattern

Every app gets a subdomain with a single static page that does two things:

• detects mobile and routes straight to the App Store or Google Play, and
• shows a description, screenshots, and a help or FAQ section on desktop.

One link works everywhere, it costs nothing to host, and it doubles as the app’s SEO landing page. I drop that one link in any post or thread and it just does the right thing for whoever clicks it.

The glue that holds it together

This is the unglamorous layer that makes the rest survivable.

• Git, committed constantly. This is my undo button for vibe coding. When a prompt makes things worse, and it will, I roll back in seconds instead of losing an afternoon. Frequent small commits are not optional in this style of building.
• A project context file. A short doc of stack, conventions, and “do not do this” rules that I feed the assistant at the start of a session. It stops the AI from reintroducing the same mistakes and re-explaining the project every time.
• A plain notes file for the backlog. Half of shipping is deciding what not to build this week. A running list keeps the good ideas from derailing the current one.
• Analytics that respect privacy. Just enough to know which articles get read and which apps get used, without turning my users into a product.

What I deliberately do not use

• Heavy project management tools. For one person, a Kanban board with seven columns is procrastination with a nice UI. A text file and a short memory work better.
• Bleeding-edge frameworks. I want the AI to know the answer and the internet to have the fix. Popular and slightly boring beats new and shiny every time.
• Anything that needs a server I have to babysit, unless there is genuinely no way around it. Every running service is a thing that can break while I sleep.

A word on choosing tools

Notice that almost none of this is about picking the single best tool. It is about picking tools that get out of your way and that you can replace without drama. I deliberately avoid anything that locks me in: a proprietary format I cannot export, a host I cannot leave, a framework only one company truly understands. The reason is simple. As a solo builder, my scarcest resource is attention, and every tool that demands ongoing care is a tax on it. So I optimize for boring, swappable, and well-documented over clever and trendy, every time. The best tool is usually the one you stop having to think about the day after you adopt it, and the worst is the impressive one that quietly becomes a part-time job to maintain.

The takeaway

The stack matters far less than the loop: describe, generate, read, run, commit, repeat. Pick boring, well-documented tools so your assistant is fluent in them, host on free static tiers until you have real traction, and keep your operation small enough that one person can hold the whole thing in their head. That last constraint is the real secret. Every tool I choose is chosen to protect it. When you can fit the entire system in your mind, you move fast and you sleep at night, and as a solo builder those two things are the whole game.

Why a casual game

Utility apps solve a problem. Casual games create a feeling. They are completely different design challenges, and I wanted the reps in the second one. The bar is also deceptively high. The gameplay is simple, but simple has nowhere to hide. If the hop does not feel good, there is no feature list to distract from it, no settings screen to get lost in. The core loop is the entire product, naked and exposed.

The pitch is tiny, and that is the point: you are a capybara, the world is an endless gauntlet of cars, trucks, buses, trains, and rivers, and you hop forward as far as you can. Cute character, instant understanding, one-thumb controls. A five-year-old and a fifty-year-old both get it in the first second.

Game feel is the entire product

In a utility app, “it works” is enough. In a game, “it works” is the floor, and feel is the ceiling. I spent a wildly disproportionate amount of time on things a spec sheet would never list:

• The hop. Its timing, the little arc, the snap onto the next tile, the tiny squash when you land. This single animation is most of whether the game feels good or cheap.
• Readability. You have to instantly see where it is safe to land. Lane spacing, hazard timing, and color all serve clarity, because a death that feels unfair makes people quit, while a death that feels like their own fault makes them try again.
• The difficulty ramp. Easy enough to start, relentless enough that “one more try” becomes irresistible. The curve has to feel fair the whole way up.

You cannot spec your way to good feel. You build it, play it a hundred times, change one number, and play it a hundred more. That tuning loop is where most of the real work lives, and there is no shortcut through it.

The eagle: solving the “standing still” problem

Endless hoppers have a classic exploit. The player just stops moving and stays safe forever, which kills all the tension. My fix is a threat baked into the design: stay still too long and an eagle swoops down and takes you. Keep moving to survive.

It is a tiny mechanic with an outsized effect. It removes the safe option, keeps tension constant, and quietly converts the game from “avoid hazards when you feel like moving” into “always be moving, manage the danger as you go.” The best game design is often one small rule that invisibly forces the behavior you want, instead of a tutorial telling players how they should act. The eagle never explains itself. It just teaches you, once, and you never stand still again.

Coins, characters, and the reason to come back

A high score is a reason to play once. Progression is a reason to come back. The loop is simple:

• Collect coins as you hop, which gives every run a second purpose beyond distance.
• Spend them to unlock characters, six of them, including a Pirate, a Ninja, and a Space Capy.

Cosmetic unlocks are perfect for a casual game. They give players goals without adding rules to learn, and “I just want the Space Capy” turns out to be a surprisingly strong retention hook. It also keeps the game fair, because everything is earnable by playing rather than paying, which builds goodwill instead of resentment.

Where vibe coding helped, and where it did not

AI assistance was excellent for the scaffolding: the core game loop, procedural lane spawning, collision detection, the coin and save system, and the unlock screens. That got me from nothing to a playable prototype fast, which is exactly when a game project is most fragile and most likely to be abandoned. Getting to “I can play this” quickly kept the momentum alive.

What the AI absolutely could not do was tell me whether the game felt good. Tuning the hop, spacing the hazards so they are hard but fair, pacing the difficulty so it pulls you forward without frustrating you, all of that is taste and playtesting, and it stays firmly human. AI gets you a working game. Only playing it, over and over, turns it into a fun game.

What polish really means

The biggest surprise was how much the tiny, invisible details mattered. A casual game lives or dies on a hundred things no player could ever name: the exact delay before the eagle appears, the weight of the landing, the half-second of feedback after a coin, the way the camera nudges forward. None of it shows up in a feature list, and all of it is the difference between a game that feels cheap and one that feels good in the hand. That obsession with feel is a muscle, and once you build it on a game where feel is the entire product, you start noticing the same missing polish everywhere else you ship, in the tools you thought were already done.

Lessons from shipping it

• The first 30 seconds decide everything. Casual players judge instantly. If the first session is not fun, there is no second session, so the opening has to land.
• Juice matters. Small feedback, the sounds, the little animations, the satisfying coin pop, makes simple gameplay feel good. Juice is not decoration, it is the feel.
• Keep it offline and free. No connection required, local progress saving, no paywalls standing between the player and fun. Friction is the enemy of casual.
• Constraints breed charm. A capybara and one clean mechanic beat a sprawling design I would never have finished. The limits made the game, they did not hold it back.

Building a game after a string of tools was the best thing I did for my craft this year. It forces you to care about feel, not just function, and that lesson follows you back into everything else you build, including the serious apps where “it works” was secretly never quite enough either.

1. Not reading the diff

This is the single most expensive habit, and it is the root of most of the others. If you accept changes you have not read, you are not building software, you are accumulating mystery. Each unread change is a thing you do not understand sitting in your codebase, waiting. Read every change. If you do not understand it, ask the AI to explain it or rewrite it until you do. The moment you start rubber-stamping diffs to go faster is the moment you start going slower, you just will not find out for a week.

2. Asking for too much at once

“Build the whole app” produces a thousand lines you cannot review and cannot debug. The output looks impressive and is nearly useless, because you have no idea which parts are right. Work in small slices, one feature, one function, one screen at a time. Small diffs are reviewable. Mega-dumps are just hope wearing a confident face. Slicing the work small is not slower overall, it is what keeps you from drowning later.

3. No version control, or rare commits

Vibe coding is intensely iterative, and iteration goes sideways constantly. Git is your undo button. Commit every single time something works, so that when the next prompt makes things worse, and it regularly will, you roll back in seconds instead of trying to manually un-break a tangle. Builders who commit rarely lose whole afternoons to a change they cannot cleanly reverse. Cheap, frequent commits are not bureaucracy here, they are the safety net that makes fast iteration survivable.

4. Trusting confident wrong answers

AI will invent an API that does not exist and present it like established fact. It will be just as fluent and self-assured when it is wrong as when it is right, which is what makes it dangerous. Confidence is not correctness. Anything load-bearing, a library call, a config value, a security assumption, gets verified against the real documentation, not trusted because it sounded authoritative.

5. Skipping the run-it loop

Generating code without running it constantly is just producing plausible-looking text. It compiles in your imagination and breaks in reality. Run the app after every meaningful change. The feedback loop is the work. Skip it and you will eventually run everything at once and discover ten broken things tangled together, with no idea which change caused which failure.

6. Letting the architecture drift

Every prompt nudges the structure a little. Twenty unsupervised nudges later your codebase is mush, with duplicated logic, three different ways to do one thing, and no clear boundaries. The AI optimizes for making this change work, not for the long-term shape of your system, so that responsibility is yours. Periodically step back and steer: “consolidate this,” “extract that,” “keep this layer thin.” Architecture is the one thing you cannot delegate.

7. No project context file

Without a short document of your stack, your conventions, and your “do not do X” rules, the AI cheerfully reintroduces the same mistakes and ignores the patterns you have already established, because it has no memory of yesterday. A small context file you feed it at the start of each session saves you from correcting the identical thing forever. It is the highest-leverage thing you can write, because you write it once and it pays off in every session after.

8. Vibe coding the critical 20 percent

Auth, payments, data integrity, anything security-sensitive, these are exactly where a subtle generated bug is catastrophic rather than annoying. This is the part of the app where “looks right” is nowhere near good enough. Slow down here. Read every line twice, test the edge cases deliberately, and do not hand the keys to an autocomplete. The speed you gain everywhere else is what buys you the time to be careful here.

9. Outsourcing your understanding

The deepest trap of all: shipping code you fundamentally cannot explain. It works in the demo, so you move on, and then the day it breaks in production, “the AI wrote it” does not help you fix it and it does not help your users whose data is stuck. You are still the engineer of record for every line, and understanding your own system is not optional. If you could not, in a pinch, explain what a piece of code does and why, you do not actually own it yet.

The meta-mistake: assuming the rules do not apply to you

Underneath all nine is one final trap: believing that because the AI is so capable, you get to skip the discipline the rest of us need. You do not. The more powerful the assistant, the more damage a single unreviewed, untested, unloved change can do, precisely because it can touch more of your codebase faster. Capability raises the stakes of carelessness, it does not lower them. The builders who get burned worst are usually the ones who were most impressed by the tool and therefore trusted it the most, skipping the diff and the test run because surely something this smart would not be wrong. Stay a little skeptical, keep the habits, and you stay safe no matter how good the model gets.

The thread connecting all nine

Every one of these mistakes is really the same lesson wearing a different outfit: vibe coding moves the work up a level, it does not remove it. You stop typing boilerplate and start spending your attention on review, direction, and judgment. That is a fantastic trade, but it is still a trade, not a free lunch. Builders who treat the AI as a fast junior developer they actively supervise ship genuinely great things, quickly. Builders who treat it as an infallible oracle ship bugs at record speed and call it productivity.

The good news is that avoiding all nine is mostly a matter of discipline, not talent. Read the diff, slice the work, commit often, verify the risky parts, and keep understanding what you ship. For the positive version of this, the workflow and tools that make it go right, see what vibe coding actually is and how to prompt an AI coding assistant.

Start with the brutal truth

Nobody is waiting for your app. No one will find it by accident. Distribution is your job, and it is a bigger job than building. If that sounds unfair, it is also the opportunity: most builders quit at exactly this point, so simply showing up consistently is itself an edge. The first hundred users do not come from a clever hack. They come from doing unglamorous things repeatedly, long after most people would have given up.

It helps to reframe the goal. You are not trying to “get users.” You are trying to find the specific people who already have the problem you solved, get in front of them, and give them a reason to care. Ten of the right people beat a thousand random visitors who bounce.

Channel 1: be where your users already complain

Find the exact place your target user already hangs out and asks for help. A subreddit, a Discord, a Facebook group, a niche forum, an X hashtag. Then be useful first. Answer questions for a week or two before you ever mention your app.

When you do mention it, frame it as “I built this because I had the same problem,” not “check out my app.” People can smell a pitch instantly, and communities reject it on sight. What they respond to is a fellow sufferer who solved the thing and is sharing what they learned. The link is almost an afterthought to a genuinely helpful post.

This channel does not scale, and that is exactly why it works at this stage. You can afford to talk to people one at a time when you only need a hundred of them.

Channel 2: App Store Optimization (ASO)

If you have a mobile app, the store is a search engine, and free traffic lives there.

• Put your main keyword in the title and subtitle, which carry the most weight.
• Make your first two screenshots sell the benefit, not show a login screen. They are visible without scrolling and they decide the install.
• Ask happy users for ratings at a good moment, after a win inside the app, never on first launch.
• Localize the listing for a couple of big markets. It is cheap and most competitors never bother.

ASO compounds. A listing you optimize once keeps pulling installs for months. The full playbook is in the ASO guide.

Channel 3: build in public

Share the process, not just the product. “Day 12: added offline mode, here is what broke and how I fixed it.” People follow journeys, then become users, then become the people who tell others. It compounds slowly and then suddenly, and the audience you build follows you to your next app too.

Your splash pages help here. A clean page per app that auto-routes to the right store on mobile gives you one link to drop anywhere, in any thread or post, without thinking about which platform someone is on.

Channel 4: content that ranks

Write the article your user would search for before they even know your app exists. “How to do X,” where X is the problem you solve. It pulls in people with exactly the right intent, for years, for free. This blog is doing that right now: each post is a door that someone with the problem can walk through. Content is slow to start and then becomes the channel that quietly works while you sleep.

Channel 5: direct outreach

For your very first users, one-to-one beats one-to-many. Send a polite, specific message to ten people who fit your app perfectly. Ask them to try it and tell you what is confusing. You get users and the feedback that makes the next ninety easier to win. The key word is specific: a copy-pasted blast gets ignored and reported, while a genuine message that references the person’s actual situation gets a reply.

What to measure (and what to ignore)

Vanity metrics will lie to you. At a hundred users, do not obsess over downloads. Watch:

• Activation: what fraction of installs actually reach the “aha” moment, the first real use of the app?
• Retention: do people come back on day two, day seven? This is the single most honest signal of whether you built something worth growing.
• Where they came from: tag your channels loosely so you know which one is actually working, and double down there.

If activation and retention are bad, more traffic just means more people bouncing faster, which can even hurt your store ranking. Fix the leak before you pour in water.

What to skip at this stage

• Paid ads. You do not know your message or your numbers yet, so you would just pay to confirm that.
• Press. Reporters cover traction, not launches. Get the traction first, then the story tells itself.
• Going wide. A thousand strangers who do not fit beat nothing, but a hundred who fit perfectly beat the thousand.

A download is not a user

One caution as you count toward a hundred: a download is not a user. Someone who installs the app, opens it once, and never returns is a vanity number, not a customer, and chasing those will only flatter you while teaching you nothing. When you tally your first hundred, count the people who actually came back and used the thing more than once. That is the number that tells you whether you have something real, and it is the only one worth optimizing for at this stage.

The real unlock

Pick two of these channels and do them consistently for a month, instead of trying all five for three days. Consistency is the actual growth hack, and it is the one almost nobody has the patience for. Your first hundred users come from showing up in the same place, being genuinely useful, and asking, over and over, long after the novelty has worn off. Do that, learn from every conversation, and the second hundred gets easier, because by then you actually understand who your app is for. For the community side specifically, see getting your first users from Reddit and communities.

The one rule that governs everything

Contribute before you promote. Communities can instantly smell someone who showed up only to advertise. The mental model that works: you are a member who happens to have built something useful, not a marketer who joined to drop a link. That distinction is everything, and people detect it faster than you would believe.

A rough ratio people throw around is nine to one, nine genuinely helpful, non-promotional contributions for every one time you mention your app. You do not have to count, but the spirit is right. If your first post in a community is your launch, you have already lost, because you have given the group no reason to trust you. Spend time being a good member first, and the promotion later lands on fertile ground instead of hostile ground.

Find the right rooms

Go where the problem lives, not where “marketing” lives.

• Search Reddit for the problem phrases, not your product. If people are asking “best offline transcription app?” in a subreddit, that is your room, and the demand is already proven by the question.
• Smaller, focused communities convert far better than giant generic ones. Two thousand obsessed members beat two million bored ones, because the obsessed ones actually have the problem and actually act.
• Look for Discords and forums built around the hobby or profession your app serves. Those tend to be higher-trust and longer-lived than a single Reddit thread that scrolls away in a day, and relationships there compound over time.

Read the rules before you type a word

Every community has self-promotion rules, and they vary wildly.

• Many subreddits ban links outright, or allow them only in a weekly “self-promo” or “what are you working on” thread. Use those threads. They exist for exactly this, and posting there is welcomed rather than punished.
• Some communities allow promotion only from established members with a minimum account age or karma, which is just another reason to participate before you pitch.
• Mods are not your enemy. Breaking a clearly posted rule is. Skim the sidebar and the wiki first, because a thirty-second read saves you from an instant, permanent ban.

Post a story, not a pitch

When you do share, frame it as a person, not a billboard.

• Lead with the problem and your motivation. “I kept needing to transcribe interviews but did not want to upload private audio to a server, so I built something that runs entirely on the phone.” That is a story people relate to, not an ad they tune out.
• Be useful even to non-users. Explain what you learned, how it works, the trade-offs you made and why. People upvote insight. They scroll past advertising.
• Invite feedback, genuinely. “What would you want it to do?” turns a promotion into a conversation, and it turns your earliest users into co-designers who feel ownership over the thing and tell their friends about it.
• Do not fake it. No sockpuppet accounts, no “has anyone tried this app?” from a burner you control. It always gets caught eventually, and it is the single fastest route to a permanent ban and a trashed reputation.

Use direct messages, sparingly and like a human

For your very first handful of users, a polite, specific, personal message to someone who clearly has the problem can work well, but only if it is genuinely personal. Reference their actual situation, the thing they actually said. Ten thoughtful messages beat a hundred copy-pasted ones, because the templated blast gets ignored and reported while the real one gets a reply, and often the kind of detailed feedback that makes your next ninety users far easier to win.

Turn feedback into momentum

The underrated prize of communities is not just users, it is honest, fast feedback from exactly the people you are building for. Listen for the recurring complaint, the feature three different people ask for, the word people use that you should put in your app store listing. Ship a fix, then go back and tell the community you did it because they asked. That loop, listen, ship, report back, builds a small group of genuine advocates, and advocates are worth more than any single install.

What gets you banned, so you can avoid it

• Drive-by link drops with zero participation in the community.
• Posting the same thing across ten subreddits at once, which reads as spam to both mods and automated filters.
• Arguing with moderators or ignoring clearly posted rules.
• Astroturfing with fake accounts and fake enthusiasm.

Every item on that list screams “marketer,” which is the one thing communities reject on sight. Avoid all of it by simply being the member you would want in the room.

Patience is the actual skill

The hardest part of this approach is not finding communities or writing good posts. It is the patience to participate for weeks before you see a single user, while a part of your brain screams that you should just drop a link and move faster. Resist it. The people who win in communities are the ones who treat them as places they belong, not as channels to exploit, and that orientation is almost impossible to fake over the long run. Show up because you genuinely find the community interesting and useful, and the users become a natural byproduct rather than a transaction you are straining to force. Slow is not the cost of this channel. It is the reason it works.

The payoff

Done right, communities give you something ads never will: your first users, and honest feedback, and a few people who will tell others. It is slow, it is manual, and it does not scale, which is exactly why it works at the stage when nothing else does. You can afford to talk to people one at a time when you only need a hundred of them. Pair it with App Store Optimization and the rest of the no-budget playbook, show up consistently, and be the member you would want to meet.

The itch

I kept hitting the same three frustrations with mainstream AI apps:

1. Privacy. Everything you type goes to a server and, often, into training data.
2. Connectivity. On a plane or with bad signal, they are useless.
3. Cost. Another $10 to $20 a month for something I use in unpredictable bursts.

On-device models had quietly gotten good enough that I started to wonder: what if none of that were true? What if the AI just lived on your phone, the way a calculator does? “Your AI, your device,” private, offline, and actually powerful. The idea would not let go of me, so I built it.

The hard part: a language model on a phone

This is where it stops being a UI project and becomes a systems problem. Phones are not servers, and the constraints are brutal enough that they drive every single decision.

• Memory. A phone might have 4 to 8GB of RAM, shared with the OS and every other app. A model that loads fine on a laptop will simply get killed on a phone. That alone rules out most models.
• Model size on disk. Nobody will tolerate a 20GB download. The realistic sweet spot is a few hundred MB to a few GB.
• Speed. Tokens per second has to feel like a conversation, not a fax machine slowly printing.
• Heat and battery. Run the processor flat out and the phone gets hot and the battery drains, so the work has to be efficient, not just possible.

The unlock is small, quantized models. Quantization shrinks a model by storing its weights at lower precision, which trades a little quality for a huge reduction in size and memory. I built around Qwen 3, from tiny 0.6B variants up to larger ones, and GLM-Edge, including vision-capable variants, with downloads ranging from roughly 500MB to 4GB. The user picks a model that fits their device, downloads it once, and from then on it runs fully offline.

The trade-off you have to make peace with, and be honest with users about, is this: a 1B model on a phone is not a frontier model in the cloud. It will not write your dissertation. But for quick questions, drafting, summarizing, brainstorming, rewriting, and anything on a plane, it is genuinely useful, and it is yours. Setting that expectation clearly inside the app matters more than overpromising and disappointing people on their first message.

Giving users the dials, with sane defaults

Different people want different behavior, so I exposed the controls that matter: temperature, top-k, and top-p for shaping how creative or focused the responses are, plus toggles for a “thinking” mode versus a “fast” mode depending on whether you want careful reasoning or a quick reply. The risk with exposing model internals is overwhelming a casual user, so the rule was: every control has a good default, and you never need to touch any of them to get a solid answer. Power users get the dials. Everyone else gets something that just works out of the box.

Where vibe coding carried me

I am one person. I could not have shipped this typing every line. The AI assistant handled the parts that are tedious but well understood:

• The chat UI: message bubbles, streaming token rendering, scroll behavior, the copy button, the empty state.
• The model download manager: progress, resume after interruption, storage checks, and deletion to free space.
• The settings layer: surfacing temperature, top-k, top-p, and the mode toggles in a way that a normal person can ignore safely.

What I had to own personally was the hard 20 percent: wiring up on-device inference, managing memory so the app does not get killed mid-generation, and tuning the defaults so a non-technical person gets a good answer without touching a single slider. That split, where the AI does the boilerplate and you own the load-bearing parts, is the whole game. I wrote about it in what vibe coding actually is.

Product decisions that mattered

• One-time download, then offline forever. The only moment of friction is the first model download. After that, zero network and zero waiting, ever.
• No account. An account is a privacy promise you can break. No account means there is nothing to leak, nothing to breach, and nothing to log in to.
• Sensible defaults, optional depth. Casual users get a model that just answers. Power users get the sampling controls. Neither group is punished for the other.
• Free. With no server costs to cover, there is no subscription to justify, which also means no billing, no payment processing, and no churn to manage.

What I would tell another builder

On-device AI feels like magic to users precisely because everyone assumes it is impossible. “You can run that on a phone?” That gap between expectation and reality is a wonderful place to build a product, because the perceived difficulty is doing your marketing for you. But respect the constraints. Pick models per device tier, be honest about what a small model can and cannot do, and spend your scarce hand-written effort on memory and performance, not on the parts an AI can scaffold in an afternoon.

The result is an app I actually use, on planes, on the subway, and any time I would rather not hand my private thoughts to a server. That is the kind of product worth shipping: one you reach for yourself. Building privacy-first apps turned into a whole theme for me, which I dug into again with an offline speech-to-text app.

A working definition

Vibe coding is describing what you want in plain language and letting an AI write most of the code, while you stay the architect, reviewer, and tester. You are still in charge. You are just not typing every line.

The real shift is from author to editor. For most of software history, your value was in producing code: remembering syntax, wiring up boilerplate, looking up the API for the hundredth time. Vibe coding takes that production cost close to zero and moves your value to judgment: deciding what should exist, recognizing whether the output is correct, and steering when it drifts. You spend less time typing and more time thinking about the product.

That sounds small. It is not. It is the difference between writing a paragraph and editing one. An editor with taste and a fast writer can produce a book quickly. An editor with no taste and a fast writer produces a fast pile of nonsense. The writer got faster either way. Whether that is good depends entirely on the editor.

A concrete example of the loop

Say I want a “save draft” feature. The old way: I open the file, remember the state management pattern, write the handler, wire the button, add storage, debug the typos. Twenty minutes if I am lucky.

The vibe-coding way: I tell the assistant, “Let users save a draft and reopen it later. Match how the settings screen persists data.” It produces the handler, the storage call, and the button in seconds. Then my real work starts. I read the diff. Does it handle the empty draft? Does it collide with an existing key? Is the storage call the one we already use elsewhere, or did it invent a second pattern? I fix what is off, run the app, confirm it works, and commit. Total time: maybe five minutes, and the thinking happened where it mattered.

Where it genuinely shines

• First drafts of anything. A new screen, an API endpoint, a config file. The AI gets you to 80 percent in seconds, and 80 percent of something is far easier to finish than a blank file.
• Unfamiliar territory. New framework, new language, a library you have never touched. The model already knows the idioms you would otherwise spend an hour googling, so the learning curve flattens.
• Boilerplate and glue. CRUD, forms, parsers, scripts, tests, type definitions. The boring 60 percent of every project that you have written a hundred times before.
• Refactors you have been avoiding. “Extract this into a service, add error handling, keep the behavior identical.” Tedious by hand, quick to supervise.

This is the reason a solo builder can now ship what used to take a small team. The production bottleneck is gone, so you are limited by how fast you can decide and verify, not how fast you can type.

Where it bites

• Confident wrong answers. The AI will invent an API that does not exist and write it like gospel. If you cannot tell, you will ship it. Confidence is not correctness.
• Silent drift. Each prompt nudges the code. Twenty prompts later the architecture is mush, with duplicated logic and three ways to do one thing, if you were not watching.
• The 20 percent that matters most. Auth, payments, data integrity, security. The parts where a subtle bug is expensive are exactly where you must slow down and read every line.

I learned the drift one the hard way. Early on I let an assistant add feature after feature to an app without stepping back, and a week later I had three different ways of storing the same data and a bug that touched all three. The fix took longer than building it properly the first time would have. Now I steer the structure deliberately instead of letting it accrete.

The rule I live by: you are responsible for every line you ship, whether you typed it or not. “The AI wrote it” is not a defense to your users when their data is gone.

The loop I actually use

1. Describe the outcome, not the implementation. “Users can save a draft and come back to it” beats “add a useState and a button.” Let the model propose the how.
2. Work in small slices. One feature, one screen, one function at a time. Small diffs are reviewable. Thousand-line dumps are not.
3. Read the diff every time. Non-negotiable. If I do not understand a change, I ask the AI to explain it or I rewrite it until I do.
4. Run it immediately. Vibe coding without running the app constantly is just generating hope. The feedback loop is the work.
5. Commit when it works. Frequent commits give me a safe point to roll back to when the next prompt makes things worse, which it regularly does.
6. Keep a project context file. A short doc of stack, conventions, and “do not do X” that I feed the assistant so it stops reintroducing the same mistakes.

What actually changes about the job

The fear is that vibe coding makes engineering skill worthless. The opposite is true. When anyone can generate code, the scarce skills become the ones the AI does not have: knowing what to build, recognizing a bad solution, understanding the system well enough to catch the subtle break, and having the taste to keep things simple. Those are senior skills, and vibe coding rewards them more, not less. The junior who only ever copied the generated answer never develops them. The builder who reads, questions, and steers gets sharper with every project.

The mindset that makes it work

Treat the AI like a fast, eager junior developer with no memory and no judgment about your product. It produces a lot, quickly, and it will confidently do the wrong thing if you let it. Your job did not disappear. It moved up a level, to direction, taste, and verification.

That is the trade. You give up typing, you keep the thinking. Done right, you ship in a weekend what used to take a month. Done lazily, you ship bugs at the same impressive speed. The entire difference is how carefully you stay in the loop. For the specific habits that keep it on the rails, see how to prompt an AI coding assistant and 9 vibe coding mistakes to avoid.

Start with the keyword, not the cleverness

Before anything, figure out what your users type. Not your branding, not your clever product name, the literal words a real person uses when they want what you built. “Voice to text,” “offline AI,” “capybara game.” Those phrases are your raw material, and getting them right is most of the battle.

Tools help here. App Store Connect shows search popularity, and third-party ASO tools estimate volume and difficulty. But even free thinking gets you most of the way: list every phrase a confused stranger might search to find an app like yours, then rank them by two things, how much traffic they likely have and how well your app actually delivers on that search. You want terms where you can genuinely be one of the best results, not the most competitive term where you will be buried on page ten.

Title and subtitle do the heavy lifting

On the App Store, the title and subtitle are by far the highest-weighted keyword fields. Do not waste them on just your brand name.

• Title: your brand plus your single most important keyword, for example “Private Transcribe: Voice to Text.” That one keyword in the title is worth more than a dozen buried in the description.
• Subtitle: your next strongest keywords in a readable phrase, not a robotic comma salad. It still has to read like a human wrote it.
• iOS keyword field (100 characters): every character counts. No spaces after commas, no repeating words already in your title, no plurals of words you already used. Pack it efficiently.
• Google Play weights the description for keywords instead of a separate field, so write a natural description that uses your important terms a few times without stuffing. Keyword-stuffed descriptions read badly and can get penalized.

The icon gets the click, screenshots make the sale

People decide in about a second, and two assets carry that second.

• Icon. It must read clearly at thumbnail size in a crowded search results list. Simple, high-contrast, and recognizable wins. Test it shrunk down to 60 pixels, and if it turns to mush, redesign it. A clever icon nobody can parse at small size is a failure no matter how nice it looks large.
• The first two screenshots. These are visible without scrolling, and they decide the install more than anything else on the page. Show the benefit, not a login screen or an empty menu. Add a short caption overlay on each one, “Works 100% offline,” “99+ languages,” “No account needed.” Treat your screenshots as an ad, not as documentation.

Ratings and reviews are ranking fuel

Your rating is both a ranking factor and a conversion factor. A 4.7 gets installed, a 3.9 gets skipped, even for the identical app. The trick is when you ask:

• Never prompt on first launch, before the user has any reason to like you.
• Ask after a win, a finished transcription, a new high score, a successful result. That is when goodwill is highest.
• Use the operating system’s native review prompt so people can rate without leaving the app, which dramatically increases how many actually do.
• Reply to reviews, especially the negative ones. It is public, it shows you care, and it lifts overall sentiment for everyone reading later.

Pick the right category and study your competitors

Choosing the most accurate, slightly less crowded category can meaningfully change how discoverable you are. And your competitors have already done expensive testing you can learn from for free. Look at the top apps for your keywords. What is in their titles? What do their first two screenshots emphasize? You are not copying, you are reading the market’s answer key, then doing it a little better and more honestly.

Localize, because it is cheap leverage

Translating your store listing, not necessarily the whole app, into a few large languages unlocks entire markets your competitors ignore. Title, subtitle, keywords, and screenshot captions are usually enough to start. It is one of the highest return on investment afternoons you will ever spend, because most indie developers never bother and you get those searchers nearly uncontested.

Treat ASO as iteration, not a launch task

This is where almost everyone fails. ASO is not “set it and forget it.” Change one variable at a time, a screenshot, the subtitle, the icon, then watch your conversion rate and impressions for a couple of weeks and keep whatever wins. Both stores hand you this data for free, and most developers simply never open the dashboard. The ones who check monthly and adjust pull steadily ahead of the ones who set it once and walk away.

One more cheap win: an app preview

If your store listing allows a short app preview video, add one. Most indie developers skip it, which is exactly why it works: a simple fifteen-second clip showing the app actually in motion can set your listing apart and lift conversion, especially for anything where seeing it move explains the value faster than any screenshot can. It takes an afternoon to record and trim, and it keeps earning installs for as long as the listing is up.

The honest caveat

ASO amplifies a good app. It cannot save a bad one. If people install and immediately churn, that actually hurts your ranking, because the stores watch retention. So ASO works hand in hand with the product itself and with your other channels. It is the store-side complement to getting your first users from communities and the broader playbook in getting your first 100 users with no budget.

Do the keyword homework, nail the title and first two screenshots, earn ratings at the right moment, localize the listing, and revisit it monthly. That is most of ASO, and it is the rare kind of traffic you do real work for once and then keep getting paid on long after.

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.

The quick version

• Cloud AI means your app sends data to a server running a large model, which sends back a result. It is easy to build and gives you access to the most powerful models, but every call costs money, needs a connection, and sends user data off the device.
• On-device AI means a smaller model runs directly on the phone. It is harder to build and limited to smaller models, but it is private, free to run, and works offline.

Now the details, because each axis matters differently for different apps.

Privacy

This is the starkest difference. With cloud AI, user data leaves the device and passes through someone’s servers, where it may be logged, retained, or used for training. For a casual app that may be fine. For anything sensitive, voice notes, health data, private documents, it is a real liability and a hard sell to privacy-conscious users.

With on-device AI, the data never leaves the phone. You can make a credible promise that you do not see, store, or transmit it, because architecturally you cannot. That promise is not just ethics, it is a marketing advantage, and it is the entire premise behind apps like my offline transcription app and on-device chat app. When privacy is the selling point, on-device is not a preference, it is the requirement.

Cost

Cloud AI charges you per request, forever. Every user, every interaction, adds to a bill that grows with your success. That can be sustainable with the right pricing, but it also means a free app with a viral spike can hand you a frightening invoice. You are renting intelligence by the token.

On-device AI costs you nothing to run after the user downloads the model. A million users cost the same as one: zero marginal inference cost. For a solo builder who wants to give an app away or charge once without an ongoing bill, that economics is liberating, and it is closely tied to how you can price the app.

Latency and reliability

Cloud calls depend on the network. They add round-trip latency and they fail when the connection is bad, which for a mobile app is often: subways, planes, elevators, rural areas, spotty wifi. Your app is only as reliable as the user’s signal and your server’s uptime.

On-device runs locally, so there is no network round trip and no dependency on a server staying up. Response time depends on the phone, but it is consistent and it works in airplane mode. For anything users expect to “just work” anywhere, offline capability is a genuine feature, not a nice-to-have.

Capability

Here the cloud wins, clearly. Cloud servers run the largest, most capable models, the ones that write essays, reason through hard problems, and handle enormous context. On-device models are necessarily smaller to fit in a phone’s memory, so they are less capable on the hardest tasks. A small on-device model is great for focused jobs, transcription, classification, summarizing, quick chat, and weaker at open-ended reasoning that demands a frontier model.

So the honest question is not “which is smarter,” it is “how much capability does my feature actually need?” Many real app features need far less than people assume, and a small local model handles them perfectly.

How to decide

Run your app through these questions:

• Is the data sensitive? If yes, lean on-device. Privacy is hard to retrofit.
• Do users need it to work offline? If yes, on-device, because the cloud simply cannot.
• Will inference costs threaten your economics at scale? If yes, on-device removes the bill.
• Does the feature genuinely require a frontier-level model? If yes, you may need the cloud, at least for that piece.
• Are you optimizing for fastest time to ship a prototype? Cloud is easier to start with, so it is a reasonable first move you can replace later.

A useful pattern: prototype with the cloud to validate the feature quickly, then move the parts that handle sensitive data or need to work offline onto the device once you know they are worth keeping. You do not have to choose globally. You choose per feature.

The hybrid path is often the real answer

In practice, the choice is rarely all or nothing. Many of the best apps mix the two deliberately: the sensitive, frequent, or offline-critical work runs on the device, while the occasional task that genuinely needs a frontier model reaches out to the cloud, with the user’s clear awareness. A note-taking app might transcribe entirely on-device for privacy, but offer an optional cloud summary that the user explicitly triggers. The trick is to make the boundary intentional and transparent, so the user always knows when their data stays local and when it leaves. Done well, a hybrid gives you most of the privacy and cost benefits of on-device with an escape hatch to cloud power for the rare cases that truly need it. Just be honest about where that boundary sits, and default to the device whenever you reasonably can.

The takeaway

Cloud AI is the easy default and the right call when you need maximum capability and your data is not sensitive. On-device AI is more work, but it wins decisively on privacy, cost, offline reliability, and the ability to make promises you can actually keep. For a solo builder, that combination, no server bill, no privacy liability, works anywhere, is often worth the extra engineering, which is why so much of what I build runs on the phone rather than in someone else’s data center. Match the architecture to what your feature truly needs, and do not pay the cloud’s costs for capability you were never going to use.

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.

Why app developers should care about web SEO

The app stores are walled gardens. You optimize your listing, which matters and which I covered in the ASO guide, but you only reach people already browsing the store for something like your app. Web search reaches everyone else: the person googling “how to transcribe audio privately” who has not yet thought to look in an app store at all. Catch them at the moment they are describing their problem, and you can introduce your app as the answer. That is a much larger and warmer pool than store search alone.

Start with a simple website

You need a home on the open web that you control, not just a store listing. It does not have to be complicated. A fast static site with a page for the app, a privacy policy, and a blog is plenty. Static site generators make this cheap and low-maintenance, and you can host it free. This site you are reading is exactly that setup. The website does triple duty: it ranks in search, it hosts the privacy policy both stores require, and it gives you a stable link to send people that is not at the mercy of store algorithms.

Write the content your users search for

The heart of web SEO is publishing content that answers what your potential users are typing into Google. Think about the questions someone has before they know your app exists:

• The problem, framed as a question: “how to do X,” “best way to Y,” “X without Z.”
• Comparisons people make while deciding: “A vs B,” “alternatives to C.”
• The how-to guides around your app’s domain, written genuinely to help.

Each article is a doorway. Someone searches their problem, finds your helpful guide, and at the end discovers that you built an app that solves exactly that. You are not interrupting them with an ad, you are answering the question they already asked, which is the most welcome kind of marketing there is.

Do the basics right, ignore the rest

SEO has a reputation for being a dark art, but for an indie developer the fundamentals carry almost all the weight, and the advanced stuff rarely matters at your scale. The basics:

• Useful, original content that genuinely answers the search. This is most of SEO. Google is in the business of surfacing helpful pages, so be one.
• A clear title and description for each page that matches what people search.
• Headings and structure so both readers and search engines can follow the page.
• Fast loading and mobile-friendly, which static sites give you almost for free.
• Internal links between related articles, so visitors and crawlers move through your site. (Notice how these posts link to each other. That is this principle in action.)

Skip the obsession over keyword density, meta keyword tags, and a hundred technical tweaks that move nothing. Helpful content that loads fast beats a thousand micro-optimizations.

Be patient, because this compounds

The hard truth about SEO is that it is slow. A new article can take weeks or months to rank, and a new site has little authority at first. This is exactly why most people quit, and exactly why it works for those who do not. Every article you publish is a permanent asset that keeps pulling visitors long after you wrote it, with no ongoing cost. Ten articles in, you have a modest trickle. A year of consistent publishing in, you have a real, free, compounding channel that works while you sleep. The traffic curve is flat and then it bends upward, and the only way to get to the bend is to keep going through the flat part.

Let it serve the whole portfolio

A nice property of a content site is that it is not tied to one app. The audience and authority you build serve everything you make, now and later. A reader who found your guide and trusted it is a warm lead for your next app too. This is part of why a portfolio approach and a content habit pair so well, a theme I get into in why I build small apps. Your writing becomes a durable asset that outlives any single product.

Avoid the common traps

A few mistakes waste indie developers’ time and occasionally do real harm. The first is writing for search engines instead of people, stuffing keywords until the prose reads like a robot wrote it, which both repels readers and, increasingly, gets penalized. Write for a human first, always. The second is chasing the most competitive keywords, where established sites have years of authority you cannot match yet, instead of the specific long-tail questions where you can genuinely be the best answer. The third is expecting results in weeks and quitting when they do not come, right before the compounding would have started. And the fourth is publishing an article and never touching it again, when a quick refresh of a useful post every so often keeps it ranking. Avoid those, focus on genuinely helpful writing aimed at real questions, and the basics will carry you further than any clever trick.

The takeaway

The app store is one search box. The open web is a much bigger one, full of people describing their problem in their own words, moments before they go looking for a solution. Build a simple website, publish genuinely helpful content around the problems your apps solve, get the basics right, link your articles together, and then be patient enough to let it compound. It is the slowest marketing channel to start and one of the most durable once it does, and for a solo builder playing a long game, that trade is well worth making.

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.

Why it works

People do not connect with polished launches. They connect with stories and with people, and a build-in-public journey gives them both. When you share the real process, the small wins, the frustrating bugs, the lesson you learned the hard way, you become a person someone is following rather than a faceless app. That relationship is the foundation of everything that follows.

The mechanics are simple and compounding. People follow your journey, some become users, some become the people who tell others, and crucially, the audience you build is not tied to one app. It follows you to the next one. You are not just marketing a product, you are building a standing audience that makes every future launch easier. That is the opposite of paid ads, which stop the instant you stop paying.

What to actually share

The most common worry is “I have nothing interesting to share.” You have more than you think. The material is your actual work:

• Progress. “Added offline mode today, here is what it looks like.” Simple, and it shows momentum.
• Decisions and trade-offs. Why you chose one approach over another. People love seeing the reasoning, not just the result.
• Problems and how you solved them. The bug that took a day, the thing that broke in production. Struggles are relatable and useful, and they make the wins land harder.
• Numbers, if you are comfortable. Downloads, users, revenue. Real numbers are magnetic because so few people share them honestly, and they build enormous credibility.
• Lessons. What you would do differently, what surprised you. This is genuinely useful to others walking the same path, which is the whole spirit of articles like these.

You do not have to share everything, and you should not share what makes you anxious. But the ordinary reality of building, told honestly, is far more interesting to people than you expect.

Be honest, especially about the failures

The instinct is to share only the wins and hide the struggles, but that is exactly backwards. The failures are what make you trustworthy and relatable. Everyone posts their launches. Almost no one posts the app that flopped, the feature nobody used, the month with no growth. When you share those honestly, you stand out, and you give people a reason to believe your wins are real too. Polished, relentlessly positive feeds read as marketing. Honest ones read as a person, and people follow people.

Where to do it

Pick the platform where your kind of people already gather and where you will actually keep posting. For many indie developers that is a public feed on a social platform, a community like the right subreddit or Discord, or a blog like this one where each post is also a durable, searchable asset. The blog has a particular advantage: unlike a social post that scrolls away in a day, an article keeps working for years and feeds your SEO at the same time. Many builders do both, short updates on social to build relationships, longer posts on a blog to build a lasting record.

Consistency beats virality

Do not wait for the perfect post or chase a viral moment. Building in public works through steady, repeated presence, not one big hit. Showing up regularly with small, honest updates builds an audience far more reliably than occasionally posting something you agonized over. Lower the bar for what is worth sharing, post consistently, and let it accumulate. The person who posts a modest update three times a week for a year will have built something real, while the one waiting to go viral will still be waiting.

Starting from zero

The hardest part is the beginning, when you are posting into apparent silence with no audience. Everyone starts there, and the only way through is to keep going while the audience is still tiny. Engage genuinely with others doing the same thing, support their journeys, and be a real member of the community rather than a broadcaster. Early on, your reach is small but your relationships are strong, and those early followers are often your most loyal users and loudest advocates later. Treat the silent early days as planting, not failing. The audience compounds, slowly and then quickly, the same way getting your first users does.

A few mistakes to avoid

Building in public has failure modes worth naming. The first is performing instead of sharing, turning every post into a humblebrag or a growth-hack thread that reads as fake, which repels the exact trust you are trying to build. The second is comparing numbers competitively and getting demoralized when someone else’s chart looks better, when their context is nothing like yours. The third is letting the audience steer your product, building what gets likes instead of what users need, because applause and usage are not the same thing. And the fourth is quitting during the silent early stretch, right before it starts to compound. Avoid those four, keep it honest and consistent, and the rest mostly takes care of itself.

The takeaway

Building in public turns solo building from a silent grind into a story people can follow and a relationship they can invest in. Share your real progress, decisions, problems, and lessons, be honest especially about the failures, pick a platform you will stick with, and post consistently rather than waiting for perfection. Start before you have an audience, because everyone does, and let it compound. Done sincerely over time, it becomes a standing audience that makes every app you ship easier to launch than the last, which is exactly the kind of compounding advantage a solo builder needs.