Privacy Policy

TDACorp Private Limited ("TDACorp", "we", "us") runs this website. This notice says what tdacorp.in collects, why we hold it, which services touch it and how long it stays. It is written from the code that runs the site rather than from a template, which is why it names services instead of gesturing at third parties.

It covers this website only. Work done under an engagement is governed by the agreement signed for it: infrastructure runs in your accounts and source lives in your repositories, so your product's data does not pass through anything listed here.

The longer version of the same answers, written for a security review and service by service, is published at /trust. The two were written from the same code and do not disagree.

Three things, and this is the whole list:

• What you type into the contact form: Six fields, and only six: your name, your email address, your company, the type of enquiry, the budget range you pick, and your message. Company and budget can be left empty. Nothing else on the page is read, and there is no hidden field carrying anything about you.
• The request that serves you a page: Our host records ordinary server-log detail: the path, your browser's user agent, the edge region, the response status and the timing, and it can match a request back to the IP address it came from. That is what serving a website produces, and we do not build it into a profile.
• How fast the page rendered: One measurement script, described in its own clause below. It records the route and URL, connection speed, browser, device type and operating system, your country, the performance figure itself and which element it is attributed to.

There is no visitor account and no login. We hold no advertising identifier, no cross-site history, no location finer than the country the timing script records, and nothing bought or enriched from anybody else.

• To answer you: Your submission is held to reply to it and to run the conversation it starts. The basis is the step you asked us to take before any contract exists: you sent an enquiry so that it would be read.
• To serve and defend the site: Request records exist so pages can be delivered, faults can be traced and abuse can be stopped. The basis is our legitimate interest in the site working and staying up.
• To keep it fast: Page timing is measured so slow pages can be found and fixed. The basis is the same legitimate interest, and the measurement is anonymous, which is the whole reason it is acceptable on that basis.
• Not for marketing, and not for profiling: No page on this site captures an address for a mailing list, no newsletter is sent, and nothing here profiles you or makes an automated decision about you. If a mailing list is ever added it will ask first and this notice will change before it does.

TDACorp is registered in India, so the Digital Personal Data Protection Act, 2023 governs this processing. Where you are covered by the UK or EU GDPR, the bases named above are the ones we rely on under it, and the rights clause below applies to you in full.

Every service that touches data from this site is named here, with what it actually holds. A notice that says third-party services may be used answers nothing a reader asked.

• Supabase: Holds the contact form. Your browser posts straight to a Supabase function, which writes one row carrying the six fields plus the arrival time and a read flag. The key your browser carries can insert a row and nothing else: no read, no update, no delete, enforced by the database rather than by the page.
• Google, over Gmail SMTP: Relays the mail. The same function sends a notification carrying your submission to our mailbox, and a confirmation to the address you entered. The confirmation is a fixed template that contains none of your text.
• Vercel: Serves the site and keeps the request records described above. Every public page is built ahead of time and served as a file, so opening one runs no query. What you type into the form does not reach Vercel: that request goes from your browser to Supabase and never passes through this site's server.
• Vercel Speed Insights: Measures page timing, and is the only measurement script on the site. Its own clause is below.
• Cal.com: Handles booking, and only if you book. Book a call is a plain link out rather than an embedded widget, so nothing from cal.com runs here and nothing is sent there by reading a page. What you enter on their form you hand to them directly.

Nobody else receives anything. Data from this site is not sold, not rented, not traded, and not handed to anybody for their own purposes. It would be disclosed if a law or a valid legal order required it, and that has not happened.

No public page of this site sets a cookie or writes to browser storage. There is no consent banner because there is nothing to consent to. The one cookie the codebase sets belongs to the password-gated dashboard we read enquiries in: it is issued only after somebody signs in there, and reading a public page never produces one.

No script from another origin can run here at all. The Content-Security-Policy sent with every response allows scripts from this origin only, and it is a response header you can check yourself rather than a claim you have to accept.

Vercel Speed Insights is mounted on every route and is served from this domain, at /_vercel/speed-insights/script.js. Vercel's published documentation for it lists exactly the values recorded, and states that the recording is anonymous, that it is not tied to or associated with any individual visitor or IP address, and that it does not store information that would let a browsing session be reconstructed across pages or a user be identified.

Vercel makes no cookie claim for Speed Insights in either direction, so neither do we. What we can state: the package we install carries no cookie or browser-storage access anywhere in its code, and the script it loads is Vercel's own and has not been audited by us. If you would rather it did not run, block that one path. Nothing on this site depends on it.

• Your submission: There is no automatic expiry: no retention job, no time to live, no scheduled purge. A row stays until it is deleted by hand from the dashboard. We deliberately do not publish a fixed retention window, because a period with nothing enforcing it would be a control that does not exist.
• The emails: The notification and the confirmation are ordinary email, so a copy of your message rests in a mailbox outside the database. Deleting the row does not delete those, which is why the request below covers both when you ask it to.
• Request records: The server logs are our host's, kept on the retention schedule of the plan the site runs on rather than one we set. We do not copy them anywhere or keep our own.
• Deleting it on request: Write from the address you used and the row goes, along with the emails if you say so. There is no form and no portal: hello@tdacorp.in reaches the person who can action it.

One hosted Postgres project, in a single region, holds the submissions table. The region is a deployment setting rather than a fact of this page, so it is confirmed in writing on request and named in a data processing agreement, where it binds instead of merely being printed.

The site itself is served from a global edge network and carries nothing of yours, because the pages are static files. Email is the exception worth stating plainly: it travels over Gmail's infrastructure and then rests in mailboxes, so a copy of your message exists outside the database and outside any one region. If something should not sit in an inbox, raise it on a call rather than in the form.

Whatever your jurisdiction gives you, these are honoured here:

• A copy of what we hold about you, which is the row and the emails
• Correction of anything in it that is wrong
• Deletion of it, including the mailbox copies when you ask for those too
• Objection to the processing that rests on our legitimate interest, and withdrawal of anything you gave us voluntarily
• A complaint to your data protection authority, without asking us first

Write to hello@tdacorp.in from the address you used. We will not ask you for more identification than the request needs, and there is no charge.

The specifics rather than the adjectives: the key your browser carries can only insert, enforced by row-level security in the database; the key that can read is server-side and never sent to a browser; the dashboard that reads enquiries is password-gated and excluded from search engines; and every response ships a content security policy, strict transport security and the rest of the header set.

None of that makes transmission over the internet perfectly secure, and we are not going to claim it does. The engineering practices behind these are published in full at /security, along with where to report something you find.

The date at the top is the date this was last checked against the running code. It is rewritten when the data path changes rather than on a schedule, and a change that adds a service or a purpose is stated in the clause it belongs to instead of being folded into a general reservation of the right to change anything.