Privacy Policy

1. Summary

Skanda Inc. runs this website. It has two halves. Most of it is public pages you can read without giving us anything. One page — the account page — lets you create an account, sign in, choose a paid plan and manage your billing.

Here is everything we do with personal data, stated plainly:

• Accounts. If you create one we hold your email address, a hashed password (never the password itself), a display name if you give one, and — if you signed in with Google or GitHub — the profile picture URL those services hand us. See section 4.5.
• One-time codes by email. Signing up with an email address and password requires a six-digit code we email to you. See section 4.6.
• Payments. Paid plans are handled by Stripe. Card numbers never reach our servers — you type them on Stripe's own pages. We hold Stripe's identifiers for you, your plan and its renewal date. See section 4.7.
• Bot protection. The account page runs Cloudflare Turnstile so that automated scripts cannot mass-create accounts or grind at the sign-in form. See section 4.8.
• Cookies. The account page sets four, all of them strictly necessary for a service you asked for: your signed-in session, a device-recognition cookie that lasts 90 days and exists so that a sign-in from an unfamiliar device can be challenged, a short-lived one that protects the OAuth sign-in handover, and Cloudflare's cf_clearance cookie, set because Turnstile runs in pre-clearance mode. There are no advertising, analytics or tracking cookies anywhere on this site, and there is no consent banner. See section 5.
• The App. Our desktop application reads the design files you open on your own computer, sends prompts to a model gateway, and keeps local databases on your machine. See section 4.5.
• The launch-updates email list. Still optional, still separate from having an account. We use it to tell you about Skanda Inc., its products, and its software. See section 4.3.
• Our hosting provider necessarily sees the technical details of your connection in order to serve the page to you — see section 4.1 — and the public pages run cookie-free analytics from that same provider — see section 4.2.

We do not sell personal data, we do not share it for advertising, and we do not build a profile of you.

This summary is a convenience. The sections below govern.

2. Scope

This policy covers personal data processed in connection with the website at skandarobotics.com and any subdomain or subpage of it, and with our desktop application ("the App") once installed on your own computer.

It does not cover:

• Websites operated by other organisations that we may link to. See section 13 of our Terms.
• Personal data processed in an employment or contractor relationship, which is handled under a separate internal notice.
• Business-to-business correspondence conducted entirely outside this website, which is governed by the arrangements agreed with the relevant counterparty.

The account is shared between the two: the same email address and password sign you in on this website and in the App. Everything this policy says about your account, your plan and your payments is therefore true in both places.

3. Who we are

"Skanda", "we", "us" and "our" mean Skanda Inc., a corporation incorporated in the State of Delaware, United States, with its principal place of business at 141 Highway 41, Suite B, Ringgold, GA 30736, United States.

For the purposes of the GDPR we are the controller of the personal data described in this policy. For the purposes of India's Digital Personal Data Protection Act, 2023 (the DPDP Act) we are a Data Fiduciary. For the purposes of the California Consumer Privacy Act as amended (CCPA/CPRA) we are a business.

We have not appointed a Data Protection Officer or a Grievance Officer, and we are not required to appoint one under the laws that apply to us. Privacy enquiries are handled directly by the officers of the company and reach them at support@skandarobotics.com. Vihaan Shah is appointed as our representative in the European Economic Area and as our representative in the United Kingdom under Article 27 GDPR and the UK GDPR respectively, and may be reached at support@skandarobotics.com. Our principal place of business remains 141 Highway 41, Suite B, Ringgold, GA 30736, United States.

4. What we collect today

The personal data we ask you for today is an email address if you subscribe for updates — section 4.3 — and, if you create an account, the account data in sections 4.5 to 4.8. Sections 4.1 and 4.2 describe what is processed anyway, as a consequence of the page being delivered over the internet, whether or not you ever type anything.

4.1 Server and hosting logs

The site is served by Vercel. Like every web host, Vercel's infrastructure receives and may log the technical details of each request in order to route it, serve it, protect the service from abuse and diagnose faults. Those details typically include:

• your IP address, or a truncated or derived form of it;
• the date and time of the request;
• the path requested and the HTTP status returned;
• your browser's user-agent string, and the referring page if your browser sends one;
• coarse network and geographic information derived from the IP address, typically no more precise than the country and region.

This is inherent to hosting a website at all — it is not a data collection decision we have made, and there is no configuration in which a web server can respond to a request without receiving it. We do not export, mine or enrich these logs, we do not join them to any other data set, and we do not use them to build a profile of you. They are held by Vercel as our processor and retained according to Vercel's own retention schedule, described in the privacy policy published at vercel.com/legal/privacy-policy.

One thing we do add to that stream ourselves, and would rather disclose than let you discover: when our subscribe endpoint refuses a request — because a rate limit was hit, an automated submission was detected, or a browser reported a security-policy violation — we write a short diagnostic line into those same hosting logs. It records a truncated network range rather than your full address: the first three groups of an IPv4 address, or the first four of an IPv6 one. We do this to tell a flood apart from a launch-day rush, and it is the basis on which the endpoint can be defended at all. The email address itself is never written to any log, at any level, in any field.

We note for completeness that our site's response headers include Referrer-Policy: no-referrer, which instructs your browser not to disclose the page you came from when it requests our assets or when you follow a link away from our site.

4.2 Analytics and performance measurement

The home page loads Vercel Web Analytics and Vercel Speed Insights. Both are first-party scripts served from our own origin; neither is a third-party tag, an advertising pixel or a tracker shared with any other website.

They are used to count page views and to measure how quickly the page renders — Core Web Vitals-style timings such as time to first byte and layout stability. The data sent is aggregate and non-identifying: the page path, the referrer category, the country, the device and browser type, and the performance timings themselves. Vercel documents both products as operating without cookies and without persistent cross-site identifiers.

The page you are reading now loads no scripts at all, including these — our legal pages are deliberately static HTML and CSS, so reading this policy is not itself measured.

If we later replace or supplement these products, this section will be updated before the change is deployed.

4.3 The launch-updates email list

The home page carries a single optional field, labelled "Subscribe for updates". If you type an email address into it and submit, we store that address so that we can tell you about Skanda Inc., its products, and its software. That is the entire purpose. Having an account is a separate thing; this list is optional and is not required to use the site or the App.

What we store

Two things: the email address, and the date and time it was submitted. Nothing else. We do not record your IP address, your user-agent, the page you came from, or anything else about the submission alongside it. We do not ask for your name, and there is no field in which you could give us one.

How it is stored

The address is encrypted before it is written down, with AES-256-GCM, and it is stored in that form and no other. Separately, a one-way keyed fingerprint of the address is used as its identifier, so that the list can recognise a duplicate signup without holding a readable address to compare against. The keys that reverse either operation are held in our hosting platform's secret store, never in the database itself, and are not interchangeable with one another.

The practical consequence, which is why it is built this way: if the database were copied by an attacker tomorrow, what they would have is a count, a list of timestamps and a block of ciphertext — not a mailing list. Addresses are made readable in one place only, on a company machine, by a person who has to hold the decryption key, and never by the website itself while serving a request.

Consent, and taking it back

We store the address on the basis of your consent — section 7. Consent is given by submitting the field and nothing else; there is no pre-ticked box, no bundling with any other permission, and nothing on this site is withheld from you if you never use it.

You can withdraw it at any time, and withdrawal is as easy as giving it was: use the one-click unsubscribe link carried by every email we send you, or write to support@skandarobotics.com from the address in question, or naming it, and we will erase it. We hold a tool for exactly this and it takes effect immediately — the ciphertext is deleted outright rather than flagged, so there is nothing left to recover afterwards. We will confirm when it is done. You do not have to give a reason, and we will not ask for one.

Because we have never yet sent a message to this list, there is at present no unsubscribe link for you to click — email us and it is done. From the first message we ever send, every message will carry a working one-click unsubscribe, and we will keep a minimal record of unsubscribes for the sole purpose of not contacting you again.

What we will not do with it

• We will not sell, rent, share or licence the list, to anyone, at any price.
• We will not use it for anything other than telling you about Skanda Inc., its products, and its software. If we ever want to use it for a materially different purpose, we will ask you first, separately.
• We will not enrich it — we will not look your address up against any other data set, infer an employer or a location from its domain, or attach anything to it.
• We will not use it to advertise to you on other platforms. It will not be uploaded to any advertising network as a custom or lookalike audience.

4.5 Your account

You do not need an account to read this site. You need one to use the App or to buy a plan.

What we store when you register

• Your email address. It identifies the account and is where we send codes, receipts and service notices.
• A hash of your password — never the password. Passwords are hashed with bcrypt by our authentication provider before storage, and the hash cannot be reversed into the password. Nobody at Skanda can read your password, including us.
• A display name, if you set one. Optional; you may leave it blank or use anything you like.
• Timestamps for when the account was created and last updated.
• A role flag, which is user for every account except the small number of company administrator accounts.

If you sign in with Google or GitHub instead

You may sign in with a Google or GitHub account rather than setting a password. If you do, that provider tells us your email address, and may tell us your display name and the URL of your profile picture; we store those three things and nothing else. We never receive your password for that service, and we do not gain access to your Google or GitHub account beyond confirming who you are. Because the provider has already verified the address, no six-digit code is sent in this case.

Signing in this way discloses to Google or GitHub that you are signing in to us. That disclosure is inherent to the mechanism. If you would rather they did not know, register with an email address and password instead.

What we record about how you use the account

Our servers hold a daily, per-model total of the work the App did for you — how many tokens were processed and what they cost. It exists so that we can show you your usage and enforce the limits of your plan. It is a count, not a copy. The content of your work — your prompts, your designs, your files — is not stored in that record.

What the App processes

This policy covers the App as well as the website. Once installed on your own computer:

• the App reads the design files you open on that computer;
• the App sends prompts to a model gateway — LiteLLM, running on Fly.io — and that gateway forwards each prompt to a model provider, which returns a completion;
• the App keeps local databases on your machine (session history and a local usage log). Those databases do not leave your computer. How long they last is a setting in the App, and it prunes files on your machine only — it cannot change what our servers hold. See section 10.

Some model providers offer a contractual "zero data retention" commitment. That commitment is contractual. It is not enforced in our code, and we cannot verify from here whether a provider keeps a copy of a prompt after returning a completion.

What we keep in order to defend the sign-in itself

Two small stores exist purely as security controls on the authentication path. Neither is used to profile you, and neither is joined to anything else.

• Rate-limit counters. So that nobody can grind at the sign-in form or flood an inbox with codes, we count recent attempts against three keys: your IP address, the surrounding network range (the first three groups of an IPv4 address, or the first four of an IPv6 one), and a keyed one-way fingerprint of the email address being used. The fingerprint is what lets us limit attempts against one account without holding a readable list of who is trying to sign in. Each counter expires by itself at the end of its window — minutes, not days. Counters used by our billing endpoints are held separately and swept nightly, one day after they are written.
• Device recognition. When you sign in successfully we store a record keyed by a one-way fingerprint of your user id and an opaque device identifier, holding the network range that device last signed in from. On the next sign-in we compare: a familiar device signs in normally, an unfamiliar one is challenged for an extra verification step. That is the entire purpose — it is what makes a stolen password insufficient on its own. The record deletes itself 90 days after it was last touched, and the matching cookie is described in section 5.

We would rather be exact than reassuring here: a keyed fingerprint of your email address is pseudonymous, not anonymous. We hold the key, so it remains personal data and we treat it as such — it is covered by every right in section 11. It is used this way, rather than storing the address itself, so that the store defending our sign-in is not also a readable list of our users.

Closing your account

Write to support@skandarobotics.com from the address on the account. We close the account, cancel any active subscription, and stop issuing a usable gateway credential. We do not hard-delete the profile, the subscription record, the daily usage totals or the gateway credential: those records are kept for the life of the record, including after the account is closed, and a closed account may still be used to collect data that arrives against it. Stripe retains its own transaction records for as long as financial-records law requires it to — see section 4.7 and section 10.

4.6 One-time codes sent by email

Registering with an email address and password requires you to prove the address is yours. We email you a six-digit code, and the account is not usable until you type it back. This is a security measure, not marketing: it stops somebody registering an account in your name and stops us sending mail to an address that was mistyped.

These are transactional messages. They carry no marketing, they have no unsubscribe link because there is nothing recurring to unsubscribe from, and they are sent only in response to something you just did. They are sent through Resend, named in section 8, which necessarily sees the recipient address and the message.

Codes are short-lived and single-use. We rate-limit them — five sends per address per five minutes, thirty verification attempts per network address per five minutes — so that the mechanism cannot be used to flood an inbox or to guess a code by brute force.

Being on the launch-updates list in section 4.3 and having an account are separate things. Creating an account does not add you to that list, and leaving that list does not affect your account.

4.7 Payments

Paid plans are billed by Stripe, and the single most important thing to say about it is this: your card details never touch our servers. When you choose a plan, we ask Stripe for a one-time checkout link and send you to it. You enter your card on a page Stripe serves, under Stripe's own domain. We never see, receive, transmit or store a card number, an expiry date or a security code, and there is no code in this website capable of accepting one.

What we store, once Stripe tells us a subscription exists:

• Stripe's customer identifier and subscription identifier for you — opaque strings such as cus_… and sub_…;
• which plan you are on, and whether it is active, past due or cancelled;
• the date the current billing period ends, so the App can show you when your allowance resets;
• the identifier of each Stripe notification we have already processed, so that a repeated notification does not charge or credit you twice.

Stripe holds the rest — your card, your billing address, your invoices, your payment history — as a controller in its own right for those purposes, not merely as our processor, because payments law requires it to. Its handling of that data is governed by Stripe's own privacy policy at stripe.com/privacy. Managing your payment method, downloading an invoice or cancelling a subscription all happen in Stripe's Customer Portal, which we open for you from your account page.

Stripe applies its own fraud screening to a payment. That is a decision Stripe makes, on Stripe's data, and we are told only whether the payment succeeded.

4.8 Bot protection on the account page

The account page runs Cloudflare Turnstile, a bot check that replaces the puzzles other sites make you solve. It exists because a sign-in form and a registration form left unguarded are ground down by automated scripts within days — credential stuffing on one, mass account creation on the other.

To decide whether you are a person, Turnstile runs checks in your browser and sends the result to Cloudflare. Cloudflare describes the data involved as limited to what is strictly necessary for that purpose, and states that Turnstile does not access, store or transmit user communications, form entries or other page inputs — it never sees your email address or your password. Cloudflare acts as our processor for this, and separately relies on its own legitimate interests in improving how well the check works.

We run Turnstile with pre-clearance enabled. In that mode it returns a one-time token to our page and sets Cloudflare's cf_clearance cookie, by a fetch to a /cdn-cgi/ endpoint on our own origin. That is why our connect-src directive stays 'self' — the clearance request does not go to a third-party host. cf_clearance is a strictly necessary security cookie; it is listed in section 5. This site shows no cookie banner: under the ePrivacy rules that govern cookies, strictly necessary cookies do not require consent.

The check runs on the account page only. Every other page on this site — including the one you are reading — loads nothing from Cloudflare at all.

4.4 What we do not collect

To be unambiguous, this site does not:

• set any advertising, analytics, retargeting or cross-site cookie — the only cookies are the four strictly necessary ones in section 5 (our three, plus Cloudflare's cf_clearance in pre-clearance mode), and they are set on the account page only;
• collect your name, telephone number or postal address — the only name we hold is a display name you chose to type, and the only address we hold is an email address;
• receive, transmit or store your card details, which go to Stripe directly — see section 4.7;
• load fonts, images or stylesheets from any other domain. The one third-party resource anywhere on this site is the Cloudflare Turnstile widget on the account page — see section 4.8;
• run advertising, retargeting, session recording, heatmapping, fingerprinting or A/B testing tools;
• request access to your location, camera, microphone, clipboard or any other device sensor. Our Permissions-Policy header affirmatively denies these to our own page, including the payment API — payment happens on Stripe's site, not inside ours.

5. Cookies and similar technologies

The public pages of this site — everything except the account page — set no cookies at all, and write nothing to your browser's storage. Reading this policy is not recorded.

The account page sets four cookies, and we name them below rather than describing them in categories. All four are strictly necessary: each exists solely to deliver a service you explicitly asked for — being signed in, and being signed in safely — and none of them tracks you, profiles you, or is shared for advertising. Under the ePrivacy rules that govern cookies, strictly necessary cookies do not require consent, which is why this site shows you no cookie banner. We would rather list them than assert the conclusion:

Our three cookies — __Host-skanda_session, __Host-skanda_device and __Host-skanda_oauth — carry the same attributes — HttpOnly, Secure, SameSite=Lax, Path=/, and the __Host- prefix — and every one of those is in your favour rather than ours:

• HttpOnly — no JavaScript running on the page can read any of them. Even a script that somehow got itself injected into this site could not read your session out of the cookie.
• The __Host- prefix — not decoration, but a guarantee your browser enforces for us. A cookie carrying this prefix is refused outright unless it is Secure, scoped to Path=/, and has no Domain attribute. So none of these can be set over plain HTTP, and none can be set or read by a subdomain: a compromise of some other host under our domain could not plant a session on this one.
• SameSite=Lax — another site cannot cause your cookies to be sent by a form post or a background request. We use Lax rather than the stricter Strict for one specific engineering reason, not to loosen anything: the return leg from Google or GitHub is a cross-site top-level navigation back to us, and Strict would withhold the cookie exactly when it arrives, breaking the sign-in it exists to protect.

None of the four is an advertising, analytics or tracking cookie, none is set before you visit the account page, and none is used to profile you. cf_clearance is placed by Cloudflare as described above; the other three are ours.

A 90-day cookie is a long-lived one, and "strictly necessary" is a test worth showing our working on rather than asserting. The exemption covers a cookie essential to providing a service the user has explicitly requested. You asked to sign in; the step-up check that __Host-skanda_device enables is part of signing you in safely, and removing it would not make the service less convenient, it would make it less secure for you. It measures nothing, follows you nowhere, and its lifetime is set by how long a device stays recognisable rather than by how long we would like to observe you. That is why it is in this table and not behind a consent prompt. If you disagree, delete it — you will simply be asked for an emailed code more often.

You can delete all four at any time in your browser's settings. Deleting __Host-skanda_session signs you out; deleting cf_clearance may mean the bot check runs again; deleting the other two costs you nothing but an extra verification step.

If we ever want to set a cookie that is not strictly necessary, we will, before it is set: publish an updated version of this policy listing the cookie, its purpose, its provider and its lifetime; and obtain your prior opt-in consent, through a mechanism that makes refusing at least as easy as accepting.

6. Processing that is not yet active

This section describes processing we anticipate as the company launches. Except where a subsection says otherwise, none of it is in effect today. Each item will only begin once the corresponding feature is actually deployed, and this policy will be updated with a new "last updated" date at that point. It is set out in advance so that the policy's scope is honest about the direction of travel rather than being quietly widened later.

6.1 Contact and enquiry forms

If we add a contact form or publish an enquiry address, we would process the identifiers and message content you choose to send — typically name, email address, organisation and the substance of your enquiry — for the purpose of answering you and keeping a record of the correspondence. We would not use an enquiry as a basis for marketing to you without separate consent.

6.2 Recruitment and careers

If we open applications, we would process the information in your application: contact details, curriculum vitae, work history, education, right-to-work or visa status where legally necessary, references, interview notes and the outcome. The purposes would be assessing your suitability, running the hiring process, and meeting employment-law record-keeping obligations.

Unsuccessful applicants' data would be retained for a defined period so that we can consider you for future openings and answer any challenge to the process, and then deleted. Special category data (for example, health information supporting an accommodation, or diversity monitoring data) would be handled separately, on an explicit-consent or employment-law basis, kept apart from the assessment record, and never used as a selection criterion.

6.3 Accounts, products and customer relationships

This is now live and has moved. Accounts, payments and the data our servers hold about your use of the application are described in sections 4.5 to 4.8 and are in effect today. This subsection is kept only so that links to it still resolve.

What remains anticipated rather than active: a support desk with its own ticket history, and telemetry from any physical hardware we may later ship. Robotic and sensor data deserves particular care because it can incidentally capture people and premises. Either will be documented here before it ships.

6.4 Sending to the email list

The list itself is active and is described in section 4.3 — this subsection is only about the part that has not started yet.

We have not sent a single message to it. Doing so requires an email delivery provider, which we have not engaged for this list; when we do, it becomes a processor holding a copy of the list, it will be named in section 8, and that will happen before the first message goes out rather than after. Every message will carry a working one-click unsubscribe from the first one onward. We will not use the list for advertising, and we will not sell, rent or share it.

7. Legal bases for processing

Where the GDPR or a comparable regime applies, we rely on the following bases. The first four are currently engaged.

Legitimate interests — Article 6(1)(f)

In effect now. Our interest, and yours, in the website being available, being served correctly, and being defended against attack and abuse. This is the basis for the hosting logs in section 4.1, the aggregate measurement in section 4.2, and the truncated network ranges we record when the subscribe endpoint refuses a request. We consider the impact on you minimal: the data is technical, not enriched, not used to make decisions about you, and not combined into a profile. You may object under section 11.1. It is also the basis for the bot check in section 4.8, and for the rate-limit counters and the device-recognition record in section 4.5: our interest, and every honest user's interest, in the sign-in and registration forms not being ground down by automated scripts, and in a stolen password not being enough on its own. The alternative — a puzzle for every visitor, or no step-up check at all — is worse for you, not better. We have weighed the impact and consider it minimal: the data is a fingerprint and a network range, it is not enriched, not used to make decisions about you beyond "challenge this sign-in or not", and not combined into a profile. You may object under section 11.1.

Consent — Article 6(1)(a)

In effect now. This is the basis for the email list in section 4.3, and the only thing it covers. Consent is given by submitting the field, freely and with no consequence for declining; it is specific to being told about Skanda Inc., its products, and its software, and is not bundled with anything else. It can be withdrawn at any time, as easily as it was given, using the unsubscribe link in any email we send you, or by writing to support@skandarobotics.com — without affecting the lawfulness of processing before withdrawal. It will also be the basis for non-essential cookies and any other optional feature we ask you to opt into, none of which exist today.

Performance of a contract — Article 6(1)(b)

In effect now. This is the basis for your account and for anything you buy from us: creating and maintaining the account described in section 4.5, verifying your address so the account can exist at all (section 4.6), taking payment and keeping your plan and renewal date current (section 4.7), and metering your usage against the allowance the plan gives you. It also covers steps taken at your request before you enter a contract, such as registering an account before choosing a plan. It is also the basis for the App reading the files you open, sending prompts through the model gateway, and keeping local databases on your machine, all of which are part of delivering the service you asked for.

Legal obligation — Article 6(1)(c)

In effect now, in one respect. Tax and financial-records law requires that a record of a payment be kept for a set number of years, so a paid transaction cannot simply be erased on request; that record sits mainly with Stripe. Otherwise this basis is not yet engaged. It would also apply to responding to a lawful and properly-scoped order from a competent authority.

Vital interests and public task — Article 6(1)(d) and (e)

We do not anticipate relying on either. They are listed only for completeness.

Under the DPDP Act, processing is generally grounded in consent or in a "legitimate use" defined by that statute. The mapping between the bases above and the DPDP Act's categories requires confirmation by counsel — see the notice at the top of this page.

8. Third parties and processors

We do not sell personal information, and we do not "share" it for cross-context behavioural advertising as those terms are defined under the CCPA/CPRA. We have never done so and have no plan to.

The following organisations form our infrastructure. For each we state what it does, what personal data it receives, and where it is. All of them are engaged under a written data processing agreement unless stated otherwise.

Vercel Inc. — hosting, content delivery, analytics · United States

Serves every page and asset of this site and supplies the measurement products in section 4.2. Our processor. Receives the connection metadata in section 4.1. Privacy policy at vercel.com/legal/privacy-policy; data processing terms at vercel.com/legal/dpa.

Supabase, Inc. — account authentication and application database · United States, with the database in AWS us-west-2 (Oregon, United States) as named in section 9

Holds the account data in section 4.5: your email address, your password hash, your display name, your avatar URL, your plan record and your daily usage totals. Runs the sign-in, the six-digit code check and the Google and GitHub handovers. Our processor. Privacy policy at supabase.com/privacy; data processing addendum at supabase.com/legal/dpa.

Stripe, Inc. — payments and subscription billing · United States, with Stripe Payments Europe Ltd. in Ireland for European payments

Takes the payment described in section 4.7. Receives your email address, your card details (directly from you, never through us) and your billing address. Acts as our processor for the subscription record and as a controller in its own right for the payment itself and for the records payments law obliges it to keep. Privacy policy at stripe.com/privacy; data processing agreement at stripe.com/legal/dpa.

Cloudflare, Inc. — bot protection (Turnstile) on the account page · United States, served from Cloudflare's global network

Runs the check in section 4.8. Receives your IP address and the technical signals the check produces. Cloudflare states that Turnstile does not access, store or transmit form entries, so it never receives your email address or password. Our processor, and separately a controller for improving the check itself. Turnstile privacy addendum at cloudflare.com/turnstile-privacy-policy.

Upstash, Inc. — the launch-updates email list, and the rate-limit and device-recognition stores that defend sign-in · United States, multi-region database with its primary in the Asia-Pacific region

Our processor, in two distinct roles.

The launch-updates email list in section 4.3. What it stores on our behalf is ciphertext: the encryption and fingerprinting keys live in Vercel's secret store, not in the database, so Upstash's own staff and infrastructure never hold a readable address.

The security stores behind our own /api/auth/ endpoints, described in section 4.5. These are separate from the account database at Supabase and hold no profile, no password hash and no readable email address. What Upstash receives for this role, and nothing beyond it, is:

• a keyed one-way fingerprint of an email address — pseudonymous, not anonymous, since we hold the key;
• an IP address and the surrounding network range (IPv4 /24, IPv6 /64);
• an opaque device identifier and a one-way fingerprint of the user id it belongs to;
• request counts and timestamps — when a sign-in, registration or code request was attempted, and how many there have been in the current window.

Rate-limit entries expire at the end of their own window, in minutes. Device records carry a 90-day time-to-live and delete themselves. Privacy policy at upstash.com/trust/privacy.pdf; data processing addendum at upstash.com/trust/dpa.pdf.

Resend, Inc. — delivery of one-time codes · United States

Delivers the six-digit codes in section 4.6, and any service notice we send about your account. Receives your email address and the message. Our processor. It is not given the launch-updates list. Privacy policy at resend.com/legal/privacy-policy.

Fly.io, Inc. — the model gateway that the App talks to · United States

Runs the LiteLLM model gateway that the App sends prompts through. Receives the prompt text you submit in the App, and the credentials that identify your account to the gateway. Our processor. The gateway then forwards the prompt to the model provider selected for that request. Privacy policy at fly.io/legal/privacy-policy.

Model providers reached through the gateway · locations vary by provider

Receive the prompt the App sent, so they can return a completion. Each acts as our processor for that request, under that provider's terms. Some providers offer a contractual "zero data retention" commitment — they agree not to keep the prompt after returning the completion. That commitment is contractual. It is not something our code can enforce or verify. We do not independently audit whether a provider keeps a copy. A provider's own privacy policy governs what it does with a prompt once it has received it.

GoDaddy — domain registration · United States

Registrar of the skandarobotics.com domain. This is a relationship about the domain name, not about you: a registrar does not receive your browsing activity by virtue of that role. Where the domain also uses GoDaddy's nameservers, the DNS lookups that resolve our hostname pass through their infrastructure. Privacy notice at godaddy.com/legal/agreements/privacy-policy.

three.js — vendored, no data flow

The home page's 3D scene uses the three.js library, which is MIT-licensed and served from our own origin rather than a CDN. No request is made to the three.js project or to any CDN, so no third party learns of your visit through it. See section 8.2 of our Terms.

We may in future engage further processors — an email provider, a customer support tool, an applicant tracking system, a payment processor. Where we do, we will put a written data processing agreement in place requiring the processor to act only on our documented instructions, to apply appropriate security, to assist us with data subject requests, and to delete or return the data at the end of the engagement. We will update this list.

Separately from processors, we may disclose personal data where we are compelled to by a valid legal process, where it is necessary to establish, exercise or defend a legal claim, or to protect the rights and safety of any person. Where we are lawfully able to notify you of such a demand, we will.

9. International transfers

Our infrastructure providers operate globally, so personal data may be processed in a country other than your own, including the United States. Two categories are involved: the connection metadata described above, and the email list, which is held in a multi-region database whose primary is in the Asia-Pacific region and which replicates between regions to serve requests quickly.

Account data adds further paths. The account database is hosted by Supabase in AWS us-west-2 (Oregon, United States). One-time codes are delivered by Resend in the United States. The payment record sits with Stripe in the United States, with European payments routed through Stripe Payments Europe Ltd. in Ireland. The bot check in section 4.8 is answered by whichever Cloudflare edge location is nearest to you, which may be in your own country or in another.

The App adds another path: prompts leave your machine for the LiteLLM gateway running on Fly.io, and from there to the model provider that will complete them. Those providers operate globally; a prompt may be processed in the United States or in another country the provider uses.

Supabase's, Stripe's and Cloudflare's data processing terms each incorporate the European Commission's Standard Contractual Clauses, as Vercel's and Upstash's already do.

It is worth being concrete about what actually crosses a border in the case of the list, because it bears directly on the risk: what replicates is the encrypted form of the address. The keys that would turn it back into an address are held in a separate system, in Vercel's secret store, and are not replicated with it. A demand served on the database operator in any jurisdiction, or an interception of the traffic between regions, reaches ciphertext rather than a mailing list.

Under the DPDP Act, transfers outside India are permitted except to territories the Central Government restricts by notification. We will comply with any such notification as it is issued.

You may request details of the specific safeguards applied to any transfer using the contact details in section 16.

10. How long we keep things

The email list in section 4.3 has no CRM, no profile and no history attached to it — a stored address is an address and a submission date, nothing more. Account records are kept as set out below.

An address on the email list

Kept until the earliest of three things: you withdraw consent or ask us to delete it, in which case it goes immediately; you unsubscribe from a message once we begin sending them; or 24 months pass from the date you gave it without us having launched. That last limit exists so that an address cannot sit in our database indefinitely on the strength of a consent given for an event that never happened. If we reach it, we delete the list rather than quietly holding it.

A record that you unsubscribed

Kept for as long as we run the list. It is the minimum needed — the address, and the fact that it opted out — and it exists for one purpose: so that we do not contact you again by re-importing you from somewhere else. Retaining it is what makes your opt-out durable. You can ask us to delete this too, understanding that it removes the suppression along with it.

Your account — profile, plan and gateway credential

Kept for the life of the record, including after the account is closed. Closing the account does not erase these. A closed account may still be used to collect data that arrives against it.

Daily usage totals

Kept for the life of the record, including after the account is closed. These are counts and costs per day and per model; they contain none of your work.

Rate-limit counters on our own sign-in endpoints

Each counter expires by itself at the end of the window it measures — minutes. Nothing sweeps them because nothing needs to: the store discards them when their time-to-live runs out.

Device-recognition records

90 days from the last sign-in on that device, enforced by a time-to-live on the record itself rather than by a job that has to remember to run. Sign in again from the same device and the 90 days restart; do not, and the record is gone.

Rate-limit counters on our billing endpoints

Held separately, in the account database. Swept nightly; a counter is gone one day after it is written.

Processed Stripe notification identifiers

Kept for 90 days for replay protection, then discarded. These are Stripe's event identifiers, not a copy of the payment.

Payment records

Held by Stripe under Stripe's own schedule, which is driven by financial-records and tax law rather than by us. Closing your account does not erase Stripe's records, and we would rather say so than let you discover it. On our side, the subscription record is kept for the life of the record, including after close; the processed-notification identifiers are kept for 90 days.

Hosting and analytics records — section 4

Retained by Vercel under Vercel's own retention schedule, not one we set. Analytics data is aggregated rather than kept as individual event records tied to a person.

The App offers two retention settings of its own — how long to keep session history, and how long to keep the local usage log. Those settings prune files on your own computer. They do not, and cannot, change what our servers hold; the periods above are the ones that govern us.

Deletion here means deletion: the stored ciphertext is removed outright rather than marked inactive, and because it is the only copy, the address is not recoverable afterwards by us or by anyone who later obtains the database. Backups, if and when we introduce them, will be covered by a stated schedule in this section before they exist.

For any category of personal data we begin holding in future, the principle is that it is kept only as long as it serves the purpose it was collected for, or as long as the law requires it to be kept, whichever is longer, and is then deleted or irreversibly anonymised. Concrete periods will be published here at that time.

11. Your rights

Your rights depend on where you live and which law applies to you.

In practice there are two questions we can almost always answer immediately: whether your address is on the email list, and whether you have an account. If you never submitted an address and never created an account, we hold nothing about you that we can look up by name, and a confirmation to that effect is a valid and complete response. If you did either, we can tell you what we hold and give you a copy. The list can be deleted on request. Closing an account is described in section 4.5 and section 10.

11.1 GDPR and UK GDPR

If you are in the EEA, the UK or Switzerland, you have the right to:

Access

Obtain confirmation of whether we process your personal data, a copy of it, and information about how and why it is processed.

Rectification

Have inaccurate personal data corrected and incomplete data completed.

Erasure

Have your personal data deleted where one of the statutory grounds applies — often called the "right to be forgotten".

Restriction

Have processing paused rather than deleted, for example while an accuracy dispute is resolved.

Portability

Receive personal data you gave us, where processing is based on consent or contract and is automated, in a structured, commonly used, machine-readable format, and have it transmitted to another controller where technically feasible.

Objection

Object to processing based on legitimate interests, on grounds relating to your particular situation. You may object to direct marketing at any time, absolutely and without needing to give a reason.

Withdrawal of consent

Withdraw any consent at any time, without affecting the lawfulness of processing carried out before you withdrew it.

Complaint

Lodge a complaint with a supervisory authority — normally the one in your country of residence, place of work, or where the alleged infringement occurred. You do not need to contact us first, though we would like the chance to put things right.

11.2 California — CCPA and CPRA

If you are a California resident, you have the right to:

• Know what categories and specific pieces of personal information we have collected, the sources, the business purpose, and the categories of third party we disclose to.
• Delete personal information we have collected from you, subject to the statutory exceptions.
• Correct inaccurate personal information.
• Opt out of the sale or sharing of personal information. We do not sell or share personal information, so there is currently nothing to opt out of and no "Do Not Sell or Share My Personal Information" link is required. We honour Global Privacy Control signals as an opt-out for any future processing that would qualify.
• Limit the use and disclosure of sensitive personal information. We collect account log-in information in combination with a password (or equivalent credentials). That combination is sensitive personal information under the CPRA. We use it solely to authenticate the account holder — an enumerated exempt purpose under California Civil Code §1798.121(a) — and for no other purpose. Because that is the only use, no "Limit the Use of My Sensitive Personal Information" link is required.
• Non-discrimination — we will never deny you service, charge you a different price, or give you a lower quality of service because you exercised a privacy right. We operate no financial incentive programme.

An authorised agent may make a request on your behalf with proof of authorisation. We will verify requests proportionately to the sensitivity of the data involved.

11.3 India — Digital Personal Data Protection Act, 2023

The DPDP Act uses its own vocabulary. If you are a Data Principal — the individual the data relates to — and we are acting as a Data Fiduciary, you have the right to:

• Access information about the personal data we process, a summary of the processing, and the identities of other Data Fiduciaries and processors with whom it has been shared.
• Correction, completion, updating and erasure of your personal data.
• Grievance redressal — a readily available means of raising a complaint with us, which we must answer within the period prescribed by the Act and its rules, before you escalate to the Data Protection Board of India.
• Nominate another individual to exercise your rights on your behalf in the event of your death or incapacity.

The Act also contemplates a Consent Manager — an entity registered with the Data Protection Board through which you may give, manage, review and withdraw consent from a single accessible point. We are not registered with, and do not operate through, any Consent Manager. Our one consent-based processing activity is the email list, where consent is given by submitting the field and withdrawn through the unsubscribe link in any email we send you, or by writing to support@skandarobotics.com; we will say here if that ever changes or if a Consent Manager becomes available to you.

The DPDP Act also imposes duties on Data Principals — for example, not to raise false or frivolous grievances — and provides for penalties. The precise application of the Act and its rules to a company of our size and stage, including whether we fall to be classified as a Significant Data Fiduciary, requires confirmation by counsel and is flagged in the notice at the top of this page.

11.4 How to exercise a right

Write to support@skandarobotics.com, saying which right you wish to exercise. Please give us enough information to find any records that concern you.

• We will acknowledge promptly and respond substantively within one month, or within the shorter period any applicable law requires. Where a request is genuinely complex we may extend by up to two further months and will tell you why within the first month.
• Exercising a right is free. We may charge a reasonable fee, or decline, only where a request is manifestly unfounded or excessive — and we will explain our reasoning if we ever do.
• We may ask you to verify your identity before we act on a request, so that we do not disclose data to the wrong person. We will not use anything you send for verification for any other purpose, and we will delete it afterwards.
• To close your account, write from the address on the account and say so. We do not require a form, a reason or a notice period. If you have an active paid plan, tell us whether to cancel it immediately or let it run to the end of the period you have already paid for. Closing the account does not hard-delete the profile, the subscription record, the daily usage totals or the gateway credential — see section 10.

12. Automated decision-making

We do not carry out automated decision-making that produces legal or similarly significant effects concerning you, and we do not profile you. Should that change — for example, automated screening in a hiring process — we would tell you before it began, explain the logic involved and the consequences envisaged, and provide the right to obtain human intervention, to express your point of view and to contest the decision.

13. Children's privacy

This site and our application are professional engineering tools. They are not directed at children, are not attractive to children in any commercial sense, and we do no tracking, profiling or advertising of any kind, to anyone. You must be old enough to enter a binding contract to hold an account — see section 4 of our Terms.

We do not knowingly collect personal data from a child. We do not demand documentary proof of age at registration, because doing so would mean collecting far more personal data from every user than holding an account otherwise requires; instead we state the requirement in the Terms and act on any report. If you believe an account or an address on our list belongs to a child, tell us and we will delete it without requiring you to prove anything further. Age thresholds differ by jurisdiction, and we apply the highest one that applies to a given individual:

• Under the GDPR, the age of consent for information society services is between 13 and 16 depending on the member state.
• Under the US Children's Online Privacy Protection Act, the threshold is 13.
• Under India's DPDP Act, the threshold is 18. The Act requires verifiable consent from a parent or lawful guardian before processing a child's personal data, and prohibits tracking, behavioural monitoring and targeted advertising directed at children outright. We do none of those things to any visitor.

If you believe a child has provided us with personal data, contact us at support@skandarobotics.com and we will act on it.

14. Security

We would rather describe the measures that actually exist than list generic assurances. As of the date at the top of this page, the site is protected by:

• Encryption in transit. The site is served exclusively over HTTPS with modern TLS. The upgrade-insecure-requests directive rewrites any incidental insecure request.
• Encryption at rest, of the email list. Every address on the email list is sealed with AES-256-GCM before it is written, and is held only in that form. Its identifier in the database is a one-way keyed fingerprint rather than the address itself, so duplicate signups can be recognised without a readable address existing anywhere in storage. Three separate keys are used — one to fingerprint, one to encrypt, one to sign the anti-automation token on the form — so that compromising one does not compromise the others. None of them is held in the database; they live in our hosting platform's secret store. The website can add an address to the list but has no ability to read one back: decryption happens only on a company machine, deliberately, by a person holding the key.
• The address is never logged. No email address is written to any log, at any level, in any field, including in error reports. Logs are a second copy with a different retention period and a wider audience, and putting the list into them would quietly undo the encryption described above.
• Abuse resistance on the subscribe path. The subscribe endpoint is rate limited per address-range and in aggregate, requires a short-lived single-use token issued by us, and rejects submissions completed faster than a person could type. It answers identically whether an address is new or already on the list, so it cannot be used to test whether a particular person subscribed.
• HTTP Strict Transport Security. An HSTS header with a one-year max-age and includeSubDomains, so that after your first visit your browser refuses to talk to us over plain HTTP at all.
• A strict Content Security Policy. The policy starts from default-src 'none' and permits scripts, styles and images only from our own origin. There is no CDN, no third-party tag manager and no remote font to be compromised. The single exception is the bot check on the account page, which is permitted to load from challenges.cloudflare.com and from nowhere else — and that permission is granted on the account page alone, not site-wide. The policy ships both as an HTTP header and as a <meta> tag, so it holds even on a host that drops the header.
• Clickjacking protection. frame-ancestors 'none' together with X-Frame-Options: DENY.
• Isolation and sniffing defences. X-Content-Type-Options: nosniff, and Cross-Origin-Opener-Policy and Cross-Origin-Resource-Policy both set to same-origin.
• Referrer suppression. Referrer-Policy: no-referrer.
• Capability denial. A Permissions-Policy header that switches off camera, microphone, geolocation, USB, payment, display capture and motion sensors for our own page.
• Passwords we cannot read. Passwords are hashed with bcrypt by our authentication provider before they are stored. We hold the hash, never the password, and the hash cannot be turned back into it. Sign-in attempts and code sends are both rate limited, so a stolen password list from somewhere else cannot be tried against us at speed.
• Short-lived sessions. Access tokens last fifteen minutes and are refreshed with a rotating refresh token, so a token captured somewhere it should not have been is useful for minutes rather than months. The session cookie is HttpOnly, Secure and SameSite=Lax.
• A step-up check on unfamiliar devices. A successful sign-in leaves a 90-day device record — section 5 — so that a sign-in attempt from a device we have never seen can be challenged for extra verification. This is the control that makes a password stolen from somewhere else insufficient on its own. The store holds an opaque device identifier and a network range, never a readable email address.
• Card details we never hold. Payment happens on Stripe's own pages. There is no code path in this website capable of receiving a card number, which is a stronger guarantee than any promise to store one carefully.
• Row-level isolation. Every account row in our database carries a policy that lets it be read only by the account it belongs to. Signing in as yourself does not give you a route to anyone else's record, even through a bug in our own code.
• Minimisation as architecture. The strongest measure here remains structural. We ask for an email address and a password because signing you in requires them, and we do not ask for a name, a phone number, a company, a card number or a postal address, because none of those is required. Data that is never collected cannot be breached, leaked or misused.

No system is perfectly secure, and we do not claim otherwise. If we ever suffer a personal data breach that is likely to result in a risk to your rights and freedoms, we will notify the competent supervisory authority within 72 hours of becoming aware of it where the law requires, and notify affected individuals without undue delay where the risk is high.

If you believe you have found a security vulnerability in this site, please report it to support@skandarobotics.com. We will not pursue legal action against anyone who reports a genuine issue in good faith, gives us reasonable time to fix it, and does not access or destroy data belonging to others.

15. Changes to this policy

This policy will change as the company grows — that is expected, and section 6 exists so that the direction of change is visible in advance rather than sprung on you.

When we change it, we will update the "last updated" date at the top of this page. Where a change is material — a new category of data, a new purpose, a new recipient, or a change in the legal basis we rely on — we will make that clear rather than relying on the date alone, and where the law requires your consent for the new processing we will ask for it before the change takes effect. Continuing to use the site after a purely clarifying change indicates acceptance of the updated policy.

Previous versions are available on request from support@skandarobotics.com.

16. Contact

Privacy enquiries and data subject requests

support@skandarobotics.com. The site carries no contact form; email, or post to the address below, is the channel for anything other than leaving the email list.

Leaving the email list

Use the one-click unsubscribe link in any email we send you. It takes effect immediately and needs no correspondence with us.

Data protection officer / grievance officer

None appointed. Enquiries are handled by the officers of the company.

Postal address

Skanda Inc., 141 Highway 41, Suite B, Ringgold, GA 30736, United States

EU / UK Article 27 representative

Vihaan Shah, appointed as the EEA representative and as the UK representative, reachable at support@skandarobotics.com. Correspondence may also be sent to our principal place of business at 141 Highway 41, Suite B, Ringgold, GA 30736, United States.

Questions about the website's terms of use rather than privacy are answered in our Terms and Conditions.