Terms of Service & Acceptable Use

Version 10.3 · effective 2026-10-28 · in force

These Terms of Service & Acceptable Use (the "Terms") are the agreement between you and RunMyB, Inc. governing your use of the RunMyB platform. By creating an account, accepting these Terms in the console, or using the platform, you agree to them. The following documents are incorporated into these Terms by reference and are available in the platform's legal documents section: the "Privacy Policy", the "Data Processing Addendum", the "Platform Rules — Content-Safety Taxonomy", the "Refunds, Cancellation & Complaints" policy, the "Notice-and-Action & Contact Points (DSA)" policy, the "Copyright / DMCA Policy", and the "Cookie & Tracker Notice".

1. Who you are contracting with

The RunMyB platform is operated by RunMyB, Inc., a Delaware corporation ("RunMyB", "we", "us"). RunMyB, Inc. is the contracting party under these Terms and, for the platform's own account, billing, and ledger data, the data controller (see the Privacy Policy).

We may assign these Terms, in whole or in part, in connection with a merger, acquisition, corporate reorganisation, or transfer of all or substantially all of the business or assets to which they relate; the successor assumes our rights and obligations, and a change of contracting party will be notified to you. You may not assign or transfer your rights or obligations under these Terms without our prior written consent.

2. Definitions

• Account (or tenant) — the workspace opened for a customer on the platform; the account holder is the customer and the single contracting party under these Terms.
• Administrator and member — the two membership roles within an account (Section 9).
• Venture — a project workspace within an account, in which assistants and people work toward a business or product.
• Product — an application or other work product built or operated through the platform within a venture.
• Credits — the prepaid units in which paid platform usage is denominated (Section 14).
• Your Content — everything you (or your members) submit to or create through the platform: descriptions, instructions, conversations, files and attachments, imported code and data, ventures, products, and the output attributed to you under Section 11.
• The service (or the platform) — the RunMyB console, assistants, build and verification machinery, storage, and the related surfaces we operate.

3. Eligibility

You must be at least 18 years old (or the age of majority in your jurisdiction, if higher) to use the platform. If you accept these Terms on behalf of a company or another legal entity, you represent that you have the authority to bind that entity, and "you" then means the entity. The platform is not directed at children and may not be used by them.

4. Your account and its security

You agree to provide accurate account information and to keep it current. Each identity on the platform is personal: it belongs to one person and may not be shared. You are responsible for safeguarding the credentials used to access your account and for the activity that occurs under it. If you become aware of unauthorised access to or use of your account, notify us promptly at hello@runmyb.com; after notice we will take reasonable steps to secure the account, and our liability remains as stated in Section 19.

E-mail about your account. While your account exists, the platform e-mails its administrators, each at the address they sign in with, notices about the account and the service: when a card in the console waits for their decision, when one of the account's products is published, its go-live request is declined, its own messages to its users are switched off, its background jobs are paused by RunMyB, a file it stores is withheld because the platform's scan found malicious software in it, files it stores cannot be scanned, or someone writes to it through its contact form or by e-mail to its own address (Section 15), when one of its runs finishes, fails or is stopped at a limit, when the account's credits run low or run out and when it nears or reaches its daily credit limit, and RunMyB's notices about the service itself, such as a change of the sub-processors listed in the "Data Processing Addendum". Each administrator can choose, in the console under Account → Notifications, whether the notices about the account reach them at once, in a daily summary or not at all, for all of them together or for each kind; until they choose, the notice that a run finished comes in the daily summary and the others come at once. The notice that someone wrote to a product that only one member of the account can see in the console goes to that member alone, whether or not they are an administrator, and they can choose for it in the same way. The platform also sends the invitations and the notices about data requests and the account's deletion that the platform's published email page describes. A notice about the account is a copy of what the console already shows, where anything it concerns is decided, except a notice about the files one of the account's products stores, which itself carries what it reports (Section 15, item 8); nothing in the service waits for a notice to be delivered, and one that cannot be delivered changes nothing. These messages are part of the service, not marketing, and come with the account for as long as it exists: RunMyB's notices about the service itself, the notice that a file one of the account's products stores was withheld, the invitations and the notices about data requests and the account's deletion have no such setting while it does, and closing the account (Section 21) ends all of these messages, the last being the notice that its deletion is complete.

5. The service; early access

RunMyB lets you describe software and have AI assistants build and verify it, and — where the platform offers hosting for your product — run it. You are responsible for what you build, for the lawfulness of your apps and their content, and for any classification or compliance obligations (including under the EU AI Act) that attach to what you create.

Early access. The platform is under active development. Features may change, be added, or be withdrawn; interfaces, limits, and behaviours evolve. We do not promise uninterrupted or error-free availability, we offer no service-level agreement and no uptime warranty, and maintenance may interrupt the service. Anything labelled beta, preview, or experimental is provided for evaluation and may be modified or discontinued at any time. Keep your own copies of anything you cannot afford to lose; export paths (including the git export in Section 12) exist for that purpose. Nothing in this section limits the non-waivable rights consumers have under applicable law (Section 23).

6. Acceptable Use Policy (AUP)

You may not use RunMyB to build, host, or operate anything that:

• is illegal, infringing, or facilitates illegality;
• targets, harasses, exploits, or endangers minors, or produces CSAM;
• deploys malware, phishing, spam, or credential-harvesting;
• infringes intellectual property or misappropriates trade secrets;
• attacks, overloads, or attempts to circumvent the platform's controls, quotas, or isolation;
• violates the privacy of, or unlawfully processes the personal data of, third parties;
• generates disallowed content of the categories the platform rules enumerate.

Platform rules taxonomy. A detailed, categorised list of prohibited and restricted content and conduct is maintained as the "Platform Rules — Content-Safety Taxonomy", which is the operative catalog for this AUP.

7. Enforcement

Violations of these Terms or the AUP may be met with graduated actions — a refusal to run, removal or unpublishing of content or an app, suspension of an account, or termination — chosen proportionately to the violation, its severity, and any recurrence. An enforcement action against your product or your account is accompanied by a statement of reasons — for publicly-hosted content, one consistent with DSA Article 17 — and you may appeal the decision. To appeal, send the decision reference (or a description of the decision) and why you disagree to support@runmyb.com or through the contact points described in the "Notice-and-Action & Contact Points (DSA)" policy. An appeal is reviewed afresh by a human — it is never adjudicated by the automated check that produced the original decision — and we aim to respond within 14 days. Nothing here waives our right to act immediately where the law requires it or where there is an imminent risk of serious harm.

8. Content moderation transparency (DSA Article 14)

Where RunMyB hosts third-party apps publicly, it acts as a hosting intermediary. Our moderation policy is stated in plain language: we act on valid notices (see the "Notice-and-Action & Contact Points (DSA)" policy), we may act on our own initiative against AUP violations, we give statements of reasons for restrictions we impose on publicly-hosted content, and we operate a repeat-infringer policy (see the "Copyright / DMCA Policy"). Some of our moderation is automated — among it the scan of the files your app keeps for malicious software (Section 15, item 8) and the checks of the photos you add to it (Section 10.5) — and the "Platform Rules — Content-Safety Taxonomy" describes the tools that enforce it, the Privacy Policy's Section 9 the platform's other automated checks, each with where a person at RunMyB reviews what it decides.

9. Teams

9.1 Members act under the customer's account

An account may be used by more than one person. The account holder — the customer — remains the single contracting party under these Terms. People the customer admits to its account (members, typically the customer's employees or contractors) act under the customer's account and on the customer's authority: their platform usage, the work products they create, and the charges their usage incurs are the customer's, and the customer is responsible for its members' compliance with these Terms and the AUP as if the acts were its own.

9.2 Membership is managed by the customer's administrators

Each account has one or more administrators (the first user of an account is its administrator). Administrators manage membership: they invite new members (an invitation is a single-use token addressed to a named e-mail address, valid for the validity period stated in the invitation; on the administrator's instruction the platform itself e-mails the invitee an acceptance link, and the inviting administrator — who is also shown the link — may convey it directly as well), assign each member a role (administrator or member), and may disable a member's access at any time. Invitation acceptance requires proof of possession of the token; nobody becomes a member of an account without an administrator's invitation and the invitee's own acceptance.

The last-administrator guarantee: an account can never be left without an administrator — an attempt to disable or demote the only remaining administrator is refused. Account-level obligations (billing, legal acts, deletion) therefore always have an accountable holder.

9.3 Acceptance is personal

These Terms and the Privacy Policy are accepted per person, not per account. Every member — administrator or not — must accept the then-current required documents before first use, and a material change requires each member's renewed acceptance before that member continues (Section 24). By accepting, a member agrees to these Terms in respect of their own use of the platform; the customer remains the contracting party for the account itself — its billing, its ventures and products, and account-level acts. The customer's acceptance does not substitute for a member's own; a member's acceptance does not bind the customer beyond that member's authorised acts (Section 9.1).

9.4 Administrator-only acts (money and legal)

The following acts are reserved to the customer's administrators; a member-role user's attempt is refused:

• billing and payments — purchasing credits, starting or cancelling a subscription, the billing portal, filing complaints, and access to billing documents;
• legal acts for the account — the withdrawal waiver, tenant-wide data-subject requests (account-wide export), and filing or cancelling account deletion (offboarding);
• credentials and connectors — storing or deleting account credentials (API keys), connector and AI settings, and enabling live (real-money or externally-visible) connector operation;
• admin-class approvals — decisions on money-class gates (spend/budget authority) and on live-enablement gates.

Ordinary venture work — describing, building, evolving, and reviewing apps — is open to every active member. Reading these Terms and accepting the required documents is never gated by role.

9.5 Attribution of member acts

Acts performed under an account are attributed to the person who performed them: approvals and decisions record the deciding member, and messages in shared venture conversations record their author. These attributions are part of the customer's account records (Section 9.6) and of the platform's audit trail.

9.6 Work products and shared records belong to the customer

Everything produced under the customer's account in the course of venture work — apps, documents, artifacts, and the conversation records of shared venture lanes, including each member's authored turns in them — are the customer's records (as between the customer and its members, subject to any arrangement between them, which is not the platform's concern). A member's personal data rights in those records are addressed in the Privacy Policy; a member's own-data export covers the member's personal data and the conversations the member owns, not the customer's shared records.

9.7 Member disable is not account termination

Disabling a member ends that person's access to the account: their sessions stop resolving, their approver authority is deactivated, and they can no longer act under the account. It does not delete the account, its ventures, or the member's past contributions (which remain the customer's records, Section 9.6). Account termination — ending the customer's account itself — is the separate, administrator-only offboarding act, with the grace window stated when the deletion request is filed and the tiered erasure described in the Privacy Policy. A disabled member remains a data subject; the Privacy Policy states what personal data of a departed member is retained, why, and for how long.

10. Your content; the licence you grant us

You own Your Content. These Terms transfer no ownership of it to us.

The operating licence. So that we can lawfully run the service on your behalf, you grant RunMyB a worldwide, non-exclusive, royalty-free licence to host, store, reproduce, transmit, back up, execute, process, display (to you and to those you authorise), and create technical copies and derivatives of Your Content, solely as needed to operate, secure, maintain, and improve the service and to run your app where you ask us to host it. Improving the service does not include training AI models on Your Content: we do not train models on it, and would not without your express opt-in. That is RunMyB's own use. The AI providers behind the platform's roles are named in the Privacy Policy's Section 5.1, which, for a role routed through OpenRouter, states how OpenRouter chooses the provider; RunMyB does not permit any of them to use Your Content to train or improve a model on RunMyB's behalf, as the Data Processing Addendum's Section 7 states. The licence ends, for a given item of Your Content, when you delete it or your account is offboarded, subject to residual copies in backups, to retention the law requires (see the Privacy Policy), and to the operational records the platform retains under Section 12.

10.1 We will not build against you

To have a product built here you must describe how your business actually works — your method, your pricing logic, your process, the judgement that makes your service worth paying for. That description is Your Content, and you own it under this Section. Ownership alone, however, does not answer the question a person is really asking when they hesitate to type it in. This subsection answers it.

The commitment. RunMyB will not use the content you entrust to us — a method, process, ruleset, or business logic you describe to us, and anything else of yours that is not public (Section 10.3) — to develop, commission, or operate a product or service that competes with yours, and will not disclose it to a third party for that purpose. This is a restriction on us. It places no restriction on you.

What you publish is different. The public pages of a product you make public — including a product the platform hosts for you — are open to study like those of any public service: by anyone, and by the platform itself when it studies the field for another customer's plan (Section 10.4). Such a study reads only your product's public pages and other public material about it; it learns the product's features and the patterns of its user experience, and recreates them in the other product's own words, visuals, and brand. What you entrusted to us to build your product is never used for it.

What this commitment cannot say, stated so you are not misled. It does not make your idea exclusive, and it is not a promise of uniqueness. Section 11.5 stands: purely AI-generated output may not be protectable, and the same or similar output may be produced for another customer who independently describes something similar. We commit not to take what you told us and act on it; we cannot commit that nobody else will ever arrive at the same idea on their own. A platform that promises you the second thing is describing something it has no way to enforce.

10.2 Your customer relationships are yours

Where you bring your own clients, members, or buyers to a product built here — including where you introduce them while acting for them as an agency, consultant, or reseller — that relationship is yours, and the following applies in addition to Section 15.

1. We will not market to them. RunMyB will not use the contact details of your end users, or of people you introduce to the platform, to market RunMyB or any other product or service to them. Mail reaching those addresses through the platform is limited to the first-party account and transactional mail described on the platform's published email page and to the messages your app itself has the platform send them (Section 15).
2. We will not solicit them away from you. We will not approach a client you introduce with an offer that bypasses you.
3. What this does not restrict. A person who finds RunMyB independently and approaches us on their own is free to do so, and this subsection does not make you their gatekeeper. It restrains what we do with an introduction you made; it does not restrain them.

10.3 Confidentiality

RunMyB treats your non-public content — your briefs and descriptions, your methods and business logic, your code, and your data — as confidential. We do not disclose it to third parties, with two exceptions only: the sub-processors needed to operate the service (the named list and its safeguards are in the Privacy Policy and the Data Processing Addendum), and disclosure required by law or legal process. This is a restriction on us, it adds nothing to what we may do with Your Content under Section 10, and it survives termination of these Terms for as long as we hold the content (including the operational records retained under Sections 10 and 12).

10.4 Material you point the platform at

You may point the platform at a service, a link, a description, or a file as a reference for your product — for the platform to calibrate its reviews of your product against it, and to study it when it plans your product. For a file you upload, you affirm that you may lawfully use it for that purpose; for a link or a name, you affirm that it points at a publicly offered service, and not at material shared with you in confidence. You take responsibility for choosing it. The platform records your affirmation at the moment you make it (an append-only record keeping the exact wording you saw, together with the link, or a reference to the file, it covers). The reference you name and any file you upload are Your Content under these Terms.

How the platform studies a service. Unless the study is turned off for the venture, before it writes a plan the platform studies the field: the leading public services of your product's type, and any service you name. It studies a service from publicly available material only. It captures up to ten of the service's public pages, with a screenshot of each, and keeps them with your venture; it may also read other public material about the service, such as its help pages, app-store listings, reviews, and articles. In its own automated fetching, the platform honours each site's robots.txt. It learns the features and the patterns of user experience it finds, and recreates them in your product's own words, visuals, and brand; it never copies a studied service's text, images, code, names, or logos into your product. Section 11 applies to the result. The Privacy Policy's Section 2.5 describes the personal data involved.

10.5 Photos you add to your app

You may add your own photos to an app — when you approve its plan, or later on the app's page in the console — for the app to show where they fit. Before your first photo for an app, you confirm on screen that you may use the photos you add to that app, including on its public site, and that everyone who can be recognised in them has agreed to appear in it (for a child, their parent or guardian has agreed). The platform records your confirmation at the moment you give it (an append-only record keeping the exact wording you saw, the app it covers, who confirmed it and when). The photos, and the descriptions you confirm for them, are Your Content under these Terms and your app's content under Section 15, item 1: you answer for them, including for any notice the people they show are owed and for a lawful basis for any special category of personal data a photo reveals, such as someone's health.

The platform uses a photo only once its automated checks have passed it. The file you add is first scanned for malicious software: the platform does not open a file in which the scan finds it, use it in your app or show it to anyone, and keeps it until you remove it or the app is erased. From each other photo, the platform prepares, from the photo's pixels alone, copies in several sizes and web formats, without the original file and without the location, camera or other data embedded in it — technical copies and derivatives under Section 10. An automated check, made by an AI model, then looks at one of those copies for content the Platform Rules prohibit or restrict (Section 6): sexually explicit content, any sexual depiction of a person who may be a minor, and graphic violence. Until a check has passed a photo, your app does not use it and no one outside your account sees it but a person at RunMyB who checks it; some photos go to such a person before anything is decided.

A photo the check finds to show sexually explicit content or graphic violence is held: kept, not deleted, and not used in your app; the console tells you why, that the decision was made automatically, and how to appeal under Section 7. A photo the check finds may sexually depict a minor goes to a person at RunMyB before anything is decided, as do some other photos; the console then says only that a person is checking it. You may remove a photo the automated check held, which deletes it, and erasing the app or your account deletes it too. A photo that is with a person at RunMyB before anything is decided, and a photo RunMyB holds because of a notice it received (Section 8) or as Section 15, item 4 requires, you cannot remove, and while such a photo is in your app neither the app nor your account can be erased: the photo stays as it is until RunMyB decides on it and, under item 4, for as long as the law requires. RunMyB aims to decide on such a photo within 14 days. A hold does not by itself take a photo out of the version of your app already published: the photo leaves it at your app's next update, or sooner where RunMyB stops serving your app (Section 7).

The platform may suggest a description of each photo for visitors who cannot see it, written by AI (Section 13); a photo is used in your app only once you have confirmed its description, as suggested or as you edited it, or marked the photo as decoration. A photo reaches your app at its next build or update, and a photo you remove leaves your app at its next update; the earlier versions of your app that the platform keeps, and its copy of your app's code history, keep a removed photo as the Privacy Policy's Section 2.8 states. That section describes the personal data involved.

11. AI-assisted output (the output clause)

The following is the split for AI-assisted output, stated plainly:

1. As between you and us, you own the output your ventures produce through the platform.
2. We assign to you any rights we may have in that output, to the extent we have any.
3. The output is Your Content — the narrow operating licence in Section 10 applies to it, including running your app where you ask us to host it.
4. You must review anything you build before you rely on or ship it: AI output can be wrong, incomplete, or insecure, and you are responsible for testing and validating it before use.
5. No uniqueness and no warranty of copyrightability. Purely AI-generated output may not be protectable by copyright, the same or similar output may be produced for others, and we make no warranty that any output is original, non-infringing, or copyrightable.

12. Git-provider integration

12.1 Export and takeover — your code on your provider

You may connect your own git hosting provider (GitHub, GitLab, Bitbucket, or a self-hosted service) and export a product's code repository to it, under your provider account. The code is already yours under Sections 10–11; export changes where it lives, not who owns it. On export the platform pushes a fresh single-commit history containing the product's current committed code — the platform's internal build history does not travel. The platform retains its local copy of the repository and its full local history as an operational record (it is what the platform builds from, verifies against, and serves previews from); that copy remains covered by the operating licence in Section 10.

12.2 The continued-operation grant

While a provider connection and a product's repository binding both stand, you grant the platform the right to read from (fetch) and write to (commit and push to) the bound repository, within that connection's scope, so the platform can keep building, fixing, and evolving the product you asked it to operate. The grant's shape is deliberately narrow, and the platform's code enforces it structurally:

1. Default: proposal branches. In the default ("pr") mode the platform pushes only to its own "runmyb/…" branches in your repository and proposes changes for you to merge; it does not write to your default branch. A direct-push mode is your explicit opt-in.
2. Never force. The platform never force-pushes to any branch of yours; forced updates are only ever applied to the platform's own "runmyb/…" namespace, and only with a lease check.
3. Never discards. When the platform adopts your newer remote work, the prior local state is preserved first (under a platform-owned reference namespace); adoption never deletes your commits.
4. Revocable at any time, by disconnecting. Deleting the provider connection (or the product's binding) revokes the grant: the stored token is deleted and all remote operations stop — every bound product flips to a named "connection revoked" state rather than failing silently. The platform's local copies remain, under the Section 10 licence, as the operational record of the service you used. Stated plainly so revocation is not misunderstood: after disconnecting, the platform can no longer fetch from or push to the repositories that rode that connection, and their bindings stay in the revoked state until you act. A disconnected connection is not revived; the supported recovery is to connect the provider again (a new connection) and re-point each affected product's existing binding at it — a supported action that changes which credential authenticates, never where anything is pushed. (An expired or rotated token on a live connection is replaced in place on the Connections surface, without disconnecting.)

12.3 Import — your warranty for code you bring

When you import an existing repository, you affirm that you hold the rights needed to bring that code onto the platform and to grant the Section 10 operating licence over it, and that you take responsibility for it — including compliance with any third-party licences the imported code carries, which remain your responsibility. The platform records this affirmation at the moment of import (an append-only attestation record keeping the exact wording you saw), together with the import's provenance (where the code came from, at which commit). Imported code is Your Content under these Terms, including the AUP and the content-safety rules.

12.4 Secret scanning — a safeguard, not a warranty

Before pushing your code to a provider, the platform runs an automated secret scan over the exact content to be pushed and refuses the push when it finds likely credentials (naming the findings with masked values, so you can remove or rotate them — the platform never edits your code silently). On import, findings are reported to you but do not block the import (the content is already in your own repository; the report is so you can rotate). This scanning is a safeguard operated on a best-effort basis: the platform does not warrant that it will detect every secret, and keeping credentials out of your repositories remains your responsibility.

13. AI disclosure (AI Act Article 50)

The assistants you interact with are AI systems. Their output may be inaccurate, you must review it, and you own it subject to Section 11. This is stated again in-product where you converse with an assistant: on screen, by the marker on every assistant line — in a voice session too, where the session's transcript is on screen throughout and every line of the voice assistant's carries that marker; and a voice session exists only because you opened it, from the console entry offering a spoken conversation with the platform's assistant, which this section and Section 6.1 of the Privacy Policy state is an AI system speaking with a synthetic voice. The AI providers behind the assistants are named in the Privacy Policy's sub-processor list (Section 5.1), which, for a role routed through OpenRouter, states how OpenRouter chooses the provider: Anthropic PBC runs the AI assistants and build agents that process workspace content, for the platform roles configured to use it; the voice assistant you converse with in a spoken session runs on one of two engines, as Section 6.1 of the Privacy Policy describes — OpenAI (OpenAI OpCo, LLC), whose speech model listens and speaks directly with your browser, or ElevenLabs (Eleven Labs Inc.), whose speech engine listens directly from your browser and whose voice model speaks the assistant's replies, which the platform relays to your browser, while a small model reached through OpenRouter, Inc. — Jev, provided by TypeSafe AI, Inc. — chooses the assistant's short reactions and judges whether what was said was meant for it; and OpenRouter, Inc. provides AI model routing for the platform-side roles configured to route through it — today among them the activity narrator, the avatar director, the avatar author, the idea author, the photo describer, the automated content-safety checks the Privacy Policy's Section 9 describes, the voice assistant's reaction model and the phrasing of its notes on the ElevenLabs engine, the build roles, the market research (including the study of the field that Section 10.4 describes), the planning roles and the console's chat assistants — routing each request to the provider of the configured model, which serves it as OpenRouter's own provider, each request on RunMyB's own OpenRouter account carrying a routing instruction that excludes providers whose terms allow the use of request data for model improvement, as Section 5.1 of the Privacy Policy and Section 7 of the Data Processing Addendum state. Where you use voice dictation, the speech-to-text engines are ElevenLabs (Eleven Labs Inc.), which is named in that list, and Microsoft's MAI-Transcribe model, reached through OpenRouter, Inc., which is named in that list and uses Microsoft as its own provider — as described in Section 6 of the Privacy Policy: they turn what you say into text that you edit and send yourself — they are not assistants you converse with. The activity narrator — the running account of a venture's work shown on the venture's "What's happening" card, described in Section 2.2 of the Privacy Policy — is likewise written by an AI model, reached through OpenRouter, Inc. as named above, from the venture's own records: it is an account, not an assistant you converse with; its entries may be inaccurate or incomplete and you must review them against the work itself; and nothing in it acts on your behalf. When the console's chat avatar is asked to act out an action that neither your account's learned actions nor its built-in actions answer, the new animation is likewise written by an AI model — the avatar director, reached through OpenRouter, Inc. as named above — as described in Section 2.3 of the Privacy Policy: it is an animation only, it acts on nothing on your behalf, and it may not look like what was asked for. When you create your own avatar from a description in your account settings, the drawing and the one-sentence description shown with it are likewise written by an AI model — the avatar author, reached through OpenRouter, Inc. as named above — as described in Section 2.4 of the Privacy Policy: the console marks a new drawing as made by AI, it is a picture only, it acts on nothing on your behalf, and it may not look like what was asked for. The ideas for products that the Ideas stream offers you, and that the platform's assistants suggest from it, are either written by an AI model — the idea author, reached through OpenRouter, Inc. as named above — or drawn from the platform's own starting set of ideas, as described in Section 2.7 of the Privacy Policy: they are suggestions, offered without exclusivity (Section 10.1), and may be inaccurate or out of date; nothing in them acts on your behalf, and a venture is created from one, and its plan started, only when you ask for it. The cost and time an idea shows are measured on earlier launches: they are an estimate, not a price, a quote or a limit, and a launch is charged for the work it uses (Section 14). When you add your own photos to an app (Section 10.5), the description the platform may suggest for each photo — the text a screen reader speaks to visitors who cannot see it — is likewise written by an AI model, the photo describer, reached through OpenRouter, Inc. as named above, as described in Section 2.8 of the Privacy Policy: the console marks the suggestion as written by AI, it may be inaccurate, and it becomes your app's text only once you confirm it, as it stands or after editing it — from then on it is your app's content, which Section 15, item 1, makes yours to answer for. While a dictation session or a voice session is open, the microphone captures whatever is audible and it is transmitted as the Privacy Policy describes; you are responsible for what you allow the microphone to capture, including other people's speech, and for any permission that requires. In a voice session the assistant changes nothing by itself: every change it proposes is shown as a card that runs only when you tap to confirm it — unless you have turned on voice confirmation in your settings, your own choice, off unless you turn it on and remembered until you turn it off, in which case a confirmation spoken while the session is open runs the change (spend included) and is yours — and it runs only after the change that will run has been put to you (on the card, and handed to the assistant to state in speech) and a short veto window has passed, in which saying that you want it stopped, in any words and any language, or tapping Cancel on the card, stops it. Decisions on the platform's own approval gates are never taken from voice.

14. Fees, credits & payments

1. Credits. Paid platform usage is denominated in prepaid credits. Credits are a means of using the service — they are not money and are not transferable, and, except for the statutory refunds described in the "Refunds, Cancellation & Complaints" policy or where the law requires, they are not redeemable for cash. Credits you purchase do not expire. Promotional or granted credits (including subscription allowances) may carry an expiry; each credit lot's expiry — or the fact that it never expires — is shown per lot in your Billing view. Credits are consumed by the work you ask the platform to perform: usage is metered as the work happens, including where the output of a given piece of work turns out imperfect — AI-assisted work does not carry an outcome warranty (Sections 11 and 18) — and if you believe a charge was wrong, the complaints route in the "Refunds, Cancellation & Complaints" policy is the named remedy. The bundles and prices in force are shown at the point of purchase, and every charge — with the rate and any margin applied — is itemised in your Billing view; changes to rates, bundles, and account-specific settings are effective-dated, prospective, and never silent or retroactive. Refunds, cancellation, your statutory withdrawal rights, and the withdrawal waiver for credits put to use are governed by the "Refunds, Cancellation & Complaints" policy.
2. The usage margin. Usage pricing includes a platform margin over raw model and infrastructure cost. The margin applied to your usage is effective-dated and itemised with each charge in your Billing view whenever it differs from the baseline; changes never apply retroactively.
3. Payment-processor choice. Where your apps take payments from your own end-users through your own payment processor, the platform takes no share of your revenue — and your account's usage margin may be set correspondingly higher. Any such setting is effective-dated, applies only prospectively, and is itemised on the charges it prices in your Billing view — never silent or retroactive. The margin in force for your account is therefore always readable from your Billing view: every charge is itemised with the margin that priced it whenever it differs from the baseline, and the absence of a margin line means the baseline applied. Changes follow point 2 — effective-dated, prospective, never retroactive.
4. Integrated payments (where offered). Where the platform offers integrated payments, you are the merchant of record for your end-user transactions, the payment provider performs onboarding and identity verification, you bear your own end-user refunds and disputes, and the platform's remuneration is a disclosed application fee shown in-product together with your earnings. When a sale is refunded, disputed, or charged back, the application fee on that sale is not returned: the fee compensates platform processing that was already completed when the sale was made.
5. Billing documents. Invoices and receipts for subscriptions and credit purchases are produced through the payment processor and surfaced in your Billing view.
6. Taxes. Stated prices are exclusive of applicable taxes unless expressly stated otherwise.

15. Hosted apps and your end users

Where the platform hosts or serves your app — in previews, or publicly where the platform offers public hosting:

1. Your app is yours to answer for. You are solely responsible for your app, its content, its lawfulness, its end users, and the notices your app owes its own users (including your own privacy notice where your app processes personal data). For your end-users' data, you — not RunMyB — are the responsible party; RunMyB is not a party to the relationship between you and your end users. Where RunMyB processes personal data on your behalf, the "Data Processing Addendum" forms part of these Terms and governs that processing. The records the platform itself keeps of visits to your app are RunMyB's own: RunMyB keeps them as an independent controller, as Section 4 of the Privacy Policy describes, and your app's own notice can tell its users so, for example: "This app is hosted on RunMyB, Inc. RunMyB keeps, as the controller of these records and for its own purposes, records of visits — such as the visitor's network address, browser and device information, the pages visited and the referring site, the time of the visit and a pseudonymous visitor identifier — for up to 30 days, for the security and operation of its platform and for statistics. Section 4 of the RunMyB Privacy Policy at runmyb.com/privacy describes them and how to reach RunMyB about them."
2. Serving domains stay ours. The platform owns its serving domains and hosting infrastructure. We may reassign or reclaim subdomains, hostnames, and hosting slots on at least 7 days' notice — and immediately where security, legal compliance, or abuse requires it.
3. No app-availability warranty. We do not warrant the availability of your hosted app; Section 5's early-access terms and Section 18's disclaimer apply to hosting.
4. Child-safety reporting. Where apparent child sexual abuse material is discovered in hosted content, RunMyB preserves the material and the associated records and reports to the National Center for Missing & Exploited Children (NCMEC) as US law (18 U.S.C. § 2258A) requires. This is a legal duty, not a discretionary act, and it is not subject to appeal under Section 7.
5. Statistics. RunMyB may publish aggregate statistics about the platform and the apps built on it at any time, provided they identify no visitor and single out no app — an aggregate is published only when enough apps stand behind it that no app's figures can be read from it. Statistics about your app alone are shown publicly only with your recorded consent — for example when you choose to show them with your app's catalogue listing (Section 15A) — which you may withdraw at any time.
6. Demo notices. The platform may publish your hosted app as a demo. RunMyB then adds, to every page of the app it serves at the app's public address, a banner saying that the app is a demo and, on a visitor's first visit, a notice the visitor is asked to acknowledge, both in RunMyB's own words, which may name a specialist field: legal, financial, health or safety (the Cookie & Tracker Notice describes what a visitor's browser keeps of that acknowledgement). An app is published as a demo where you choose it, when you ask to publish the app or later, or where RunMyB decides so, when it approves the app's publication or later. The banner and the notice are added as the pages are served and leave your app's own files unchanged; so that they load and show, the platform also adjusts the caching and encoding headers of the app's HTML responses and amends the content-security policy of its pages, only to admit the notice's own script and stylesheet, and a page it cannot mark is not served while the demo notice is on. While the demo notice is on, the platform also does not serve, at the app's public address, a script a visitor's browser asks for as a service worker, so that the app cannot install or update, from that address, a service worker that would show its pages from the browser's own storage without the banner and the notice; the platform itself removes nothing a visitor's browser already keeps, and the app's service worker is served again once the notice is off. You may remove the demo notice at any time from the app's publication card, including one RunMyB applied, and the app stays published. By removing it you confirm that you have checked the app's content — the review Section 11.4 already asks of you before you ship it — and that the notice is no longer needed. RunMyB may also remove a demo notice you chose, and you may turn it on again. The platform records who turned a demo notice on or off, and when. A demo notice changes nothing in item 1: your app and its content remain yours to answer for, and RunMyB's decision to publish an app, with a demo notice or without one, is not a review of whether its content is correct, complete, or fit for any purpose.
7. Your app's own messages. Where your app has the platform send its users messages of its own, written from the templates your app carries (the platform's published email page describes how), those messages are yours to answer for: what they say, that you may lawfully send each of them to its recipient, and what the law requires of them. You may use them only for transactional messages — messages about the recipient's own dealings with your app, or that the recipient asked your app to send — and never for marketing, advertising or other promotion. The platform checks the form of your templates and of the values your app fills into them — for example, that each link a template declares leads to your app's own address — never their wording, and it does not review what your messages say. It renders and sends each message itself, with its own last lines, which name your app and RunMyB and carry an unsubscribe your app cannot remove; it sends a message only to an address confirmed for your app, and only within the platform's limits, asking an address not yet confirmed to confirm itself instead; and once the platform has accepted your app's request for a message, its answer to your app is the same whatever becomes of that message. RunMyB may switch your app's own messages off — automatically, when the platform receives enough spam reports about them, or about the platform's requests to confirm an address sent in their place, or by its administrators' decision where the platform's e-mail, its delivery or the people it writes to require it — and only RunMyB's administrators switch them back on. While they are off, the platform refuses your app's requests for them, saying why, and it e-mails your account's administrators that they were switched off (Section 4), unless they have turned that notice off. You may ask for them to be switched back on; such a request is handled as an appeal under Section 7. Switching them off leaves your app's sign-in mail unaffected. From your app's preview, the platform sends one of your app's own messages only when it is addressed to the address with which the member of your account who started that preview from the console signs in to the platform, without first asking that address to confirm itself and without an unsubscribe; every other such message stays on the preview, unsent, and the preview's own mail page lists it where your app has that page; and the platform's answer to your app's request from a preview is the same whether or not it sends the message, also while your app's own messages are switched off.
8. Files your app keeps. Where your app keeps files on the platform for its users, RunMyB may act on a single stored file — under Sections 7 and 8, or as item 4 requires — by withholding it or deleting it. The platform also has each file your app stores scanned automatically for malicious software (malware), soon after it is stored, and withholds a file in which the scan finds such software: automatically, before any person at RunMyB has looked at it, and without the withholding being, by itself, a finding that you or whoever added the file did anything wrong. The platform itself deletes no file because of the scan. A file is served until the scan has judged it, and a file the scan cannot judge — one protected with a password, for example — is served unscanned; where a scan could not be completed, the platform tries it again, at most three times and at least twenty minutes apart, telling your app meanwhile that the file is still being checked, and then serves the file unscanned if it still has not been judged. The scan is a safeguard operated on a best-effort basis: the platform does not warrant that it finds all malicious software, and the files your app keeps, and what it does with them, remain yours to answer for (item 1). While a file is withheld, the platform gives your app no further access to its content, and your app cannot delete it. While a file is withheld, neither your app nor your account can be erased until RunMyB has decided on it: a file the scan withheld, or one withheld on a notice, we then delete, and the erasure proceeds; a file that item 4 or a legal demand to preserve it requires us to keep stays for as long as the law requires. When the scan has a file withheld, the platform e-mails your account's administrators the statement of reasons — which file it is, why it was withheld and how to contest that — in a notice no setting turns off (Section 4), unless the law requires RunMyB to delay it; and it tells them, once for each app and without naming any file, when files your app stores cannot be scanned, unless they have turned that notice off. You may ask us, through support@runmyb.com, to delete a withheld file, except one item 4 requires us to preserve, and to release a file the scan withheld if you think the scan was wrong; such a request to release it is handled as an appeal under Section 7. A withheld file does not count against your storage allowance.
9. Background jobs. Your app may declare jobs — work it has the platform start for it on a schedule it declares, soon after it asks or at a later time it names, or when you start a run in the console — and the platform then calls your app's own address for each run, waking the app to do so if it is asleep; the "Data Processing Addendum" (its Section 2) states what the platform keeps of each run. A job runs only as the version of your app that the platform serves declares it, and only within these limits. Your app may declare at most 20 jobs, and a schedule may come due at most once every 15 minutes, your app's schedules at most 400 times a day in all. A run may be handed at most 16 KiB of data and be asked for at most 30 days ahead; your app cannot ask for a run while 1,000 of its runs are waiting; at most 2 of its runs run at the same time, and only one of each job; and each attempt of a run is given the time its declaration sets, at most 280 seconds, a run being tried at most the number of times its declaration sets, at most 5. Each day, a UTC day, no run of your app starts once its runs have been started 500 times, each retry counting, or have run for 2 hours in all; and no run that would wake an app, or run while it is up only for its jobs, starts once your account's apps have made 1,000 such runs, as the platform counts them. Beyond these limits, a declaration or a request for a run is refused or the run waits; a run still waiting 24 hours after the time it was due is not run; a scheduled run that comes due while the job's previous run is unfinished is skipped; and the runs a schedule misses while it cannot run — while it or your app's jobs are paused, or while the platform cannot start them — are made up by at most one. Unlike the operational values Section 24 leaves in-product, these limits change only with these Terms (Section 24). What a job does is yours to answer for, as item 1 says of your app: the platform checks the form of each declaration, never what the job does, and a job may have the platform send messages only as your app otherwise may (item 7). The platform does not promise that a run starts when it is due: a run may start late or run more than once, and a run that keeps failing is given up after the attempts its declaration allows. You see your app's recent runs, and how each ended, in the console, where you can also start a run, run a failed one again, cancel one that waits, and pause or resume your app's jobs; the platform does not e-mail you when a run is given up. Preview links run no jobs. RunMyB may pause your app's jobs where the security or operation of the platform or the people your app serves require it, or where your app's jobs cause the platform a cost out of proportion to what these limits allow; the console then shows that your app's jobs are paused, and why, and the platform e-mails your account's administrators that they were paused (Section 4), unless they have turned that notice off. Only RunMyB's administrators lift such a pause; you may ask for it to be lifted, and such a request is handled as an appeal under Section 7.
10. Messages to your app. An app the platform hosts with a server of its own may have the messages people write in its contact form reach you through the platform (the platform's published email page describes how), and only an app whose form hands its messages to the platform receives any this way. For each message, your app's server hands the platform its text, the address the person gave for a reply and, if they gave one, their name; the platform keeps them for your account, shows them in the console, as plain text with any link shown as text, to the members of your account who can see your app — for an app that only one member of your account can see in the console, to that member alone — and e-mails your account's administrators, or that member, a notice that a message arrived, which carries nothing of it, unless they have turned that notice off (Section 4). The platform takes a message written in your app's form from your app's server, not from the person who wrote it, and does not check who wrote it or what it says: not for viruses, not for spam, and not whether the name and address given are that person's own. It cannot tell a person from a program writing through your app's form; your app's own form is where such messages can be stopped. The platform sends nothing to the address a person gave — any answer comes from you, from your own e-mail — no AI model or assistant on the platform reads a message, and the platform acts on nothing a message says. It takes messages for your app only within its daily limits, for your app and for each reply address, and none while your app's inbox is switched off or your account is suspended or terminated (Section 21); it then refuses your app's request, saying why, and keeps nothing of it. From your app's preview it takes no message: one written there stays on the preview. Such an app may also have an e-mail address of its own on the platform, made from its address on runmyb.app and shown in the console, and e-mail sent to that address reaches you the same way, whether or not your app shows the address; an address your app no longer has receives nothing. The platform receives that e-mail through its mail provider, which scans it for viruses and spam, and delivers it only if the scan found neither, if it is within the platform's size limit and if its sender's address passes the e-mail authentication of its own domain, or of a domain related to it — which shows that the e-mail came through a mail service that domain allows, not who wrote it, and leaves the sender's name unchecked; it delivers none while your app's inbox is switched off or your account is suspended or terminated, and only within its daily limits, for your app and for each sender's address. Of an e-mail it delivers, it keeps for your account the sender's address and name, the subject, the text, as plain text with any link written out as text and cut at a set length, and the list of the attached files, keeping only files of a few common kinds — PDF, PNG, JPEG, GIF, WebP and plain text — whose contents match the kind they state. The members of your account who can see your app download a kept file in the console, under a name the platform gives it from the kind it verified, and the platform itself never opens or runs it; a kept file is deleted with its e-mail, your app cannot reach it, it is not one of the files your app keeps (item 8), and it is not part of your account's data export, so download one you need while it is kept. An e-mail the platform does not deliver is deleted, and the platform keeps only a count, by day and reason, which the console shows you for the current day; it tells the sender nothing, not even that the e-mail was not delivered. The platform deletes each e-mail as it was received once it has delivered it or counted it. It deletes each message after 90 days, so keep your own copy of one you need for longer (Section 5). The members of your account who can see your app can delete a message sooner, and can switch your app's inbox off and on in the console. The messages are your app's end users' data, which RunMyB processes on your behalf under the "Data Processing Addendum" (item 1), and what you do with them is yours to answer for. Your app's own notice can tell the people who write to it so, for example: "Messages you send through this form, or by e-mail to this app's address, reach us through RunMyB, Inc., which hosts this app and keeps them for us, deleting its copy after 90 days; RunMyB also keeps, as the controller of that record and for its own purposes, a daily count of the messages this form sends it for each reply address, and of the e-mails it delivers to this app from each address, identified only by a hash, for two days — Section 2 of the RunMyB Privacy Policy at runmyb.com/privacy describes it."

15A. The public catalogue: listings, ranking, and reviews

The platform is beginning to operate a public catalogue of hosted products. It is new and small; the commitments below bind as it operates and are stated now so they are on the record from the start.

1. Listing is consent-based. Every published product in good standing is eligible for a catalogue listing as that surface opens. Your product is listed only with your recorded consent, which you may withdraw at any time; withdrawal removes the entry.
2. Ranking transparency. The main parameters determining how catalogue entries are ordered and presented are: recency, platform curation ("recommended" picks are editorial choices made by us), visitor ratings, and usage signals. Placement is not influenced by payment. If paid placement is ever introduced, it will be labelled as advertising.
3. Reviews and ratings. Visitor ratings are not verified purchases, and we say so where they appear. We do not suppress a rating for being negative. Removing a catalogue entry and removing a rating are separate acts, and each is recorded. Submitting, commissioning, or incentivising fake ratings or reviews violates the "Platform Rules — Content-Safety Taxonomy".
4. Contesting a decision. You may contest a ranking, a rating, a listing, or a delisting by writing to support@runmyb.com; the complaint is handled under the process described in the "Notice-and-Action & Contact Points (DSA)" policy.

16. Third-party services you connect

The platform lets you connect third-party services under your own accounts — git providers, Google services, Trello, Notion, AI providers under your own keys, and similar. Each such service is governed by its own terms and privacy policy, which you are responsible for accepting and observing. By connecting a service you authorise the data flows you initiate through that connection (described in the Privacy Policy); disconnecting stops them. RunMyB is not responsible for third-party services, their availability, their acts or omissions, or the consequences of your configuration of them.

17. Feedback

If you send us feedback, suggestions, or ideas about the platform, you grant us a perpetual, irrevocable, worldwide, royalty-free, sublicensable licence to use them for any purpose, without obligation, compensation, or attribution. Feedback is not Your Content under Section 10.

18. Disclaimer of warranties

TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, THE SERVICE IS PROVIDED "AS IS" AND "AS AVAILABLE", WITHOUT WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, AND ACCURACY. WE DO NOT WARRANT THAT THE SERVICE WILL BE UNINTERRUPTED, SECURE, OR ERROR-FREE, THAT DEFECTS WILL BE CORRECTED, OR THAT ANY OUTPUT WILL BE CORRECT, COMPLETE, OR FIT FOR YOUR PURPOSE.

Nothing in this section limits the warranties or conformity remedies that applicable law grants you as a consumer and that cannot be excluded or limited by agreement (Section 23).

19. Limitation of liability

TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW: (a) NEITHER PARTY IS LIABLE FOR INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, EXEMPLARY, OR PUNITIVE DAMAGES, OR FOR LOST PROFITS, REVENUES, DATA, OR GOODWILL, EVEN IF ADVISED OF THE POSSIBILITY; AND (b) RUNMYB'S AGGREGATE LIABILITY ARISING OUT OF OR RELATING TO THESE TERMS OR THE SERVICE IS CAPPED AT THE GREATER OF (i) ONE HUNDRED US DOLLARS (US$100) AND (ii) THE FEES YOU PAID TO RUNMYB IN THE TWELVE MONTHS PRECEDING THE EVENT GIVING RISE TO THE CLAIM.

Nothing in this section limits your indemnification obligations under Section 20 or your obligation to pay fees due.

What this clause never limits. Nothing in these Terms excludes or limits liability for intentional misconduct or gross negligence, for death or personal injury caused by negligence, or for any other liability that cannot be excluded or limited under applicable law. If you are a consumer, your statutory remedies remain unaffected to the extent they cannot be waived.

20. Indemnification

You will defend, indemnify, and hold harmless RunMyB, Inc. and its officers, directors, employees, and agents from and against third-party claims, and the resulting liabilities, damages, and reasonable costs (including reasonable attorneys' fees), to the extent arising from: (a) Your Content; (b) apps you build or direct the platform to operate, and your own end users; (c) your breach of these Terms; or (d) your violation of law or of a third party's rights. We will give you prompt notice of any such claim — a failure to notify does not relieve your obligations except to the extent you are materially prejudiced by it; you may not settle a claim in a way that imposes obligations on us without our consent, and we may participate in the defense with our own counsel at our expense. If you are a consumer, this section applies only to the extent permitted by the law of your habitual residence and only to claims caused by your breach, Your Content, or your apps.

21. Suspension & termination

1. By you. You may stop using the platform at any time, and you may terminate by filing account deletion (offboarding) from your account surface.
2. By us. We may suspend, restrict, or terminate your access for material breach of these Terms or the AUP, for legal or regulatory risk, for a security threat, or for non-payment. Enforcement is graduated where practicable (Section 7); we may act immediately where the violation, the law, or an imminent risk of serious harm requires it. We may also terminate these Terms for convenience on at least 30 days' notice — your export paths (Sections 5 and 12) remain available through the notice period — and may close accounts for inactivity only after at least 12 months without activity, and only with notice to the account's e-mail address before the closure takes effect.
3. Effect of termination. On termination your access ends. Offboarding runs a grace period whose end date is stated when you file the deletion request; during that period the deletion can still be called off — through your account surface where it remains accessible, or by contacting support@runmyb.com. After it, your data is handled as the Privacy Policy describes (tiered erasure, with the retention the law requires). Whether any amounts are refundable is governed by the "Refunds, Cancellation & Complaints" policy — which states the rule for an unspent balance at account closure — and applicable consumer law.
4. Survival. Sections 10 (for retained records, to the extent stated there), 10.4 (for the affirmations you made and their records), 11, 12.3, 15 (item 6, for the confirmations you gave and their records), and 17 through 25 survive termination.

22. Export control & sanctions

You represent that you are not located in a jurisdiction subject to comprehensive embargo, are not on any applicable sanctions or denied-parties list, and will comply with applicable export control and sanctions laws in your use of the platform.

23. Governing law, disputes & consumer rights

1. Governing law and venue. These Terms are governed by the laws of the State of Delaware, without regard to its conflict-of-law rules. Subject to point 3 below, the state and federal courts located in Delaware have exclusive jurisdiction over disputes arising out of or relating to these Terms or the service, and both parties consent to their jurisdiction.
2. Talk to us first. We ask — without limiting your rights — that you contact us at hello@runmyb.com before filing a claim; most issues can be resolved quickly and informally.
3. If you are an EU/EEA consumer. Nothing in these Terms deprives you of the protection of the mandatory provisions of the law of your country of habitual residence, and the choice of Delaware law does not displace them. You may bring proceedings in the courts of your home Member State, and proceedings against you may be brought only there. Your withdrawal rights are described in the "Refunds, Cancellation & Complaints" policy. Where any clause of these Terms conflicts with a mandatory consumer protection that applies to you, that protection prevails.
4. Individual basis; jury waiver. To the extent permitted by applicable law, disputes will be resolved on an individual basis — neither party will participate in a class, representative, or consolidated action against the other — and both parties waive trial by jury. This point does not apply where such waivers are prohibited by law, including for EU/EEA consumers.

24. Changes to these Terms

The platform is under active development, and these documents evolve with it; by accepting these Terms you also accept this change process. We update the legal documents for stated kinds of reasons: new or changed features, legal or regulatory requirements, security, and changes to pricing mechanics.

• A material change requires your renewed acceptance before you continue using the console.
• A non-material change takes effect on posting; the new version number, its effective date, and the changelog are the notice of the change, and you are invited to review them.
• In plain language, so the split is not ours to stretch: material means a change that reduces your rights or adds an obligation on you — for example, narrowing the licence limits in Section 10, adding a new fee category, or widening what you indemnify us for; such a change fires the re-consent gate. Non-material means a new restriction on RunMyB, a disclosure, a clarification of something already true, or a change in your favour; such a change takes effect on posting.
• A change never retroactively removes value you have already paid for. Operational values — rates, bundles, margins, allowances, and similar settings — live in-product (Section 14) and change through the platform's effective-dated configuration, not through these documents.
• Every version is dated, versioned, and kept in the changelog.

25. General provisions

1. Entire agreement. These Terms, together with the documents they incorporate by reference, are the entire agreement between you and RunMyB about the service and supersede prior understandings on that subject.
2. Severability. If a provision of these Terms is held invalid or unenforceable, it is enforced to the maximum extent permissible and, where necessary, deemed modified to the minimum extent needed to make it valid — and the remaining provisions stay in full force.
3. No waiver. A failure to enforce a provision is not a waiver of it.
4. Force majeure. Neither party is liable for failure or delay caused by events beyond its reasonable control, including natural disasters, war, terrorism, labour disputes, failures of the internet or utilities, and acts of government.
5. Contact. Questions about these Terms: hello@runmyb.com.