On September 27, I noticed that an app I had spent ten months building had received an update.
I was no longer working for the company, but curiosity got the better of me. I opened the Play Store, installed the update, and launched the app.
For the first few seconds, I thought something had loaded incorrectly.
The spacing looked strange. Text that had once been carefully sized was now unnecessarily small. Containers had been added where they were not needed. Shadows extended outside their content. Screens that once followed the same visual language now looked as though they belonged to different applications.
I moved from one screen to another, trying to find the product I remembered.
The features were still there, but the experience had completely changed.
Ten months of careful work had become almost unrecognizable in a single update.
To explain why that moment affected me so much, I need to go back to the beginning.
Rebuilding the App From Scratch
I joined a small service based company as a Flutter developer.
It was a very small company, so there was no manager between me and the founder. I communicated directly with him.
The company was working with a partner from Kenya on a dating application. I never completely understood the exact nature of their partnership, but our company was responsible for developing the product.
A version of the app already existed. It had been created as a Progressive Web App and published on the Google Play Store. It had around 200,000 downloads, but its submission to the Apple App Store had been rejected.
I was hired to rebuild the mobile application from scratch using Flutter.
I was the only Flutter developer working on it.
There was no Flutter team around me. There was no senior mobile developer reviewing my decisions or another app developer sharing the workload. I was responsible for the complete mobile application.
The architecture, interface, features, performance, bug fixes, releases, and production issues all came through me.
The company had a backend developer, but everything related to the Flutter application was my responsibility.
I knew that I could not treat the project as a collection of screens that only needed to look correct. The app already had users, and the company wanted it to continue growing. Whatever I built needed to survive future features, production issues, and changes in business requirements.
I started by planning the architecture.
I separated features and responsibilities, created reusable components, and organized the code so that it would remain understandable as the app became larger. I wanted another Flutter developer to be able to open the project in the future and understand where things belonged.
The designs given to me were decent. They provided a good foundation for a professional dating application.
Over the following months, I converted those designs into a complete Flutter application on my own. On some days, I was working on the user interface. On others, I was investigating performance problems, connecting APIs, fixing production issues, preparing releases, or discussing changes with the founder and backend developer.
As the only Flutter developer, I had to understand the entire mobile application rather than only one part of it.
After several months of work, we released the rebuilt app on the Google Play Store.
It launched successfully.
During the time I worked on it, the app grew from approximately 200,000 downloads to more than 1.5 million downloads.
I cannot claim that my development work alone caused that growth. Marketing, the existing audience, and the business behind the app also played important roles.
Still, the rebuilt application was stable enough to serve that growing audience, and I knew how much work had gone into making that possible.
I was proud of what I had built.
Building for the Phones Our Users Actually Had
One of the most important lessons I learned from the project was that developers cannot judge an application only by how it performs on their own devices.
Many of our users were in Kenya and used inexpensive Android phones. In Indian currency, some of those devices would cost around ₹5,000.
An application can feel smooth on a powerful development device and still provide a terrible experience on a phone with limited memory, a slower processor, and an unreliable internet connection.
I had to consider those users while building every feature.
Images needed to be handled carefully. Animations could not be added simply because they looked attractive. Screens could not perform unnecessary work in the background. The app needed to work across different screen sizes, Android versions, and hardware limitations.
These were not theoretical concerns.
They affected real people using the application every day.
Because I was the only Flutter developer, I was also the person who had to investigate when something did not work properly on those devices. I could not pass the issue to another mobile developer. I had to understand the cause and find a solution myself.
During the following months, I continued adding features and solving production problems. Many feature ideas were heavily inspired by other dating applications, but it was still my responsibility to make them work properly inside our product.
After around four months in production, the application was running smoothly.
It was not perfect. No real product is. There were occasional problems and improvements that still needed to be made, but there was no major issue affecting the complete application.
The product had become stable, familiar to its users, and capable of supporting its growing audience.
Then I had my first serious disagreement with the founder.
The First Conversation About AI
I had access to Antigravity, an AI powered development environment that provided an experience similar to VS Code.
The company did not provide or pay for it. I had access through a personal subscription.
I did not use it to build the entire application for me.
I mainly used it when a complicated issue affected several files and required a wider understanding of the codebase. A normal chatbot could suggest a possible solution, but it would not always understand how different parts of a large project were connected.
Antigravity could inspect more of the codebase and help me trace those connections.
That did not mean I accepted whatever it generated.
I reviewed every file it modified. I read the code, checked the logic, tested the result, and made sure the solution followed the architecture I had created.
I had built the application from the beginning. I understood how its parts were connected, so I could usually tell when a generated solution did not fit the project.
One day, I was using Antigravity while investigating a critical issue.
The founder saw it on my screen.
“What is this?” he asked.
I explained that it was Antigravity, an IDE similar to VS Code but with integrated AI features.
His reaction was immediate.
“Why are you using it? It leaks company data and violates privacy.”
His concern about privacy was not completely unreasonable.
Companies should think carefully about how their source code is shared with AI services. Developers should also be careful about what information they provide to external tools.
However, the company had no written AI policy. There was no list of approved tools, no security guidance, and no rule explaining what developers were allowed to use.
I explained that the tool could not independently publish or commit our code. I reviewed every change and remained responsible for what entered the project.
I also told him that if he did not want me to use it, I would stop.
He then said that the tool had committed code to GitHub on a Sunday.
That did not make sense to me.
We did not work on Sundays, and Antigravity could not create a commit unless I reviewed the changes and explicitly gave it a command.
I opened the repository history and showed him the commits.
There was no unexplained Sunday commit.
Nothing had been uploaded secretly.
The conversation still continued in front of the other employees.
Later, when I spoke to them about what had happened, they told me that this type of interaction was common. They felt that the founder found it difficult to accept that someone else might understand a technical subject better than he did.
I decided not to argue further.
I continued working on the application.
How I Used AI as a Solo Flutter Developer
I never believed that developers should avoid AI completely.
I also never believed that they should become completely dependent on it.
Being the only Flutter developer meant that I did not always have another mobile developer available to discuss a difficult problem with. AI sometimes helped me explore possibilities or examine connections that I might otherwise have spent hours tracing manually.
It could help me understand unfamiliar behavior, investigate bugs, reduce repetitive work, or suggest possible solutions.
But it could also produce incorrect code with complete confidence.
That was why I treated AI as an assistant.
It could suggest a direction, but I remained responsible for deciding whether that direction made sense.
If I could not understand a generated solution, I did not want it in the project.
If the solution broke the architecture, I rejected it.
If it solved one problem while creating another, it was not a useful solution.
For some time after the conversation with the founder, I avoided using Antigravity in front of him. I continued using it privately when I believed it could help, but I reviewed everything before allowing it into the project.
AI was helping me perform my job.
It was not performing my job for me.
A few months later, the founder’s opinion about AI changed completely.
“Give It to Claude”
The founder purchased a Claude subscription.
After that, whenever the backend developer encountered a difficult issue and asked him for a suggestion, the founder often gave the same answer.
“Give it to Claude. It will fix it in two minutes.”
The first time I heard this, I remembered our earlier conversation.
When I had used AI carefully and reviewed its work, it had been described as a privacy risk.
Now that the founder had purchased his own subscription, AI was being treated as the fastest and most capable developer in the company.
The issue was not that he had changed his mind.
People are allowed to learn. They are allowed to discover new tools and reconsider their previous opinions.
The issue was how quickly AI went from something dangerous to something that was expected to solve every technical problem.
Software problems rarely exist inside a single prompt.
A tool may generate an answer in two minutes, but it does not automatically understand why the existing code was written in a certain way. It does not know every business decision behind the product. It does not know what users already expect or what another change might silently break.
A fast answer is not always a correct answer.
Over time, I started feeling that the founder no longer saw AI as something that could help the development team.
It felt like he believed it could replace the team.
The Final Meeting
Last week, the founder called everyone into a meeting.
There were only three employees, so those three people represented the entire company team.
He told us that his partner had decided to stop future development of the dating application and focus on marketing.
Because active development was being stopped, the company had decided to remove the development team.
September 30 would be our final date.
The next day, the founder called me again.
He told me that the company would pay me for the entire month, but I could leave immediately if I wanted.
I decided to leave.
I was disappointed, but I accepted that business decisions can change. Projects lose funding. Partners change direction. Small companies reduce their teams when priorities shift.
These things happen.
I believed my work on the application had ended.
Then the September 27 update appeared.
Seeing the New Version
When I opened the updated application, I did not know exactly how the new interface had been created.
I only knew that it no longer felt like the product I had spent ten months building.
It looked as if individual screens had been created separately without anyone checking whether they belonged to the same application.
A dating app is not simply a collection of buttons, profile cards, images, and text.
Its design affects how comfortable people feel while using it. Spacing, typography, colors, and consistency all contribute to whether the application feels trustworthy and professional.
Users may never consciously notice those details when they are handled properly.
They notice them when they are gone.
For ten months, I had tried to create consistency across the entire application. I built reusable components so that buttons, cards, text, and spacing behaved the same way on every screen.
I had also designed those components while thinking about the low end devices used by many of our customers.
The new update had removed much of that consistency.
What hurt was not simply that somebody had changed my design.
No developer owns a product forever. After we leave a company, other people will modify our work. Some of those changes may even be better than what we originally created.
What hurt was seeing thoughtful work replaced without the same level of care.
I had built the Flutter app from the first line of its architecture to the version used by more than a million people.
Now, I could barely recognize it.
I gave the founder honest feedback about the new version. I mentioned the excessive spacing, small text, unnecessary containers, and broken shadows.
Shortly afterward, my account on the dating application was suspended.
That was the final response I received.
The Real Problem Was Not AI
It would be easy to say that AI ruined the application.
I do not believe that is completely true.
AI did not decide that the update was ready for release.
AI did not decide to remove the development team.
AI did not skip the design review or ignore the experience of existing users.
People made those decisions.
The real problem was the belief that generating code and building a product are the same thing.
They are not.
Code is only one part of a product.
The rest comes from understanding users, remembering previous decisions, testing assumptions, noticing small inconsistencies, and caring about what happens after the code reaches production.
AI can generate a screen without knowing why the old screen was designed in a particular way.
It can rewrite a component without understanding the devices on which it needs to run.
It can suggest a solution without having to maintain that solution later.
It does not receive complaints from users. It does not investigate production failures. It does not take responsibility when something breaks.
That responsibility still belongs to people.
What I Took With Me
When I first saw the update, it felt as if ten months of my work had disappeared.
After thinking about it, I realized that an update could change the application, but it could not remove what I had learned while building it.
I built a real mobile application from scratch as its only Flutter developer.
I designed its architecture, created its screens, implemented its features, optimized its performance, prepared its releases, and handled its production issues.
I worked on it while it grew from approximately 200,000 downloads to more than 1.5 million.
I learned how to design for users with low end devices and unreliable network connections.
I learned how to make decisions without having another Flutter developer beside me.
I learned how to use AI without allowing it to replace my own understanding.
Those lessons are still mine.
The current version of the application may no longer represent the quality of my work, but it cannot erase the experience I gained while building it.
I am not worried about developers using AI.
I use AI myself, and I believe it can make good developers more productive.
What worries me is when people confuse the ability to generate code with the ability to build a good product.
AI can make a skilled developer faster.
It can also help a careless person create problems faster.
The difference is not which subscription someone purchases.
The difference is whether someone is still thinking, reviewing, testing, and taking responsibility for the result.
AI can generate code in two minutes.
Judgment takes much longer to build.
Top comments (1)