Cloning an app with AI

I had been using the Android app CloudPlayer to play my MP3 files on my Google Drive. The app was missing some features I wanted, and I was also curious about how easy AI makes it to clone an app, and how much this could threaten the indie-hacker ecosystem.

The features I wanted were an icon indicating downloaded songs next to each track name, the ability to remove individual tracks from the cache, and information about how much storage space was used and how much remained. So I decided to create DriveMP3 entirely with AI assistance:

I started by asking Gemini to create a specification based on CloudPlayer. I then asked Claude Code to create a version plan based on the specification. The initial version would only connect to Google Drive and display the MP3 files stored there. Then I asked Claude to implement each version. It managed to one-shot each version with only making small mistakes once or twice. After verifying that each version worked as expected, I asked Claude to implement the next one. I did not edit any of the generated Kotlin code. 

Each version took Claude about 15 minutes to implement and consumed roughly $13 worth of API tokens on average. The total API cost was $93. This is much more expensive than the cost of CloudPlayer (free with ads, $15 without ads), especially when you also count the two days I personally spent for design and testing.

Note that API tokens are the most expensive way to use Claude Code. The advantage of API credits is that they remain valid for one year. If you are using Claude less than once a month, API tokens are the way to go. If you are using it more frequently, the other pricing plans will be much cheaper.

AI-assisted cloning creates three potential threats for app developers: 

1. Users who build personal alternatives.
2. Hobbyists who clone a few apps each year for personal use and release their versions as open source (I am an example of that). 
3. Businesses that systematically identify promising apps, reproduce their visible functionality, and compete through stronger distribution and marketing.

In this experiment, cloning the app cost more than $100 when the value of my own design and testing time was included. If your price is low enough that ordinary users will not bother searching for an open-source alternative, hobbyist clones may have little effect on your sales. Note that I am talking about a one time payment here, if you are using a subscription model, the incentives for cloning increase.

However, an app cloning business can use the $200/month plan to create an app every couple of days. Note that it also takes time to publish an app on Google Play. Let's assume the time you spent makes the total $300/app. If they market the clone effectively and provide a comparable user experience, they may capture your potential customers. If your app is easy to clone, you might only be able to make money from it until it becomes popular and appears on the radar of cloning shops.

What can you do to make cloning harder? An AI can only clone what it can see (the client side) or what is easily predictable (standard business logic). Apps like CloudPlayer fall into this category. To build a defensible moat against AI-assisted clones, you need to shift your value proposition away from surface-level features and toward capabilities that are deeply embedded and difficult to replicate. This means you have to be an expert in a field with complex workflows and compliance requirements and have domain specific data. If your app has a social component (e.g. Slack), if you get lots of users quickly, a copycat can clone the code in a week, but they cannot clone the teams already communicating on it.

The age of casual apps that can be sold through word of mouth has come to an end for indie hackers. The main expense is no longer development but marketing. Defensibility now comes from better marketing, backend depth, proprietary data, network effects, distribution channels, and execution speed.

For non-casual apps, AI makes building a working demo ("0 to 1") almost effortless. Taking a system from "1 to 100", ensuring reliability, backward compatibility, air-gapped security, zero-downtime migrations, and maintainability, requires deep engineering domain knowledge that AI cannot autonomously govern without human oversight. The person writing the prompt, validating the architecture, and shipping the code is increasingly the person deciding what to build.

Music: Zombie (Afro House Remix)