Claude Opus helped a business analyst launch two apps in two weeks without a team

An experiment with AI development showed that a person without programming experience can already bring a mobile product to market. In two weeks, a business analyst assembled two Flutter applications for RuStore and spent about 80 hours on it.

How the experiment went

The author approached the task as a hypothesis test: if a business analyst knows how to decompose requirements, write user stories and acceptance criteria, that might be enough to work with an AI assistant instead of a regular team. For the test, he chose two different products — a time tracker "168 Hours" and F1 Tycoon, a game about managing a Formula-1 team. He also selected the stack through the model: Flutter and Dart for cross-platform development, Supabase as a free backend for the MVP.

The schedule turned out almost like a full sprint. The first two days were spent setting up Flutter and Android Studio, then a conveyor assembly of screens for "168 Hours" began. Next came the first heavy stage — integration with Supabase, where authorization and network calls quickly turned into a series of cyclical fixes.

After that, the author tackled F1 Tycoon, but the game project itself revealed the main limitation of current models: the more files and dependencies, the worse they maintain overall architecture. On day 14, both applications passed moderation in RuStore, and direct expenses remained at zero.

Where AI accelerated the work

According to the author, the best results came not from free tools, but from stronger commercial models. Free options often produced code that wouldn't compile and UI in the style of old textbook projects. GPT-5.2 turned out to be noticeably more stable, but it was Claude Opus that delivered the cleanest code, modern interface, and best preserved the context of the dialogue. But there's something more important: business analyst skills unexpectedly aligned with what good prompting requires.

"AI is like a junior developer: the more precise the requirements, the

more precise the result."

In practice, this looked not like magic, but like a very fast cycle of task setting and result verification. The author described a screen, received code, inserted it into the project, ran it on the phone, and returned specific errors to the model. This mode was like working with a very fast remote junior: the answer comes in minutes, and fixes can be checked immediately on a real device. In this scheme, AI turned out to be particularly useful for several typical tasks:

• generating UI components and screens in minutes
• choosing a starter stack for a newcomer without a team
• explaining errors and terminology in simple language
• writing boilerplate code and basic business logic
• preparing for publication: build signing, keys, build.gradle configuration

Where problems began

The most painful area was integrations. Connecting Supabase looked simple on paper, but in reality, one fix easily spawned the next bug. The author describes a typical scenario: the model fixes an email authorization error, after which the registration screen breaks, then the next patch touches yet another file.

On short tasks this is tolerable, but in a large project it turns into an exhausting game where fixing a local problem doesn't guarantee the app will even compile as a whole. The second problem was model memory. When F1 Tycoon grew to 50+ files, the AI stopped confidently remembering key classes, project structure, and previous architectural decisions.

To reduce context loss, the author created a separate "memory file" describing the structure and fed it to the model at the start of each session. This helped, but didn't fully solve the issue. An additional risk was request limits: at a critical moment, access to the best model could be cut off for several hours, and all development simply stopped.

By the end of the experiment, both releases made it to the store, but together received only 14 downloads.

What this means

The story doesn't prove that AI has already replaced developers, but it does show something else well: the threshold for creating an MVP has dropped sharply. If a person knows how to formulate requirements, break down tasks, and patiently debug, they can already reach a working release. But complex integrations, large-project architecture, and quality control are still areas where without an experienced engineer, speed quickly hits a ceiling even in solo experiments.