Whether AI can build an app is not the interesting question anymore. A couple of years ago it sounded ambitious. Now I already know the answer, because I did it: I used AI coding agents to build and ship RYZA on both iOS and Android.
The question I actually care about is different. It is not can AI build an app. It is can AI help you build an app that survives becoming a real product. That is a much harder problem, and it is what I have been learning while building RYZA.
The app I built with AI
I am building RYZA, a voice-verified affirmation alarm app for iOS and Android. The idea is simple: an alarm rings, and instead of dismissing it with a tap, the user reads a chosen affirmation or goal out loud, and the app verifies that voice interaction before the alarm experience is done.
Describing only that screen to an AI would not be a hard prototype to produce anymore. But RYZA is not just that screen. The real application involves alarm scheduling, voice recognition, application state, background behavior, notifications, widgets, subscriptions, free and premium features, localization, Firebase, iOS-specific behavior, Android-specific behavior, App Store requirements, Google Play requirements, analytics, reliability, and actual device testing. That is where AI app development gets interesting.
My stack: AI, Flutter, Firebase, and real platforms
RYZA uses Flutter, because I wanted to build for both iOS and Android without maintaining two separate applications. Flutter builds both from one shared codebase, with room to drop into platform-specific code when native functionality is required. That matters, because one codebase does not mean iOS and Android are the same. They are not. Flutter reduces duplication. It does not eliminate platform differences.
I also use Firebase, mostly for analytics and the backend pieces I don’t want to run myself, and RevenueCat for subscriptions, which handles the in-app purchase plumbing across both platforms so I am not writing it twice.
AI coding agents sit across that entire stack. I mostly use Codex, and more recently started using Claude Code seriously too. I wrote about how those two differ in practice if you want the longer version. That combination has changed how fast I can investigate and implement things. It has not removed the complexity underneath them.
What AI is extremely good at
The first thing AI changes is speed, and not just typing speed. Exploration speed. Before AI coding agents, entering an unfamiliar part of a project meant searching through files, tracing references, reading documentation, inspecting dependencies, and slowly reconstructing how something worked. Now I can ask it to trace the complete flow for a feature, show me where the state changes, which services are involved, and what could break if I touch it.
That saves a real amount of time, and it is useful to me in a few specific ways. Understanding existing code is one: as a project grows, remembering every past decision becomes impossible, and AI can inspect the codebase and reconstruct the logic faster than I can. Implementing features is another. Once a requirement is clear, modern coding agents turn it into working code well. Debugging changes shape too, because instead of only searching an error message, I can ask an agent to investigate why the error exists in the context of my project. Refactoring gets easier, since AI spots duplicated logic and structural mess faster than I can by reading every related file by hand. And reviewing becomes a habit I actually keep: I can have one agent implement something and a second one examine the result, which has become one of my favorite uses of having more than one AI coding tool available.
What AI is not good at deciding for you
This is where a lot of “build an app with AI” content gets misleading. AI can write the implementation. Someone still has to decide what the product should actually do.
Should RYZA allow unlimited standard alarms for free? How many voice-verified alarms should be free? Which features belong in Premium? What happens if voice verification fails? What should happen if the operating system interrupts the alarm? How aggressive should the app be about keeping someone from going back to sleep? Which of those behaviors feels motivating, and which feels annoying?
None of that is a coding question. It is a product question. AI can help me reason through it. I still have to make the call.
The biggest surprise: coding wasn’t the hardest part
This is probably the biggest lesson from the whole project. Once AI got good enough at coding, writing code stopped being the main bottleneck, and the bottleneck moved somewhere else: deciding what to build, preventing regressions, understanding platform restrictions, debugging real-device behavior, managing subscriptions, passing store review, designing pricing, positioning the product, finding users, improving retention. That is a very different development problem than the one I started with.
App Store rules don’t disappear because AI wrote the code
This is where the gap between an AI-generated prototype and a production app shows up. Apple does not care whether you wrote the app by hand, hired a developer, or generated most of it with AI. The finished product still has to follow App Store requirements, and Apple has specific rules for auto-renewable subscriptions that I only actually read closely after RYZA needed me to.
RYZA has gone through real App Store review issues, and they taught me something specific: AI can help build the implementation, but it cannot make the platform’s rules disappear. I still had to understand what Apple was actually asking, and figure out whether the problem was my code, my configuration, my metadata, my subscription setup, or the way the reviewer accessed the feature. That is production development, not prototyping.
Cross-platform doesn’t mean platform-independent
Flutter has been a good choice for building RYZA across iOS and Android, but there are moments where the shared-codebase abstraction ends. Flutter covers a lot, but not everything: some things still need native libraries, platform-specific code, or a custom plugin when the shared framework does not reach that far. An alarm app is a good example of why. Operating systems care deeply about background behavior, notifications, permissions, battery management, and alarm scheduling specifically. AI can understand Flutter perfectly and still need to reason about a completely different set of platform rules underneath it. Build once does not mean debug once.
AI can generate code faster than you can understand it
This is one of the more dangerous parts of AI coding. A developer manually writing 500 lines probably understands most of them, because they wrote them gradually. An AI agent changing 500 lines in a few minutes gets the code out faster than your understanding of the system can keep up.
That creates a new kind of debt. Call it understanding debt. The code works, but I do not fully know why. Then another feature gets added. Then another AI refactor. Then another bug fix. Eventually a project can become something I technically own but do not really understand anymore. I have gotten a lot more careful about that.
My rule: investigate before you modify
One habit has helped more than anything else. Before letting an agent make a large change, I ask it to investigate first: don’t modify anything yet, trace the existing implementation, identify the relevant files, explain why it behaves the way it does now, and propose the smallest safe change. I review the plan, and only then does implementation start.
That sounds slower. In practice it is usually faster, because fixing an unnecessary AI-generated refactor costs a lot more than spending two minutes understanding the change first.
Codex and Claude Code don’t work exactly the same way for me
I use Codex more often and have used it longer. In my experience it tends to be relatively task-focused. I give it something to do and it generally concentrates on that. It can misread an instruction, and it occasionally makes a decision I did not ask for, but overall I find it easy to control.
Claude Code entered my workflow more recently, and what surprised me is how proactive it can feel. I might ask it to change one thing and it starts investigating the surrounding system. Sometimes it finds something important I did not ask about. Sometimes I want it to stop investigating and just do what I asked. Both code extremely well. Their working styles are just different, and that has made me realize choosing an AI coding agent is not only about benchmark scores anymore. It is also about how much autonomy you want to hand it. I go into more detail on that difference in Claude Code vs Codex.
Vibe coding works. Production changes the vibe.
I understand why vibe coding got popular. It is genuinely satisfying: you describe something, the AI builds it, you run it, it works. But the workflow changes as soon as the app becomes valuable enough that you do not want to break it.
Early development looks like idea → prompt → code. Production development looks like requirement → investigation → plan → implementation → review → test → release → observe → fix. AI can participate in every one of those stages. The stages themselves do not disappear.
AI makes building easier. That makes distribution harder.
There is a consequence to this that does not get discussed enough. If AI makes software dramatically easier to create, more software gets created, and building something stops being much of a competitive advantage on its own. Distribution gets more important. Brand gets more important. Retention gets more important. Actually understanding a user’s problem gets more important.
That is why I am spending more and more time on ASO, positioning, short-form content, Reddit, pricing, subscriptions, retention, search, and actual user feedback. The code is only the beginning.
Would I build another app with AI?
Absolutely. I do not think I would want to go back to my old development workflow. AI has made me dramatically faster, let me investigate things I would not have attempted as quickly before, and lowered the cost of experimenting. It makes ambitious ideas more realistic for small teams and independent builders.
But I would approach the next project differently. I would spend less time asking whether AI can build something, and more time asking: if AI can build this easily, can other people build it just as easily? And after that: why would anyone choose mine? That is becoming the important question.
Can you really build an app with AI in 2026?
Yes, absolutely. You can use AI to help design, code, debug, refactor, test, and maintain real software, and you can combine AI coding agents with frameworks like Flutter, services like Firebase, subscription infrastructure like RevenueCat, and the existing Apple and Google ecosystems to build real products.
But do not confuse AI can build the code with AI can build the business. Those are different things. The code is getting easier. Product decisions are still hard. Distribution is still hard. Getting people to care is still hard. Making software reliable enough that people keep using it is still hard. That is the part I am most interested in now, because after building RYZA, my biggest lesson is not that AI can build an app. I already knew that. It is that AI is making software easier to build than ever, which makes everything that happens after the build matter more than ever.