building in publicindie appsvibe codingAI app buildersiOSTestFlightstartup strategy

Building in Public When AI Can Clone Your App in Two Prompts

Muhammad Tayyab

October 8, 2026·16 min read

Two hands holding two smartphones showing identical screen content side by side — photo by Amanz via Unsplash

An unreleased iOS app got rebuilt from a demo video in 1.5 prompts, and indie devs started saying building in public is over. Here's what a clone can copy, what it can't, and what to share now.

On October 5, 2026, iOS developer Hewad Mubariz posted a demo video of his "dream football app": YOLO26 for ball detection, automatic tracking, Core ML on iOS, plus juggling counters and shot analysis that were still in progress. It was a typical build-in-public post. It did very well, too: as of October 8 it had more than 2,700 likes, about 190,000 views, and 200+ replies, including people asking for TestFlight access.

A day later, Vibecode co-founder and CEO Ansh Nanda quoted it with: "This UI is fantastic. Couldn't wait for it to be released so I made it myself. 1.5 prompts on @vibecodeapp." That post got roughly 300,000 views. A few hours later he did the same thing to another indie app's UI, in "1 prompt".

By October 7, a good part of indie-dev X was posting some version of "DON'T BUILD IN PUBLIC."

I don't think that's the right conclusion, but the worry behind it is real. This post covers what actually happened, which parts of an app a prompt can clone from a video and which it can't, and a practical way to decide what to share and what to keep to yourself in 2026.

Not legal advice. This is a developer's reading of public posts, Apple's published guidelines, and U.S. Copyright Office guidance as of October 8, 2026. If someone is selling a copy of your product, talk to a lawyer in your jurisdiction.

What actually happened (short timeline)

All times UTC, from the original posts on X.

Oct 5, 16:28 UTC — Hewad Mubariz: Posts a work-in-progress demo of an iOS football app, naming the stack (YOLO26, Core ML)
Oct 6, 22:08 UTC — Ansh Nanda (Vibecode CEO): "Couldn't wait for it to be released so I made it myself. 1.5 prompts on @vibecodeapp"
Oct 7, 03:37 UTC — Ansh Nanda: Rebuilds the UI of Hieu Dinh's app Steps "in 1 prompt": "Can you tell which one is original and which one is vibe coded?"
Oct 7, 07:24 UTC — Adrià Martinez: "DON'T BUILD IN PUBLIC". About 77,000 views and 700+ likes.
Oct 7, 10:28 UTC — Hewad Mubariz: "I honestly regretted posting that video and mentioning the entire tech stack."
Oct 7, 15:28 UTC — Ansh Nanda: Follow-up: "Building a good product still matters… If you go deeper into a problem than anyone else. You can still win."

Two details are easy to miss. First, Hewad's app hadn't been released yet. The clone copied a demo video, not a product anyone could download. Second, Ansh later said the clone was "for myself... Not to publish". Critics like Brandon Sladek replied that the demos still promoted Vibecode and encouraged others to copy apps. Both points hold up. Nobody shipped a competing app here. What people were reacting to was how little effort a convincing copy took.

(Some recaps going around described the cloned app as a smart-glasses detector. The original post is a football-tracking app.)

The two camps

"Go stealth." Ian Nuttall: "PSA: don't build in public. Code is a commodity so build your good ideas in stealth." Kamal Kumar, an App Store Awards finalist, put it this way: "Build in public used to feel like sharing progress. Increasingly, it feels like handing over a blueprint." Indie maker Elitza Vasileva wrote that she's become "so much more cautious because of copycats."

"Keep shipping in the open." Marc Köhlbrugge: copycats "always will be one step behind. It's not like you're sitting still, not iterating after your v1… Relatively, not much has changed. You need to continue to keep momentum, keep shipping, gather feedback, iterate on that, build a network of peers who got your back." Designer Dima Groshev added: "copying a product once and building it over time are two very different things." Alex West took a different view: "'building in public' is for the brave again."

The most useful line came from the person who got cloned. In a reply, Hewad said he had "gained some followers and learned a bit about what to share and when." That's the right lesson. The problem wasn't sharing in general. It was sharing particular things before he had any way to capture the attention they brought in.

What a prompt can clone from a video, and what it can't

AI app builders now produce real native code. Vibecode, for example, generates native Swift/SwiftUI, React Native/Expo, or web apps from natural language and lets you export the source. So assume that anything visible in a screen recording can be copied in an afternoon. What a video doesn't show is where your edge actually comes from.

Screens, layout, motion, color — copyable from a demo video? Yes, in minutes. That's what the 1.5-prompt clone copied.
Feature list and named tech stack — copyable from a demo video? Yes, it's a free spec. Naming "YOLO26 + Core ML" told everyone how to start.
Model quality, training data, tuning — copyable from a demo video? No. Hewad said he used "my own data" plus "some sources from internet". You can't prompt your way to that.
Edge cases and real-device performance — copyable from a demo video? No. Lighting, camera angles, older phones, offline use. The things that only show up when real users test it.
Polish over time — copyable from a demo video? Barely. Hieu Dinh called the copy of his app "the sloppiest clone of my app ever", and Ansh agreed it was "definitely not as good as yours"
Audience, testers, email list — copyable from a demo video? No. The people asking Hewad for TestFlight wanted his app.
Distribution channels that work — copyable from a demo video? Only if you publish them. Many founders give this away in "how I got my first 1,000 users" threads.
Brand and trust — copyable from a demo video? No. Dima's analogy: plenty of restaurants serve food, but only a few have lines out the door.

The pattern is simple. What's visible is cheap to copy. What's built up over time isn't. UI is visible. Data, feedback loops, distribution, and reputation are built up over time.

The share / hold-back playbook

Here's how I'd sort it for a pre-launch or early indie app in 2026.

Share freely

The problem and who it's for. "I'm building a juggling counter for kids' football training" brings in the right people. An idea alone was never much of a moat.
Polished screens once you have a way to capture interest (more on that below). Screens are your best marketing asset, so don't hide them. Just don't post them before you can collect anything from the attention.
Lessons, failures, and decisions. "Why I dropped feature X after tester feedback" builds trust, and a copycat can't use it.
Outcome metrics (users, retention trends, revenue milestones) if you're comfortable sharing them. They help you look credible and don't tell anyone how to copy you.

Share with care

Short demo videos of the core interaction. Post them, but pair every one with a TestFlight link, a waitlist, or a pre-order page.
General tech choices ("on-device ML," "SwiftUI") are fine. A step-by-step recipe is different.
Roadmap themes, without exact feature specs or release dates.

Hold back (at least until launch)

The exact stack and pipeline: model names, training approach, prompt chains, the third-party APIs that make the hard part work. This is what Hewad said he regretted.
Your proprietary data sources and how you label or clean data.
The distribution channel that's currently working. Once you write the "this subreddit / this creator / this ASO keyword drove most of my signups" thread, that channel starts filling up with competitors.
Pricing experiments still in progress. Share them after you've decided.
Unreleased features that make up your actual differentiator. Show them to testers, not the timeline.

Capture the attention before you post

Hewad's post had the reach most indie devs hope for, and the replies included people asking "TestFlight?" and "is it out, do you need testing?" His answers were "TestFlight is coming" and "probably next week." That's the gap to close. Before a big demo post, have something ready to collect the attention:

A TestFlight public link. Apple lets you invite up to 10,000 external testers, and public links can screen by device type and OS version. The first build needs TestFlight App Review approval, so submit a few days before you post.
A pre-order page if you're close to done. Brand-new apps can set a release day 2 to 180 days after the pre-order is published, and pre-orders show up in App Store search. It also puts a limited version of your product page live early.
A one-field waitlist on your own domain, so you keep the list no matter what happens to your account on any platform.
A pinned post or bio link that points to one of the three above.

A clone can copy your screens. It can't copy a list of people who asked for your app by name.

Why execution still wins

AI makes v1 nearly free. It doesn't make v1.1 through v40 free, and that's where products actually win.

Copying once isn't the same as maintaining. Every week you ship fixes driven by tester feedback, a one-off clone falls further behind. Even Ansh's own follow-up came down to this: "You can put in more effort. And then no one can clone you in one prompt."
Go deeper than a prompt can. On-device ML tuned on your own data, smart handling of bad lighting, accessibility, and offline behavior are where a "1.5 prompt" clone stops.
Distribution compounds. As builder Mahdi Farra put it: "the real moat is and always will be distribution and marketing." An audience is something you earn, and it can't be copied. Even Tobi, angry about the clones, noted that building in public "gave people with no marketing budget a chance to get their first users."
Community is a feedback engine. Testers who feel some ownership report bugs, suggest features, and tell their friends. A clone starts with none of that.

If anything, the clone story makes a case for building in public better: show the outcomes, collect the audience, and stay vague about the recipe.

If someone does clone you

Know what protects you and what doesn't before you get upset in public.

Apple's rules are on your side for apps published on the App Store. Guideline 4.1 (Copycats) says: "Don't simply copy the latest popular app on the App Store, or make some minor changes to another app's name or UI and pass it off as your own." Guideline 4.1(c) bars using another developer's icon, brand, or product name without approval. Guideline 4.3 also targets apps that are "indistinguishable from what's already widely available."
There's a formal channel. If a published app infringes your IP, Apple's App Store Content Dispute form exists for that. Apple says it will generally contact the other developer and ask the two of you to resolve it directly.
Ideas and layouts are weakly protected. The U.S. Copyright Office's Circular 33 excludes "any idea, procedure, process, system, method of operation, concept" from copyright, and says that as a general rule the general "format" or "layout" of a page isn't copyrightable. Your original artwork, copy, and code are a different story. "They made it look similar" is usually a much weaker claim than you'd expect.
Private clones aren't something you can act on. A demo someone built for themselves and never published doesn't land in any App Store process. Your response is to ship.

Practical move: keep a dated record of your originals (designs, commits, public posts). If a copy ever does reach a store, you'll have the timeline ready.

A 7-day build-in-public reset

Write one sentence about the problem you solve and who it's for. That's your shareable "idea."
List your real moats: data, model tuning, edge cases, audience, distribution channel. Mark which ones you've already posted publicly.
Set up a capture point: TestFlight public link, pre-order page, or a waitlist on your own domain.
Before the next demo post, delete stack and pipeline specifics from the caption. Keep the screens, the outcome, and the link.
Move build details into a tester-only channel (TestFlight notes, a private Discord, an email list).
Post one "lesson learned" thread this week instead of a "how it's built" thread.
Archive dated originals of your designs and posts.
Ship something to testers. A visible update cadence is the best signal to the people following you, and to anyone thinking about cloning you.

Soft close

Building in public isn't over. What's over is the version where you post your full recipe before you have a single tester. Screens are cheap now. Your audience, your data, and how fast you iterate are still yours, and how you share should protect them.

If you're getting ready for a launch and want a second pair of eyes on what to show, what to keep private, and how to set up TestFlight or pre-orders to capture the attention, say hello via /#contact.

About the author

Muhammad Tayyab is a full-stack and mobile developer based in Lahore. He builds DripScore, an AI outfit rating app live on the App Store, under dawnapps.co. Find him on GitHub, LinkedIn, and X, or say hello at /#contact.

Sources

Back to all posts

Thanks for reading 🙏