How to do this fairly.
Rebuilding someone’s product in public is a compliment — it says the thing is worth the effort of reimagining. It only stays a compliment if the people who built it are treated as participants rather than targets. These rules are how we keep it that way, and they are the reason a company can join in rather than call a lawyer.
The short version
- Build it yourself, with AI. Recreate designs; never copy logos or assets.
- Synthetic data only, and never touch a company’s real systems.
- Every build is labelled an unofficial concept, every time.
- If a build names a company, we tell them and they get a published reply.
- Takedown on request, within two working days, without argument.
What you must do
- 1
Build it yourself
Your own work, made for this. Don't pass off someone else's build as yours, and don't submit a company's own code back to them. Your AI assistant can capture the screens and write it up, but it only ever prepares a draft: you look at every screenshot and publish it, under your name, every time.
Why: Obvious, but it is the foundation everything else rests on. And a development app is full of real things — your email, a colleague's name, a key on a settings screen — so a person sees each screen before the world does.
- 2
Recreate, never copy assets
No logos, icons, illustrations, sounds, fonts or artwork belonging to the company. Build your own or use generic equivalents — even if an AI tool produced a near-identical copy for you.
Why: A user interface's ideas are not protected, but its assets are. This is the single most likely way an otherwise fair build becomes copyright infringement, and AI makes it easy to do accidentally.
- 3
Synthetic data only
Made-up accounts, made-up numbers. Never a real customer, never a real balance, never your own live account.
Why: Protects real people, and keeps a demo from touching anything a regulator would care about.
- 4
Don't touch their systems
No calling their API, no reverse-engineering their app to find private endpoints, no scraping. Build from what is publicly visible.
Why: Their developer terms usually prohibit competing clients, and probing a bank's endpoints can cross from a terms breach into computer-misuse law.
- 5
Label it unofficial, every time
Every build page says it is an unofficial concept, not affiliated with or endorsed by anyone. Don't use a lookalike name, and never publish it to an app store.
Why: Trademark trouble comes from confusion about origin or endorsement. Naming the app you rebuilt is fine; implying they made it or approved it is not.
- 6
Make a proposal, not a verdict
"Here is what mine does" — not "their app is insecure" or "they are wasting money". Show your work and let people draw conclusions.
Why: Opinion and verifiable fact are safe. An unproven claim about a company's security or spending is an assertion you would have to defend.
- 7
Punch up, not down
Aim at organisations large enough to answer with a comms team and a legal department. Not two-person startups, not individuals.
Why: A large company being nudged is a fair fight. A stranger aiming this at a tiny team is harassment, whatever the intent.
- 8
One build per company, no dogpiling
Don't post repeatedly at the same company, and don't organise several people to hit one target at once.
Why: Volume turns a point into a pile-on. The format only works while it stays a conversation.
What we promise a company
The single version of these commitments. Nothing elsewhere on the site restates them, so there is nothing to drift out of step.
We tell the company — at the first build
Not when the challenge is posted. There is no point warning anyone that something is coming if nothing ever arrives. The date we contacted them is shown on the page.
They always get the right to reply
Their answer is published in full at the top of the page, above the builds, attributed and unedited — as content rather than a comment buried underneath. No account is needed: the email contains a link that goes straight to a text box. A bank's CTO once replied with an entire article; that is the model.
Declining is a recorded answer, and silence is not held against anyone
A company can say on the record that it would rather not comment, and the page says exactly that. If they say nothing at all, the page states that they were told, that they have not replied, and that this is entirely their right — with no day counter and no implication that silence means anything.
We never publish findings about their systems
Builders rebuild from the outside. Nobody probes anyone's infrastructure, and we do not run security assessments against a company's live services.
Takedown on request, no argument
A company can ask us to remove any build concerning them. We aim to respond within two working days and we do not require a reason. Every build and every challenge carries a report link that needs no account, so this does not depend on finding the right email address.
Internal rounds stay internal
If we run a private build-off inside a company, nothing from it is published without written approval.
Banks, health and anything regulated
Extra care in regulated sectors. A build must never imply it can move real money, hold real deposits, give financial or medical advice, or handle real patient data. Financial services sit inside a regulatory perimeter, and an app that merely looks like it does banking can attract attention as a demo.
If you are rebuilding something in one of these areas, say plainly in your Build Breakdown what is faked. That honesty is the point of the format, and here it is also what keeps it safe.
If you are a company and you want something removed
Email us and it comes down. No reason required, no argument. We aim to reply within two working days. If you would rather reply than remove, we will publish your response in full alongside the build.
support@bineric.comThese rules describe how we run Vibe Off. They are not legal advice, and they do not replace your own judgement or your own counsel — a build is your responsibility, not ours. If something here is unclear, ask before you post.