Shipping native apps as a PM, with AI writing the code

This year I shipped an Android app without writing most of its code by hand. It’s a reality-TV voting app in two languages, built in React Native with AI coding tools from the first screen to the store listing, and it has passed 10,000 downloads. I’m now building a second one, a native iOS app in SwiftUI, aiming for a December release.

The decision this essay helps a PM make is narrower than “should PMs code”. It’s when you should build the thing yourself, and what you’re signing up for when you do. Once AI writes the code, the build gets cheap. Scope, quality and ownership stay exactly as expensive as they were, and all three land on you.

When building it yourself is the right call

In my day job I build AI-assisted prototypes and internal tools for live demos, and they’ve cut product feedback cycles from weeks to days. That’s the low end of PM building. A prototype answers a question faster than a spec can, then it gets thrown away. Nobody depends on it.

Shipping is a different commitment, and I want three things to be true before I make it:

The open question is about users. If what I need to learn is whether people install, come back and tolerate the ads, only a shipped product can tell me. A prototype answers questions about the idea; a store listing answers questions about behaviour.
I can own the whole lifecycle alone. A store app comes with reviews, policy changes, OS updates and a release train. If any of that needs a team, I shouldn’t start.
The full-time job is untouched. Everything I ship runs on evenings and weekends.

The voting app passed all three. The show runs in seasons, the audience is defined, and the job is small: let people vote, and bring them back each week when there’s a new vote to cast. A companion web property carries the weekly season updates. You can read how it came together in the voting app case study.

What changes about scope

When an engineer builds your feature, scope has a natural brake. Every addition costs a conversation, an estimate and a trade against something else on the board. With AI writing the code, that brake is gone. A new screen is one prompt away. So is a settings panel, a second sign-in method, or a feature nobody asked for.

For a PM who builds, the brake has to come from the product’s core loop, and I write that loop down before I write the first prompt. On the voting app it’s short. The season moves in weeks, a weekly push notification brings people back for the next vote, and the vote itself takes seconds. Anything that doesn’t feed that loop waits. The AI will build whatever I describe with total confidence, so the loop is what decides what I describe.

Monetisation is a scope decision too, and the two apps get opposite answers. The voting app carries in-app ads. The iOS app will be free with no ads at all. Same builder, same tools, different call, because the question I ask is what the ad interrupts. A voting session is short and transactional, and an ad between votes costs someone a few seconds. The iOS app is a reading app, and an ad there interrupts the very thing the user opened it for. For that product I’d rather learn whether people keep coming back to read.

What changes about quality

AI-written code looks finished before it is. It compiles, the screens render, the happy path works. None of that tells you how it behaves on the phones and networks your users actually carry, or what happens on the edge cases you never thought to describe.

A PM-built product still needs a quality gate, and the PM has to define it, because there’s no QA team to inherit one from. On motomotar.com, my AI content operation, the gate is explicit: every page is scored against a rubric with publish bands at 85, 82 and 78, the local test suite runs 3,858 assertions before a pipeline change ships, and publishing is always my manual action. The apps follow the same principle at a smaller scale. Nothing reaches the store until I’ve decided it should, and the code generator gets no say in whether the work is done.

The faster the build, the more the gate matters. When an engineer spends a week on a feature, review happens along the way: in standups, in code review, in the questions they ask you. When the AI produces the same feature in an evening, the only review is the one you insist on.

What changes about ownership

Building it yourself collapses roles that are usually separate. I’m the PM who decided the feature, the engineer who shipped it, the person who reads the reviews, and the one who notices if the weekly notification didn’t go out. That’s clarifying. There’s nobody to hand a bad decision to, and no handoff where context leaks.

It also means every shipped product becomes a standing commitment. I built a Chrome extension that works, and I never uploaded it to the store. When building is cheap, the build stops being the decision. The decision is whether I want to own the thing in public, with its users, its updates and its listing. I didn’t, so it stays on my machine.

Choosing not to ship something you built is an ordinary product call. It gets easier once you count shipping as the start of an obligation. The voting app was worth that obligation to me. The extension wasn’t.

What this means if you’re the PM

Build it yourself when the open question is about user behaviour and you can carry everything that happens after launch. When the question is about the idea, a prototype is enough, and it’s cheaper to throw away.

Write the core loop before the first prompt. With AI writing the code, it’s the only scope brake you have left.

Decide monetisation by asking what the ad interrupts. Two products from the same person, built with the same tools, can need opposite answers.

Define the quality gate yourself and keep the release decision with a human. A code generator’s confidence is no evidence that the code is right. Treat “built” and “shipped” as two separate decisions, and make the second one on purpose.

The download count is from the app’s public Play Store listing; the motomotar gates are documented in the motomotar case study.