One Threatened With Takedown, One Cracked: The Hardest Part of Indie Development Is Not Writing Code

A mini program with around 300 users was threatened with takedown over a phone call.

A macOS app had not earned much yet, but it had already been listed on a cracking site.

Neither story is big news.

But after reading them, I found them more real than all those articles about “building a SaaS in one day with AI” or “making money with Vibe Coding.”

Because when people talk about AI coding today, they usually talk about the first half: how AI helps you write code, how to make an MVP in a few hours, and how one person can now build a product.

But anyone who has actually built a small product knows that writing the code is only the beginning.

The rest is where AI may not help much.

Users will find you. Platforms will regulate you. Cracking sites will watch you. Privacy policies may expose you. Paid features may be bypassed. A small bug, a permission note, or a customer support phone number may become the thing you deal with at midnight.

Start with the first story.

A developer on V2EX built a watermark camera mini program with roughly 300 users. That sounds tiny, right?

Then a user called because of a location issue and threatened to report the product unless it was taken down.

The developer retested it and said location, watermark generation, and sharing all worked normally. Later, he reported the harassing call through 12321. Someone in the comments pointed out that he had left his phone number in the privacy policy and suggested using an email address instead.

That detail is painfully real.

When people build products, they may think leaving a phone number is responsible and professional.

But for an individual developer, it may also mean exposing yourself directly to every emotional user.

Users will not become gentler just because you are alone.

They will not lower their expectations because your product is free, cheap, or just starting out.

As long as they use your tool in real work, they will judge it like a real product.

This is one of the most underestimated facts about small products:

Fewer users does not mean fewer problems.

Fewer users only means less revenue.

A watermark camera sounds like a simple tool: take a photo, add text, add time, add location. But think about where it might be used.

Factory inspection. Field patrol. Attendance. Reimbursement. Construction records. Client proof.

In these scenarios, users are not using it for fun. If the location is wrong, permissions are unclear, or phone compatibility causes trouble, they may not “give feedback.” They may panic.

Because someone may also be pressuring them.

At that moment, telling them “I am just an indie developer” does not help.

They only ask: does this thing work or not?

This is the first gap between AI-generated code and a real product.

AI can help you build a watermark camera.

But AI cannot take that angry phone call for you.

Now look at the second story.

Another developer built a macOS app called Aion. Its function is roughly to quit apps automatically based on context, by detecting network traffic, audio, video, camera, and microphone usage, so it does not accidentally close an app during a meeting, download, or recording.

The idea is specific, useful, and very typical of an indie developer product.

Small, but valuable.

Then the author found that it had been listed on cracking sites such as MacKed.

His feelings were mixed.

On one hand, being cracked may mean the product has value. Nobody bothers cracking something nobody wants.

On the other hand, indie developer income is usually thin. If revenue has already been declining, seeing your hard work offered as a direct download feels cold.

The comments were also realistic.

Some said being cracked means the product has a market. Some said even Windows cannot stop cracking, so macOS should not expect miracles. Some suggested continuing to upgrade features, raising cracking costs, or moving the core value to backend services.

All of these are partly right.

Being cracked can be a form of being seen.

But that does not mean you should be happy.

Cracking may not destroy your revenue directly.

But it makes you realize for the first time that selling a client-only app is fragile.

Local-first apps have real benefits.

Better privacy. Stable experience. No server dependency. Buy once and use.

But the downside is also obvious:

Authorization is on the client, and cracking is on the client. Pricing is visible, and bypassing it is visible too. The lighter your app is, the easier it is for someone else to package and distribute it.

Then you have to choose.

Should you add online activation? Should you use subscriptions? Should you move part of the functionality to the cloud? Should you update frequently to increase cracking maintenance costs? Should you accept some piracy and focus on serving paying users?

These are not pure technical questions.

They are business trade-offs.

And many Vibe Coding tutorials skip exactly this part.

They tell you how to generate UI with AI, connect a database, deploy, launch, and collect payments.

But they rarely tell you:

What if users yell at you? What if the platform receives a complaint? How should your privacy policy be written? Should you leave your phone number? What if paid features get cracked? What if a piracy site posts a direct download? If your revenue is only a few hundred yuan, should you spend a dozen hours fighting piracy? Should you build anti-cracking measures or build more features?

These things are not cool.

But they are what keep a product alive.

In the past, many people could not build products because development blocked them.

They could not write frontend. They could not write backend. They could not deploy. They could not integrate payments. They could not build clients.

Now AI coding lowers that barrier.

If you cannot write it, AI can guide you. If you do not understand architecture, you can still piece together a first version. If you do not know macOS development, you can ask as you build. If you do not know mini programs, you can use documentation and AI to force your way through.

That is a good thing.

I do not oppose Vibe Coding.

In fact, I think it is one of the few directions worth trying for ordinary technical people in the next few years.

But the problem is:

AI lowers the development barrier, not product responsibility.

Before, you could not build it, so you had no users. Now you build it, and users arrive. Once users arrive, trouble arrives too.

Before, you had no revenue, so nobody cracked your product. Now you start charging, and cracking sites appear.

Before, you were not online, so platform rules did not matter. Now you are on mini programs, apps, and stores, so you live under platform rules.

Before, you had no privacy policy, so nobody found your phone number in it. Now you try to look proper, and the phone number becomes a harassment channel.

This is the real side of building products.

It does not end when you deliver code.

It is a relationship.

Your relationship with users. Your relationship with platforms. Your relationship with paying customers. Your relationship with pirated users. Your relationship with rules, complaints, copyright, privacy, and support.

Code is only the beginning of that relationship.

Many people who want side projects are easily misled by one sentence:

“Now AI can write code, so ordinary people can build products and make money.”

The first half is true.

AI can write code.

The second half is not guaranteed.

Because money does not automatically appear after code.

Money requires someone willing to pay. If someone pays, they have expectations. If they have expectations, there is support. If there is support, there are emotions. If there are emotions, there may be complaints. If there is revenue, someone may try to bypass it. If there is bypassing, there is protection cost.

AI does not remove this chain.

It only lets you enter it faster.

I have seen many technical people build products, and they often share one misunderstanding:

They believe that if the function is good enough, users will naturally understand them.

They will not.

Users only understand their own problems.

They do not care whether you are one person or a team. They do not care whether you built it after work or full-time. They do not care whether it was Vibe Coded or handwritten.

They only care:

Does it work? Is it accurate? Is it stable? Who fixes it when it breaks? Was it worth the money?

So the real lesson from the 300-user mini program is not “how unreasonable users can be.”

It is that even with only 300 users, once they use your product in real work, you have entered the real product world.

The real product world does not have a protective shield that says “I am an indie developer, please be kind.”

Of course, most users are normal.

But if you build products, you will eventually meet a few abnormal ones.

A malicious complaint. An emotional phone call. A bad review. A threat. A refund dispute.

That is enough to disturb your mindset.

So small developers should understand early:

Do not tie your private life too closely to your product.

Use email instead of a private phone number when possible. Use a ticket system instead of letting users call your life directly. Use a separate support account instead of your main account. Write permission explanations clearly. Keep logs before complaints arrive.

This is not big-company bureaucracy.

This is self-protection.

The platform bill must also be counted.

Why are mini programs attractive?

The entry point is close. Users are familiar with it. No installation is needed. The WeChat ecosystem carries trust.

But the cost is that you are not running a stall in front of your own house.

You are renting a small counter inside a mall.

The mall has rules.

Users can complain. The platform can act. Permissions need explanation. Privacy needs compliance. Location, camera, album, microphone — each can raise user questions.

You cannot only say “my code is correct.”

The platform looks at more than code.

It looks at user experience, rule text, complaint history, qualifications, and whether permission use is reasonable.

Many programmers dislike this.

Because it is not engineering-like.

Code is either right or wrong. Platform rules are not like that. User emotions are not like that.

Your function may be correct, but your explanation unclear. Your permission use may be reasonable, but users may feel it crosses a line. You may be misunderstood, but the platform may ask you to explain first.

That is the cost outside technology.

Now about piracy.

An indie developer seeing their software cracked will definitely feel shaken.

Especially before revenue becomes stable.

You work hard on features, bugs, documentation, and releases, then someone posts a cracked package that bypasses your paid feature.

The first reaction is often: I must stop cracking completely.

I understand that.

But we should stay calm.

Anti-cracking is worth doing.

Basic signature checks, license checks, purchase receipt validation, version updates, and server-side checks can all help.

But do not imagine one person can clean up every cracking site.

You may spend 100 hours on protection, and someone may spend 10 hours bypassing it. You patch a hole today, they upload another package tomorrow. You report one link, they change domains.

In the end, the one exhausted may not be the cracking site. It may be you.

So build protection, but do not bet your life on it.

More importantly, think clearly:

Where is your product’s value?

If the value is only in a local binary, it is naturally easier to copy. If the value is in continuous updates, cloud services, data sync, community, workflow, enterprise support, or stable experience, piracy can only take away part of it.

This does not mean every app must go cloud or subscription.

No.

Some tools are naturally suited for local one-time purchase.

But you need to know what you have chosen.

Local one-time purchase is user-friendly, private, and lightweight. But you also accept the revenue ceiling, anti-cracking pressure, and piracy risk.

Subscription and service models may bring more stable revenue and higher piracy difficulty. But they also bring servers, support, continuous delivery, and retention pressure.

No choice is free money.

Technical people often make one mistake: treating business problems as technical problems.

A user threatening takedown is not only a location issue. It is support, communication, permission, platform, and emotion management.

An app being cracked is not only an encryption issue. It is pricing, authorization, distribution, service shape, and user value.

Vibe Coding is the same.

It does not make business problems disappear.

It only makes you meet them earlier.

That is why these two small stories are worth writing about.

They have no funding, no viral growth, no million users, no ten-thousand-dollar monthly revenue.

One has 300 users. One got listed on a cracking site.

They are small.

But they are realistically small.

Real enough that many people preparing to do AI side projects should look at them first.

Because this is more useful than success stories.

Success stories tell you: you can do it too.

Small accidents remind you: yes, you can, but you must carry the consequences.

Carry what?

User uncertainty. Platform uncertainty. Revenue uncertainty. Piracy uncertainty. Your own emotional uncertainty.

Many people think the hardest part of indie development is writing code alone.

It is not.

Writing code alone is getting easier.

The hard part is facing consequences alone.

Doing support alone. Fixing bugs alone. Writing announcements alone. Handling complaints alone. Watching revenue decline alone. Seeing cracking sites update and still continuing. Deciding alone whether to continue, raise prices, pivot, or stop.

AI can help you brainstorm.

But you still carry the final responsibility.

So if you also want to build a small product with AI, I am not discouraging you.

I actually suggest you try.

But keep the target small.

Do not start with “I want to build a platform.” Build a small tool first. Find 10 real users first. See whether anyone wants to use it. Then see whether anyone wants to pay. Then see whether you can accept feedback, complaints, refunds, piracy, maintenance, and all the follow-up costs.

If you can accept these, then slowly scale up.

That is more reliable than reading endless stories about getting rich through AI coding.

The real opportunity is often not who gets AI to write the first version fastest.

It is who can survive after the first version.

Keep fixing. Keep listening to angry users. Keep iterating. Keep protecting revenue. Keep grinding with platform rules. Keep judging, amid small revenue and fragmented trouble, whether the product is still worth doing.

That does not sound exciting.

But that is what real indie development looks like.

My biggest takeaway from these two cases is:

In the past, technical people had no products because they could not build them.

Now AI helps you build them, and you discover that the truly hard part starts after launch.

Code is only the ticket.

Users, platforms, revenue, rules, piracy, and support are the road after entry.

AI can help you build the product.

But nobody will answer user calls for you, and nobody will watch cracking sites for you.

I am Lao Hua. Follow me to understand more about AI, tools, and information gaps.