AI mobile app architecture is becoming a standard part of modern development workflows.

I got a new project from a client — a mobile app for managing work schedules in a small company. I sat down, opened my IDE, and before writing a single line of code, I did something I probably wouldn’t have done a year ago — I asked AI to help me design the project structure.

In this post, I’ll walk you through how that worked in practice, what surprised me, and where AI definitely fell short.

AI as a standard tool

It’s 2026 now. At this point, pretty much everyone has stopped pretending they don’t benefit from AI tools in their daily work. They’ve become part of the routine — just like search engines or developer forums used to be. Today, algorithms are deeply embedded in how we build software and electronics: from automating technical documentation analysis, to helping generate block diagrams, to assisting with writing code.

Using AI lets you move faster and work more efficiently. It frees up time to focus on architecture and solving real client problems instead of “fighting the tooling” in areas where machines already do a great job. But like any craft, a tool is only as good as the person using it.

Today I want to show this through a typical work scenario — planning the structure of a new mobile app. I’ll point out where AI can genuinely support decision-making, and where human judgment and critical thinking are still absolutely essential.

Context first — without it, AI is guessing

Before I pasted anything into a chat, I had to answer a few questions myself: what does the client expect, what kind of app is this, who’s the target user, which platform, and what tech stack?

I chose Flutter — one codebase for both Android and iOS. I work with Flutter daily, I’ve built a few apps with it already, and honestly — I just feel more comfortable with it than with native languages.

How I wrote the prompt

For this experiment, I used Claude by Anthropic. Instead of writing something vague like “build me a Flutter app…”, I took a moment to be specific:

I’m building a cross-platform mobile app in Flutter (Android + iOS). The app is for managing work schedules in a small company (~20 employees). I need a project structure based on Clean Architecture, split into layers: data, domain, presentation. Tech stack: Riverpod (state management), Dio (HTTP), Isar (local database). Generate a folder and file structure.

Here’s what I got back (simplified for the article):

 

And honestly? My first reaction was: “I could’ve written that myself.”

But then I realized — manually creating dozens of folders is pure overhead I don’t actually need. Sure, I could do it myself, but I don’t have to. With a fairly simple but well-structured prompt, I got exactly what I needed: a clean, solid structure. Probably very close to what I would’ve built anyway — but it would’ve taken more time, and I’d likely tweak it a few times along the way. AI did it in seconds.

After refining the prompt, the chat added actual .dart files (relevant for Flutter). On top of that, it generated a script that created the full folder hierarchy with empty files ready to be filled in later.

In short: in a few minutes and with a couple of prompts, I had a complete project structure — folders, files, and everything already set up on my machine.

Where AI starts to struggle

As this example shows, AI handles simple, repeatable tasks really well. The problem starts when a project goes beyond a “typical template.” And in our work at Indoornavi, solving non-standard problems is just everyday reality.

Recently, we worked on a major refactor of an older Flutter app. We had to remove outdated dependencies and bring the code up to modern Android and iOS standards. The app controlled machines via Bluetooth.

At first, it seemed straightforward. In the old setup, the flow was simple: the phone connected to the main Bluetooth module, which then passed commands directly to the “brain” (the main control unit).

Things got complicated when the client decided to expand the system with new battery-powered devices (like additional cabin panels). Without wired power, the entire communication model changed. Now the main Bluetooth module not only had to receive signals from the phone, but also independently connect wirelessly to these new devices.

The biggest challenge? The new version of the app had to fully support this more complex wireless system — while still maintaining full backward compatibility with older devices, where everything worked over a wired connection. On top of that, every component had to be configurable from the phone.

I described all of this to the AI and asked it to design an architecture that could handle both worlds.

What I got looked fine — at first glance. But after digging deeper, it became clear that combining modern features with backward compatibility completely threw the AI off.

What went wrong?

The AI essentially produced “spaghetti code.” It tried to handle both types of machines inside one massive decision block. The generated structure forced the app to constantly check conditions for every single action (like changing a setting): “Is this an old machine? If yes, send the command this way. If not, do it differently.” Instead of a clean solution, it tightly coupled configuration logic with the specific Bluetooth communication method. If we had used that code, the app would’ve struggled with performance and likely dropped connections when configuring newer devices.

What should it look like?

In professional system design, we avoid constant conditional checks like that. Instead, we use an abstraction layer.

Think of it as a universal translator: the app interface issues a simple command like “Save configuration,” without worrying about what hardware it’s talking to. Under the hood, a mechanism detects the device type and selects the appropriate communication protocol.

This keeps the core application logic clean and prevents bugs when dealing with different generations of devices.

This example shows that AI is great at repeatable tasks, but struggles when a broader, system-level perspective is required. The role of the engineer is shifting toward system design and validation — AI helps you get started faster, but we’re still responsible for making sure the whole thing actually works in real-world conditions.

What’s next?

Project structure is just the beginning. In the next article in this series, we’ll look at filling that structure with actual logic. I’ll show how AI handles generating boilerplate code — and why, in some cases, auto-generated code can actually be more optimal than what you’d write by hand.

Stay tuned for the next one.

#CleanArchitecture #Flutter #AppArchitecture #AIinIT #PromptEngineering #ProjectStructure #MobileDevelopment #Riverpod #ArtificialIntelligence #SoftwareEngineering