Reverse engineering and cloning is recreating an existing product from the outside. The input is screenshots of someone else's interface, a recording of it in use, the markup of a live site or the requests an application sends, and the brief is some version of "make one like this". Models are good at it, which is exactly the difficulty.
It is in the taxonomy because people do it, and a map that left it out would be incomplete. This section does not recommend it as a way to ship, and there is deliberately no course on it. Both decisions are explained below. Nothing on this page is legal advice.
What it is for
People reach for it for three different reasons, and only some of them hold up.
- Shipping a lookalike of somebody else's product. This is what the category usually means, and what this page argues against.
- Studying how a product achieves an effect: a transition, a layout, an onboarding flow. Studying other people's interfaces is how interface design has always been learned.
- Rebuilding a product you own whose code is lost, unmaintainable or locked inside a platform you are leaving. The product is yours, so the premise is too.
The second is real work as long as it ends in understanding rather than in a copy. The third is better described as maintenance.
Who it suits
As a way of studying, designers and developers learning interface patterns, provided the study stays study. As a way of rebuilding your own product, teams replacing a system they own, and that work is covered under AI code review, refactoring and maintenance. As a way of shipping someone else's product, nobody this section would advise.
How to tell this is your category
- Your input is a product you did not build: its screens, its recordings, its markup or its traffic.
- The brief names the product rather than the problem: "like this one", "the same as that".
- Success means looking or behaving like the original.
- If the input is a design made for you, that is design to code. If it is a sketch or a screenshot of your own idea, that is screenshot to app. If the product is yours and you are replacing it, that is maintenance.
What it costs you later
- Legal exposure you cannot size in advance. Copying a product from its screens risks copyright and trade dress claims, and if you hold an account with the product, its terms of service may say something about what you can do with it. Where the line falls depends on the product, the jurisdiction and exactly what was copied, which is a question for a lawyer, not for this page. One general point is safe to make. The World Trade Organization's agreement on intellectual property says copyright protection extends to expressions, not to ideas, procedures or methods of operation, and requires computer programs to be protected as literary works. A model asked to recreate a product from its screens works from everything on them, the wording, the illustrations and the distinctive look included, not only from the idea.
- A premise that belongs to someone else. A clone starts behind the original and stays there. Their roadmap becomes yours, every change they ship is one you follow, and the reason a customer should choose the copy has to come from somewhere other than the product.
- Decisions without their reasons. You can copy what a product does, but not why it does it. The constraints behind a design, the edge cases it handles, the states you never saw on screen and the failures it was built around are invisible from outside, so the model fills them in plausibly. You end up with a product built on decisions nobody made, and no specification to explain it. Vibe coding builds fast, but can you explain it later? is about where that leads.
- Their mistakes too. Copying behaviour copies all of it: the bugs, the accessibility failures, the confusing flow the original team is already trying to fix. Nothing in a screenshot says which parts were deliberate.
- Work you cannot show. A product whose premise is copying is hard to put in a portfolio or hand to a client, because the first question anyone asks is whose idea it was.
Why there is no course
The working session that produced this taxonomy suggested teaching cloning with the legal and ethical boundaries covered. That does not fix it. The premise of such a course is recreating other people's products, and a lesson on boundaries does not change the premise. It stays off the course list for three reasons.
- The exposure. It invites copyright and trade dress problems that an independent author has no appetite for, and that every learner who followed the course would inherit.
- The audience. A course on cloning attracts the buyers most likely to skip the boundaries lesson, and their work would carry the course's credential.
- The credential. The courses this section leads to are built around a credential whose whole value is that it does not overclaim. That cannot be attached to work whose premise is copying.
The legitimate half of the skill is taught elsewhere, without the premise. Understanding an unfamiliar system from the outside in is the core of maintaining a codebase you inherited. Turning a design into a working interface is design to code. If what draws you here is a product you admire, study it, describe the pattern in your own words, and build from the description rather than the screenshot, with your own wording, your own illustrations and states designed for your own users. Learn from interfaces. Do not ship someone else's.