Privacy

Who runs this service

StartupsMRR is operated by Tarun Kumar, an individual based in India, who decides what data is collected and why. Under India's Digital Personal Data Protection Act, 2023 that makes the operator the Data Fiduciary for the personal data described here. Questions, requests, and grievances go to support@startupsmrr.com.

The service is in an invited beta. This policy describes the system as it actually runs today rather than features that are planned.

What is collected

• Account identity from Google sign-in: your Google account identifier, email address, and display name. Signing in is optional and only needed to add or manage a startup. Your username is shown publicly on your comments, mentions and profile card; your account name and email never are. A name and photo are shown only on a public founder profile.
• Startup submissions: name, description, website address, logo, category, audience, business model, pricing, country, and launch date, as entered by you.
• Domain ownership evidence: the domain being claimed and a one-time verification token published as a DNS record.
• Revenue-provider credentials: an API key from your payment provider (Stripe, Dodo Payments, Paddle, Polar, Lemon Squeezy or RevenueCat), and a second one only if you connect a second provider. Each is encrypted before storage and is never displayed back to you, to administrators, or in any log.
• An optional founder profile, only if you create one: a display name, public handle, headline, short bio, country, up to five links, and a photo. The photo is either uploaded by you or, if you choose, a copy of your Google profile picture that this service stores itself. Your consent to publish it is recorded with the time and the notice you saw.
• Aggregate revenue figures read from that provider: monthly recurring revenue, a count of active subscriptions, and a count of distinct customers.
• Administrative records: moderation decisions, verification attempts, synchronisation runs, and scoring calculations, each with a timestamp and the account that caused them.
• Sponsored placement records, once paid placement opens: the brand name, website, category, and logo you submit, plus the payment amount, currency, provider payment reference, and the email address the payment provider reports for the payer. Card details are handled by the payment provider and are never seen or stored by this service.
• Verified revenue record settings: the startup, optional recipient label, exact-or-range choice, access mode, history window, issue and expiry times, revocation state, and aggregate opening count. A recipient email is stored only when the founder chooses access restricted to that address. Only a SHA-256 fingerprint of the random bearer token is stored, so the private link cannot be recovered or shown again.
• Identified record access: when a record requires identification, the email address entered by its reader, whether control of that address was proved, and the time it opened. A verified-access code is emailed to the address selected by the founder; only a keyed digest of the code is stored, never the code itself.
• Abuse-prevention and aggregate traffic records: the hosting provider reports a network address when a request arrives. The application immediately converts it into a keyed, purpose-specific pseudonym and stores only that pseudonym, a short time window, and a request count. The raw address is not written to the application database. The same process measures unique loads and profile visits from verified badges without identifying the visitor.
• Trust Page analytics for its founder: daily counts of page views, visitors and clicks through to the company's website, and where visitors came from (a site name such as "google", or a tag the founder added to their own link). Each visitor is counted once a day through a pseudonym keyed to that day, that startup and that kind of event, deleted after two days, so visits cannot be linked across days or startups. Only the startup's owner sees these counts.
• Error reports: when a page or request fails, the error message (with email addresses, keys, tokens and query strings removed), the route where it happened, and when. No request body, account or address is kept with it. Reports are deleted 30 days after being fixed, or after 90 days.

What is deliberately not collected

The revenue integration reads only aggregates. It does not retrieve or store your customers' names, email addresses, invoices, payment methods, card details, or any individual transaction.

Customer identifiers are held in memory only long enough to count how many distinct customers a subscription set contains, and that count is the only thing written down. No customer-level record is ever persisted.

Keys that can change your payment account are refused. Full Stripe secret keys are rejected before any request is made; only restricted read-only keys are accepted. Dodo Payments, Paddle, Polar and RevenueCat keys are tested before they are saved, and one that can write is rejected. Lemon Squeezy is the one exception: its keys cannot be limited to reading, so a Lemon Squeezy key is accepted only after you confirm you understand it has full access. The service only ever sends read requests with it, and disconnecting erases the stored copy immediately.

A verified revenue record is never a stored copy of revenue. Its page reads the current verification boundary when opened, whether the startup is publicly listed or unlisted. The raw private-link token is not stored, logged, or returned after creation.

The service does not store a plaintext verified-access code. It does not claim that a watermark prevents screenshots or forwarding; identified access creates disclosure and an audit trail, not copy protection.

Why it is collected

• To confirm that a startup listing belongs to the person submitting it, so that published figures cannot be claimed by someone else.
• To read verified revenue directly from a payment provider rather than trusting a form, which is the entire basis of the ranking.
• To calculate and publish a Market Momentum Rating and public ranking position.
• To keep an auditable record of moderation and verification decisions.
• To give a founder aggregate counts of unique verified-badge loads and resulting StartupsMRR profile visits.
• To let a founder share a current, expiring and revocable revenue attestation with a buyer, investor, lender, or other chosen reader.

What is published

For a startup that completes verification, its public Trust Page shows identity and verification status. The founder explicitly chooses whether MRR, paying customers, trend, and continuity appear exactly, as a range or direction where supported, or not at all. Market Momentum stays public for a listed company.

A founder may embed a signed StartupsMRR badge that repeats only a currently valid and disclosed claim: verified monthly revenue, current Market Momentum Rating, category or revenue-tier leadership, or verification continuity. During an infrastructure interruption the badge says verification is pending; withdrawn claims show no stale value.

A founder may create a private bearer link to a live verified revenue record without making the startup publicly discoverable. The founder chooses open access, reader-declared email, or access restricted to one email address; exact or range disclosure; and an optional recipient label visible to every permitted reader. Identified records display the reader's email and opening time as a watermark.

A founder profile is published only with your recorded consent, only beside companies you have not hidden it on, and only while that company is approved and publicly listed. It appears as a byline on the board, on the company's Trust Page, and on a founder page at /founders/<handle>, which lists those companies with each figure exactly as that company discloses it. A photo appears only after an administrator approves it. The “Founder at” mark is computed by checking whether your sign-in email is on the company's verified domain; the email itself is never published.

An account email is never published. A record viewer's email is shown only within the record they opened and to the founder who issued it; it is not searchable or placed on a public listing. Provisional ratings, test-mode figures, and stale readings are not published at all.

Retention and deletion

You can disconnect a revenue provider at any time from your dashboard. Doing so permanently erases the stored encrypted credential and stops all future synchronisation.

You can hide your founder profile on any company, or delete it entirely, from the startup dashboard at any time. Deleting it erases the profile and its stored photo immediately and removes the founder page.

You can request deletion of your account and startups by writing to the support address. Personal data is removed or anonymised on request.

Some records are kept deliberately. Revenue snapshots, scoring calculations, and administrative audit entries are immutable by design, because a ranking that could be quietly rewritten afterwards would not be verifiable. Where such a record must be retained, identifying personal data within it is anonymised rather than the record being deleted.

Abuse-prevention pseudonyms rotate every UTC day. Their counter rows become eligible for deletion after 24 hours and an hourly retention job removes them. Sponsored and verified-badge impression and click pseudonyms are purpose-separated per placement or startup and event, rotate daily, become eligible for deletion after 30 days, and are removed by the same hourly job; aggregate totals remain.

Verified-record opening pseudonyms are separately purpose-scoped to one record, rotate every UTC day, and are removed after 30 days. Only the aggregate opening count and last-opened time remain. Proof metadata remains in the founder's record history until its startup or owner account is deleted; revocation immediately makes its bearer link unusable.

Identified-viewer emails and their opening timestamps remain attached to the founder's record history and are deleted with that record. Short-lived access-code digests expire after ten minutes, cannot be used more than once, and are replaced when a later code is issued; they are deleted with the record.

Your rights

• Access the personal data held about you.
• Correct anything inaccurate or incomplete.
• Erase your account and submissions, subject to the retention note above.
• Withdraw consent by disconnecting a provider or closing your account.
• Raise a grievance and receive a response. Write to the support address and it will be treated as a grievance under the DPDP Act.

Processors and transfers

The service runs on Supabase (database, authentication, storage) and Vercel (application hosting and network protection). Vercel may process network addresses and request metadata in its own security logs. Google provides sign-in. The payment provider or providers you connect (Stripe, Dodo Payments, Paddle, Polar, Lemon Squeezy or RevenueCat) are read on your behalf. Resend delivers transactional email, including verified-record access codes. These providers process data on the operator's instructions, and their infrastructure may be located outside India.

No personal data is sold, and none is shared for advertising.

Security

Provider credentials are encrypted with a unique key per credential, which is itself wrapped by a separate master key held outside the database. Encryption is bound to the specific startup and provider, so a stored credential cannot be moved between accounts.

Administrative access is denied by default and granted only to explicitly authorised accounts. No credential value is readable through the application, by an administrator, or in any log.

No system is perfectly secure. If a breach affects your personal data, you will be notified along with the Data Protection Board of India as required.

Changes

Material changes will be reflected here with a new date. During the invited beta, participants will also be told directly.