I have shipped six apps by myself. An offline AI chat app, a private speech-to-text app, an arcade game, a GPS speedometer, a credit card tracker, and a retirement planner.

They look unrelated. They are not, and I did not notice the pattern until app four.

The pattern #

Every one of them runs entirely on the user’s device. No backend, no account, no subscription, no data leaving the phone.

That was not a strategy. It started as a constraint, because I am one person and I did not want to operate servers or be on call for infrastructure I could not afford to staff. Then it turned out to be the most interesting thing about the work.

Consider what the constraint eliminates: authentication, session management, password reset flows, sync conflict resolution, database migrations, uptime monitoring, scaling, a security surface, GDPR tooling, a privacy policy that needs a lawyer, per-user operating cost, and a subscription to cover that cost. All of it, gone, because there is nowhere for the data to go.

What it eliminates on the user’s side is more interesting. A local-only app cannot leak your data in a breach, cannot be subpoenaed, cannot change its privacy policy after an acquisition, and cannot start charging you monthly because the servers got expensive. Those are not promises. They are properties of the architecture.

I wrote about the general form of this argument in on-device AI explained and what happens to your data when you use AI, and it applies well beyond AI.

What each one taught me #

Personal LLM, the offline AI chat app, taught me that memory management is the entire game on a phone. A model that loads on a flagship gets killed by the OS on a three-year-old device, with no graceful failure, and matching model tiers to device capability was most of the work.

Private Transcribe, on-device speech to text, taught me that privacy can be a whole product rather than a feature, but only if it is real in the architecture. And that long recordings are where a demo becomes a product, because forty minutes of audio is a memory problem that ten seconds is not.

Capybara Crossing, the arcade game, taught me that game feel is tuning rather than design, and there is no substitute for playing it a thousand times. Also that finishing a game is a completely different skill from starting one.

Speedometer GPS taught me that the naive implementation of a simple app is usually wrong in a way you can only discover in the field. Raw GPS speed is noise, and turning it into a usable number was signal processing I did not expect to be doing.

Credit Card Central taught me that setup friction kills utility apps, and that deciding what not to build is most of the design. Refusing to connect to bank accounts removed eighty percent of the work and cost one feature I did not need.

Retire Goals taught me that the hard part of a finance app is not the finance. The formula took an hour and the chart design took weeks, because an accurate chart was discouraging and that was the actual product problem.

Where AI assistance actually helps #

I use AI coding tools heavily, and the division of labor has been consistent enough across six projects that I trust it now.

What it does well is boilerplate and scaffolding: settings screens, list views, navigation, form validation, work that is well-trodden and tedious. It writes code in a framework I know less well faster than reading documentation does, particularly for the second platform. It is a good rubber duck for a design problem, since explaining the problem clearly enough to ask is often where the answer comes from anyway. It writes test scaffolding I would otherwise skimp on. And it handles the unglamorous middle layer: download managers with resume, local database queries, share sheets, notification scheduling. Real work, well understood, no novelty.

What stays on me is anything performance-critical: on-device inference, memory management, the GPS filtering, the parts where being subtly wrong produces something that works on my machine and fails on someone else’s. Anything where the promise is the product, because when your entire pitch is that audio never leaves the device, you read every line yourself and verify there is no analytics call quietly shipping something off the phone. Product decisions, meaning what to build, what to refuse, and what the default should be, since AI will happily implement a bad idea very quickly. And anything I will have to debug at 11pm, because code I did not write is code I do not understand, and understanding it later costs more than writing it now.

The honest summary: AI assistance made me roughly two to three times faster on the seventy percent of work that is well understood, and approximately zero percent faster on the thirty percent that is actually hard. Which is a large speedup, and it is not the speedup people describe.

What actually takes the time #

If you have not shipped one of these, the distribution will surprise you. Roughly, per app:

The core feature is the model running, the filter working, the formula computing. It is the part you think about before starting. Everything around it is settings, storage, search, error states, empty states, permission flows, the case where the download fails halfway, the case where the user has 0.4 GB of free space. Polish is making it feel good rather than merely work. And shipping is store listings, screenshots, descriptions, privacy declarations, review rejections, icon sizes, and the compliance paperwork on two platforms.

That last fifteen percent is entirely uncreative and completely unavoidable, and it is where a lot of side projects die two weeks from done. Budget for it or you will resent it.

The error and edge cases in the middle fifty percent are the real difference between a demo and a product. A demo transcribes ten clean seconds. A product chews through forty minutes of rambling audio on a phone with four gigabytes of RAM without losing the recording when the user takes a call.

The honest accounting #

These apps are free. No subscriptions, no ads inside them, no data sold. They earn approximately nothing.

I want to be straightforward about that, because there is an entire genre of indie developer writing that implies a revenue story it never quite states. There is no revenue story here.

What I get instead is tools I actually use. I use all six. That was the bar for building each one, and it is the only bar that reliably produced something worth finishing.

Skills that transfer: on-device inference, signal processing, mobile performance work. Every one of these was a genuine technical education and I would not have got it from a course.

Something to point at, since shipped work is worth more in a conversation than any description of what you could build.

And the thing itself. Six things exist that did not exist before. If that does not feel like enough, do not do this, because for long stretches it is the only compensation on offer.

The infrastructure costs nothing because there is no infrastructure, which is what makes free sustainable. An app with a server has a monthly bill that has to be paid by someone, forever, and that is where subscriptions come from. That is also why I host everything else on free tiers.

What I would tell someone starting #

Build the thing you will use, not the thing with a market. You are one person with no marketing budget, so the only reliable source of motivation over the months it takes is that you want the thing to exist. Every project I started for a reason other than that died.

Pick a constraint and let it do the design work. Mine is no servers. It answers a startling number of questions before I have to think about them, and the answers are usually good.

The unglamorous middle is the product. Anyone can get a model running in a weekend. The search, the storage, the error handling, and the empty states are why someone opens it twice.

Ship the small version. All six of these do less than the version I designed in my head, and they exist, which the designed version does not.

Budget for the last fifteen percent: store submission, screenshots, privacy declarations, and review rejections. It is not fun and it is the difference between built and shipped.

And do not build a backend until you have proven you need one. Most small apps do not, and the ones that do usually discover it after they have users, which is the right time to find out.

The build stories, in the order they happened: the offline AI chat app, the speech-to-text app, the arcade game, the GPS speedometer, the credit card tracker, and the retirement planner.