Where your data goes, and who touches it.
A security review asks the same four things before it clears a supplier: who else handles the data, how long it is kept, what agreement covers it, and who the company legally is. This page answers all four for this website, with the services named instead of described as third parties.
What this page covers, and what it does not.
This is about the data this website collects: what you send through the contact form, and the request records that come with serving any site at all. Every service in that path is named below with the fields it actually holds, because an answer that gestures at unnamed third-party services is the one a review sends straight back.
It is not a statement about your product. On an engagement, infrastructure runs in your accounts and source lives in your repositories, so the services below are ours rather than a list of what would sit under the system we build for you. That list is decided during scoping and written into the access and security checklist you receive.
Nothing here is a compliance posture. The claims are deliberately small enough to check from the outside: the response headers this page is served with, the disclosure policy published at /.well-known/security.txt, and the single network request the contact form makes when you press send.
The services that touch it.
Each entry states what it holds rather than the category it belongs to. Nothing else runs here: no advertising tag, no cross-site analytics, no chat widget, no embedded media.
Supabase
Database and form endpoint. The contact form posts from your browser straight to a Supabase function, which writes one row and then sends the mail. The row holds the six fields the form collects (name, email, company, enquiry type, budget range, message) 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 row-level security rather than by the form.
Google, over Gmail SMTP
Mail relay. The same function sends two messages through Gmail's SMTP service: a notification carrying your submission to the site's own mailbox, and a confirmation to the address you entered. The confirmation is a fixed template containing none of your text, which is deliberate. It is what stops the endpoint being usable to relay somebody else's message to a stranger.
Vercel
Hosting. Every public page here is built ahead of time and served as a static file, so opening one runs no query and reads no record. What Vercel holds is the request itself, IP address, user agent and path, in its platform logs. It does not hold what you type into the contact form: that request goes from your browser to Supabase directly and never passes through this site's server.
Vercel Speed Insights
Page timing, and the only measurement script on the site. It is served from this domain, at /_vercel/speed-insights/script.js, and reports how fast a page rendered and which route it was. No script from another origin can load 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.
Cal.com
Booking, and only if you book. The Book a call control is a plain link out rather than an embedded widget, so nothing from cal.com runs on this site and nothing is sent there by reading a page. What you enter on their scheduling form you hand to them directly.
What is kept, and for how long.
Written as it runs today, including the part that is still manual. A reviewer is better served by a small true answer than a tidy one.
- One row per submission, in a table called contact_submissions, holding the fields listed above. It is written before the email is sent, so a mail failure degrades the dashboard rather than losing your message.
- One password-gated dashboard on this site reads it, using a server-side key that is never sent to a browser. The publishable key that does ship to the browser can only insert, which is enforced by the database rather than by the page.
- 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 that dashboard. A fixed retention window is deliberately not published here, because a period with nothing enforcing it would be a control that does not exist.
- Deletion on request is a policy the delete path already supports. Write to hello@tdacorp.in from the address you used and the row goes. The notification email is a separate copy sitting in a mailbox, so say if you want that removed as well and it is.
- The subscriber table holds nothing this site put there. No page captures an address for a mailing list, so nothing here writes to it.
Agreements, location, and the parts nobody certifies.
The answers a buying process needs in writing, plus the one thing this page will not claim and the address to send a finding to.
A DPA is reviewed on request
Send a data processing agreement and it is reviewed and answered before any data is shared. It is read case by case rather than signed on sight, because a DPA commits to specific handling and an agreement signed without reading it is worth nothing to the party it is meant to protect. Same position as the NDA on an engagement: the paperwork that protects you should not be a negotiation you have to open.
Where the data sits
One hosted Postgres project in a single region holds the table above. The region is a deployment setting rather than a constant of this page, so it is confirmed in writing on request and named in the DPA, 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.
Email leaves the database
The notification and the confirmation are ordinary email. They travel over Gmail's infrastructure and then rest in mailboxes, so a copy of your message exists outside the database and outside any single region. If something should not sit in an inbox, put it on the call rather than in the form.
What is not claimed
No SOC 2, ISO 27001 or equivalent certification is held, and none is claimed. There is no audit report behind this page and no framework it was derived from. What stands in their place is the practice itself, published in full on /security, and a data path short enough that you can check it rather than take it.
Reporting something you find
Security reports go to hello@tdacorp.in. The policy on /security states what to send, what is asked of a reporter and what to expect back, and it is published in machine-readable form at /.well-known/security.txt.
What to put on the vendor record.
The fields an onboarding form and a purchase order ask for. Anything else your portal needs is sent in writing during onboarding.
- Registered name: TDACORP PRIVATE LIMITED.
- Entity type: a private limited company limited by shares, registered in India under the Companies Act 2013.
- Corporate Identity Number: U62011RJ2026PTC116182. It is the identifier a vendor portal asks for, and it is the one that lets you check the rest of this block yourself on mca.gov.in rather than taking it from us.
- Jurisdiction of registration: Jaipur, Rajasthan, India. The work is remote-first, so this is a legal fact about the entity rather than a service area.
- Recognised as a startup by the Department for Promotion of Industry and Internal Trade, certificate DIPP274377, valid to 16 July 2036. It is a recognition of the ENTITY by the Government of India, not an audit, a security certification or an assessment of the work: the certification position on this site is unchanged, and it is stated under security.
- One address for all of it: hello@tdacorp.in. Onboarding forms, purchase orders, invoicing questions and security review reach the same place, and there is no account-manager layer to route them through.
- Invoicing runs per milestone against the schedule in the engagement document. The rest of the commercial rails, the NDA, IP ownership, credential handling and access returned at the end, are published under the procurement section of how engagements run rather than restated here.
The pages this one leans on.
This page states what happens to data. These state how the work itself is secured and what the contract around it says.
- PageSecurityThe engineering practices the work runs on, and the vulnerability disclosure policy this page points at.
- ProcessThe commercial railsNDA, IP ownership, credential handling and per-milestone invoicing, in the order a buying process asks for them.
- FormatsSample artifactsThe documents an engagement produces, including the access and security checklist filled in before the first credential is issued.
- LegalPrivacy policyThe formal notice. This page is the specific version of it: named services, named fields, named limits.
Ask the question this page missed.
If your review has an item that is not answered above, send it and it gets a straight answer, including the items where the answer is no.