Questions people ask before they trust a platform like this

These are the questions that actually decide it — the ones a security review asks, and the ones you ask yourself before typing fifteen years of method into somebody else’s box. Each is answered straight below, including the ones where the honest answer is a limit. A hedged answer on this page would be worth nothing.

Who owns the code if an AI builds it?

You do. Not a licence to use it — ownership of the output, written into the Terms §11. The same document says your content stays yours and that we do not train models on it (§10). Every product built here is a real git repository, a commit per build step, and it exports into your own GitHub or GitLab account whenever you ask (§12.1). The code was already yours; export only changes where it lives.

Your own developer can work in it. She pushes to the repository she already uses; one action syncs that push, re-verifies the whole product and puts the update in front of the publication gate. Commits she makes are detected and adopted, not overwritten. It runs inwards too: arrive with a half-finished repository and it is cloned, adopted as a product, and carried on from there.

If I leave, do I take my product with me?

Yes, and test that early rather than when you are angry. Export pushes the product’s current code into a repository under your own account (Terms §12.1). One limit in the same breath: what lands there is a fresh single-commit history. The build history does not travel — our internal build log stays with us as the operational record we build, verify and serve previews from. What leaves is the source, and the source was already yours.

A full-tree secret scan runs before every push and refuses the push when it finds likely credentials — a safeguard operated on a best-effort basis, not a warranty that every secret is caught (Terms §12.4). And the rest of the honest answer: what you take is source. Hosting and the database it runs against are things you would stand up somewhere else. We would rather tell you that now than let you find it out on the way out.

Do you train models on my work?

No. Terms §10: you own your content, and we do not train models on it. That covers the conversation in which you describe the product, what is built from it, and the files you bring with you. The brand identity created for a product is output, and §11 says you own the output. These are published, versioned clauses you can read before you sign up, not an assurance given on a call.

Could you build a competing product out of my idea?

To have something built here you have to describe how you actually work, so the answer needs to be a clause rather than a reassurance. Terms §10.1: we will not use what you describe to build a product that competes with yours. Read §11.5 in the same sitting, because it is what §10.1 does not do — your idea is not made exclusive, and someone who independently describes something similar may get something similar.

Your customers are covered separately. If you bring clients here, we will not market to them and we will not approach them with an offer that goes around you (Terms §10.2). That is a term of the ordinary agreement, not a partner tier you have to qualify for. Ask any agency or builder to put either of those in writing before you describe your idea to them.

What happens to my product if RunMyB disappears?

We will not answer a survival question with a growth number. RunMyB, Inc. is a Delaware corporation in closed beta, and no company at this stage can honestly promise you a decade. What we can do is make sure your product does not live only here. The code exports to a repository under your own account whenever you ask, on infrastructure we do not touch.

The instrument is the answer, because instruments survive a company and optimism does not. What we do not have is written down further down this page.

What if I do not like what it builds?

You find out privately, before anyone else does. You are not asked for a spec: you describe the job in plain language and the build starts from that. What comes back runs on a private preview only you and the people you share a link with can reach. You drive it, say what is wrong, and it is changed in place and re-verified. Accepting a build and publishing it are two separate acts, and both are yours.

Who is answerable when the software gets something wrong?

Split the question in two, because the two halves have different owners. Whether the software works is ours to check: every build must serve, load and run without crashing; a build that stores data must prove the data survives a write, a restart and a read-back; a build with end-user accounts must clear an authentication floor before you ever see it. Whether it is right for your business is yours to judge. A floor cannot know your domain.

That is exactly why the judgement happens before anything is published, on a preview only you can reach. Downstream it stays yours in the same way: you own the output (Terms §11), and the judgement about whether it is right for your business stays where it belongs, with you.

Who reviews what gets published?

You first, then us. Publishing a product, changing it or taking it down is always your explicit decision — nothing goes public because a build finished, and nothing is served to the world on a schedule you did not set. Before a product is served publicly we review it as well. A platform that hosts strangers’ software and reviews none of it is a platform with a problem. The rules that review applies are published in full and in force.

Do I need to know anything technical?

No, and there is no document to write first. You describe what the product should do in plain language, in conversation. You never configure a server, because you never get one: each product runs in its own sandboxed runtime with its own isolated database, provisioned and run by the platform. What is asked of you is judgement, not syntax — you decide what gets built, you drive the preview, and you approve what ships.

Can another business on this platform read my data?

Isolation here is a proof rather than a promise. Every hosted product gets its own isolated database and its own sandboxed runtime — not a shared table with a customer column in it. A cross-tenant read returns not-found rather than a permission error, so nothing is confirmed by the shape of a refusal. An internal proof module runs against all of it, and it has already found and closed real authorisation bypasses. That is the argument: we go looking, and we say what we found.

One thing is true by design, and we would rather print it here than have you discover it: the platform’s own admin overview reads across tenants, because somebody has to be able to see that the platform itself is healthy. Admin authority is listed rather than ambient — the allowed-principal list fails closed, and every admin route is guard-first, checked by a sweep generated from the router’s own table rather than a list somebody forgets to update.

Inside my own product, can one customer see another customer’s data?

Applications built here with end-user accounts get real authentication — email and password, passkeys, time-based two-factor codes, account-linking safety — generated as part of the build rather than bolted on afterwards. Every such build must clear an authentication floor, and one of its items is cross-user isolation. A build that cannot demonstrate the floor does not pass.

When an apparent cross-account leak was reported in a build here, we investigated it and refuted it: both records belonged to the same account. The real defect was that the application never showed which user was signed in, which is a different and more ordinary failure. Generated applications with accounts now have to show who is signed in. That is what looking properly gets you — the true answer, and a fix to the thing that was actually wrong.

Can the assistant do something in my business without asking me?

One act executes outward, and it is chokepointed. The assistant reads across a connected mailbox, calendar, notes, boards, git repository and the web. The only outbound act it can execute is sending an email, and only after a draft you actually see and a confirmation pinned to the exact text you approved, through a single firewalled chokepoint. Writes into your notes, boards and calendar are denied deliberately.

That denial is a prompt-injection control rather than a missing feature. An agent that reads text strangers can put in front of it should not also hold the pen on your workspace: the moment it does, a shared document or an inbound email becomes a way to steer it, and the loss is yours, not ours. Ask any vendor promising full write access what stops a web page from steering it. The answer tells you what you need to know.

If someone asks me to delete their data, can I prove it is gone?

A delete button that reports success over data it never reached is worse than no delete button, so ours does not do that. When you erase a product, the platform tells you what it actually reached. A hosted database that survives the erasure is never silently counted as deleted: it becomes a recorded obligation naming the exact resource, and discharging it stamps proof — the hosting provider’s own response showing the project is gone, and a record of which hand verified it. (both the recorded obligation and the credentialed path that discharges it are live today: the discharge runs inside the platform’s own network, asks the provider to delete the resource, re-reads the provider to confirm it is gone, and records that answer — it is deliberately a person’s act, not a background job)

The defect behind the old behaviour is worth naming, because it is the shape of the thing you are trying to avoid: erasure used to resolve which datastore to drop from the surrounding environment rather than from the product’s own binding, so a hosted product’s erasure could report success while the real database survived. That is fixed at the root. Nothing unreached is counted as deleted.

What do you not have?

We hold no third-party security audit. SOC 2 and ISO 27001 both require an external auditor, we do not have one, and we would rather say that in the same sentence than let an architecture description imply it. There is no published uptime or support commitment. There is no published price. RunMyB is in closed beta, access is by invitation, and there is no public self-service sign-up.

We would rather tell you this here than in a footnote after you sign up.

Where can I read the actual clauses?

The clauses cited above are in the Terms of Service & Acceptable Use, published in full, in force and versioned, alongside the Privacy Policy and the content-safety rules. What the platform builds and how a product gets made is on the home page. How access works, and what we send you if you are invited, is on the access page. If your question is not answered here, ask it: hello@runmyb.com.