A competitor teardown is a structured look at someone else’s product so you can finish your job better. It is not a shopping list of screens to duplicate. At Croncode we will run a teardown as questions. We will not take a Figma file that traces another app as a deliverable. Refusals: what we will not build. Naming: how we name apps.

A teardown should name the job a competitor fails and the question you will ask testers. Copying their chrome, copy, or motion is not research. It is a clone brief we will refuse.

What should you write down in the first hour?

1. The job they claim on the store. ASO honesty: positioning.
2. The job a tired user can actually finish.
3. Where they lie: paywall, empty, permission. Paywalls, empty states, push.
4. One question you will test on your own object, not their layout.

Our jobs are not templates to clone: YourStyle, Numira, Spylie, Luviport. Catalog: what Croncode builds.

When does a teardown become a legal and ethical problem?

This is not legal advice. Counsel handles marks and unfair competition. We handle whether we will draw it. Security and assets: security questions.

How should a studio workshop use the notes?

Ten slides maximum. Each slide is a failed job, not a screenshot collage. Then write your empty state and your first job. Design QA will test your screens, not theirs: design QA. Sprint demo shows your binary: sprint demo. Feature creep loves “they have this tab”: feature creep.

People: Goktug Unver, Yusufhan Sokur, Ozgur Ismet Ozkan. Shipping: how we ship.

What about AI products and teardowns?

Do not copy a vendor chat as your app. Scope a fail-safe on your object: fail-safe AI. Do not copy a creepy personalization pattern you “admire”: creep line. Infrastructure argument: AI as infrastructure.

What mistakes waste the research week?

• A 40-app spreadsheet with no question: you are collecting icons.
• English-only teardowns for a Turkish market: onboarding.
• Using reviews of others as your only spec: still talk to your users. Reviews.
• Skipping your own empty state because theirs looked full: they may have fake data.

Quote the job, not the clone: what to send. Choose a studio: choose an iOS studio. Hire: hire. Custom: custom software. Contact: contact. Journal: /en/journel/. Home: /en/.

How do we keep client work from becoming a clone factory?

Separate backlogs. Shared standards. Dual track: products and client software. Handover of a repo that already copied someone is a debt item: handover. Thin MVPs that only exist as “like X”: too thin. Trust UI should still be yours: trust onboarding.

If the site teardowns a competitor, do not paste their hero. When a site is enough. Founders sometimes bring a folder of screen recordings and call it a spec. We will watch one job path with them, write the failed step, and close the folder. The rest is noise. Your object is the spec.

When the teardown is done, delete the screenshot folder from the shared drive if you do not need it for counsel. Keeping a clone kit around makes the next intern think it is the spec. The written questions should survive. The traced pixels should not. The not-now list should get the features you almost copied.

Frequently asked questions

Can I take screenshots for an internal deck?

For internal critique, usually yes if you do not publish them as your UI. Do not ship their art.

Is “inspired by” a safe word?

Not if the pixels match. Write the job you will finish instead.

Should I teardown Croncode apps?

You can use them as job examples. Do not copy the chrome and call it a brief. Store links live on each product page.

Do you teardown as a paid workshop?

We can. The output is questions and a not-now list, not a traced file.

What if the client insists on a clone?

We decline. See the founder refusal list linked above.