Privacy Policy

PixlNova is a sole proprietorship. It is not a company, and as at the version date of this document it is not registered — GST registration, Udyam (MSME) registration and a current account are all in progress. Nothing here should be read as claiming a registration that does not yet exist.

The Explanation to section 43A of the Information Technology Act 2000 defines a body corporate to include a sole proprietorship engaged in commercial or professional activities. The SPDI Rules 2011 therefore apply to this studio, and we treat them as applying in full. Under the Digital Personal Data Protection Act 2023, the proprietor is the Data Fiduciary and you are the Data Principal.

This policy governs pixlnova.com only. That includes the marketing pages, the enquiry form, the guided assistant at /chat, and any email thread that starts from one of those.

It does not govern projects.pixlnova.com, which sells downloadable academic project packages, or freelancer.pixlnova.com, which is a talent marketplace with escrow. Those are different products handling different data, and each publishes its own privacy policy. We would rather say so than pretend one page governs three businesses.

Each section carries a one-line plain-English summary in the margin. Those lines are a reading aid. They are not the terms, and where a summary and a clause differ, the clause is what applies.

Elsewhere on this site three kinds of clause deliberately carry no plain-English line: limitation of liability, indemnity, and intellectual property assignment. Those are the three places where a friendly one-liner most reliably understates what the clause does, and where the cost of a mismatch is highest. Their absence there is a decision, not an oversight. This document contains none of the three, so every section here has a summary.

This policy is published in English. Section 5(3) of the DPDP Act lets you ask for the notice in any language listed in the Eighth Schedule to the Constitution. If you want this policy in Tamil, ask at the grievance address in section 11 and it will be sent to you.

Our database is hosted by Supabase in region ap-southeast-2, which is Sydney, Australia. If you are in India, your personal data is stored outside India. That is a deliberate choice with real consequences, and section 7 sets them out plainly rather than listing a hosting provider and moving on.

The contact form collects thirteen fields. All of them are stored. None of them is inferred, enriched from a third-party data provider, or appended to from any other source.

Fields you leave blank are stored blank. The two free-text fields hold exactly what you write, so treat them as you would an email — see clause 3.7 before putting anything confidential in them.

The assistant at /chat is a guided walkthrough of content already published on this site. It is not a language model. Your messages are not sent to any model provider, and nothing you type there is used as training data by us or by anyone else.

A brief you submit at the end of that flow goes through the same pipeline as the contact form, is stored in the same place, and is covered by every clause in this policy that applies to a form submission.

When we reply, the message is sent through Resend. The thread that follows — everything you write to us and everything we write back — is personal data we hold, and it is usually the largest part of it. Attachments you send are stored with the thread.

The analytics are first-party. Three identifiers are involved, and there are no others.

The two cookies are scoped to Domain=.pixlnova.com, so the same pxnv_anon_id is sent on pixlnova.com, projects.pixlnova.com and freelancer.pixlnova.com. Activity on those properties can therefore be attributed to the same browser. We disclose this because a first-party cookie scoped to a parent domain is genuinely cross-property, and calling it site-only would be untrue.

If you then submit the enquiry form, the anonymous identifier is associated with the enquiry. From that point it is no longer anonymous to us, and everything in this policy about identifiable data applies to it.

With each analytics event we record the page path, a timestamp, the browser user-agent string, and a transformation of your IP address. We do not store the raw IP address of a site visitor.

The transformation is SHA-256 over the string salt:ip, using a secret salt held on our server. This is pseudonymisation, not anonymisation, and the difference matters. Because the salt is fixed, the same IP address always produces the same hash, so visits can be linked. Because we hold the salt, a specific IP address can be tested against a stored hash. We therefore treat the hashed IP as personal data under both the DPDP Act and the GDPR, and it is covered by every right in section 10.

Payments are taken through Razorpay or Stripe. Card numbers, UPI handles, CVVs and bank credentials are collected by the payment provider on their own systems. They never reach ours, and we could not retrieve them if asked.

What we hold is the record around the payment: an amount, a currency, a status, the provider transaction identifier, and the invoice it belongs to. Those records are also what our tax obligations attach to, which is why clause 9.1 keeps them longer than anything else.

Rule 3 of the SPDI Rules defines sensitive personal data as passwords, financial information such as card or account details, physical, physiological and mental health condition, sexual orientation, medical records and history, and biometric information.

We do not ask for any of it. No field on this site requests it, and we have no use for it. Please do not put any of it into the two free-text fields or into an email to us. If you do send it, we will delete it once the point it was sent to make has been dealt with.

The thirteen form fields exist so that a reply can be useful rather than a request for the same information again. The service, product stage, budget band and timeline fields let us say honestly and early whether a project is a fit, which is the outcome that saves you the most time.

If the enquiry becomes a conversation, the same record carries it: notes, the written scope, and the milestone plan.

Once a scope is agreed, we use your contact details to run the project: milestone acceptance, invoices, handover documentation, and defect-warranty correspondence during the 30, 60 or 90 day period stated in your plan.

Project code lives in your repository and infrastructure lives in your accounts, so most of what a client would think of as project data never sits on our systems at all. What we hold is the commercial record of the engagement.

The analytics answer three questions: how many people read a page, which pages lead to an enquiry, and where visitors arrive from. That is the whole purpose. It informs what gets written next.

It is not used to target you, to score you, or to change what you are shown. Everyone sees the same pages.

Invoices, payment records and the identity of the party we invoiced are kept because Indian tax law requires books of account to be kept, and because a payment dispute cannot be answered without them. This purpose is why deletion is not always total — clause 10.5 explains what survives an erasure request and why.

We do not use your data for advertising of any kind, we do not add you to a marketing list because you sent an enquiry, and we do not disclose your name or your project as a case study without written permission. That last point is why this site currently shows no client names.

When you submit the enquiry form or a brief through /chat, you consent to us using those thirteen fields to reply to you and to discuss the work. The notice at the point of collection says so, and this section is the itemised version of that notice required by section 5 of the DPDP Act.

Giving the information is voluntary. Rule 5(7) of the SPDI Rules gives you the right not to provide it, and the practical consequence is the obvious one: without an email address there is nowhere to send a reply.

Analytics run on a first-party, no-third-party basis and are limited to counting. The control we offer is unconditional rather than a banner preference: set do-not-track in your browser and nothing is collected. Clearing your cookies and localStorage removes the identifiers already stored.

Two narrow cases. Section 7(a) of the DPDP Act covers personal data you have voluntarily provided for a specified purpose — the enquiry you sent us is exactly that. Section 7(b) covers processing required to comply with a law, which is the basis for keeping tax records after you have asked us to delete everything else.

Nothing else is processed on any other basis. We do not rely on a general legitimate-interest theory to do things this policy does not describe.

You can withdraw consent at any time by emailing the grievance address in section 11. Say that you are withdrawing consent and we will stop processing within a reasonable period, as section 6(6) of the DPDP Act requires, and delete what clause 9.1 does not require us to keep.

Withdrawal is not retrospective. It does not make unlawful anything we did lawfully before you withdrew, and it will not remove an invoice we are obliged to keep. It should also be said plainly that if you withdraw consent mid-enquiry, we can no longer reply to that enquiry.

The DPDP Act contemplates registered Consent Managers through whom consent can be given, managed and withdrawn. We have not appointed one and are not registered with any. Consent is given and withdrawn directly with us, by email.

Four providers process personal data on our behalf, each for one job.

The Subprocessors page at /legal/subprocessors carries the current list, what each one holds, and where each one runs. That page is the authoritative version; if it and this clause ever disagree, the Subprocessors page is right and this clause is stale. Adding a provider that handles personal data is a material change under clause 14.1.

For work outside one engineer's range — a video edit, a heavy motion sequence — a trusted collaborator may be brought in. You are told before it happens, not after. Any collaborator is bound by confidentiality, is given only what the task needs, and never receives an enquiry record that is not their project.

We do not sell, rent, licence or barter personal data. We do not share it with data brokers, lead-generation services, advertising networks or partners. There is no exception to this clause and no plan to create one.

Rule 6(1) permits disclosure without consent to a government agency mandated by law to obtain the information, and where disclosure is required by a court order. We will comply with a valid, lawful demand of that kind.

We will tell you that it happened unless we are legally prohibited from telling you. We will ask for the demand in writing, and we will not disclose more than the demand actually requires.

If the studio is sold, merged into a company, or transferred as a going concern, client records may transfer with it. If that happens you will be told by email before your data moves, and the acquirer will be bound by this policy until it publishes one you have been given the chance to read.

Enquiries, briefs and analytics events are stored in a Supabase Postgres database in region ap-southeast-2. That region is Sydney, Australia. Backups of that database are held by Supabase in the same region. Email in transit is handled by Resend, and payment records sit with Razorpay or Stripe; the Subprocessors page states where each of those operates.

It means your personal data is physically stored outside India, on infrastructure subject to Australian law. Three consequences follow, and none of them are hypothetical.

The Reserve Bank of India directs that payment system data be stored in India. That obligation falls on the payment providers, not on us, because payment credentials are collected on their systems and never reach ours. Razorpay and Stripe address it in their own policies. What we hold is an amount, a status and a transaction reference, which is not payment system data in that sense.

Tell us before you send anything. We can take an enquiry by email or on a call instead of through the form, though our mailbox is also hosted outside India and we will not pretend otherwise. For a client project, data residency can be part of the written scope — the software we build for you runs in your accounts, in a region you choose.

Stating this is more useful to a procurement reviewer than a list of controls with the gaps left out.

One person holds every administrative credential. That removes whole categories of risk — no leavers, no over-broad internal access, no third-party support staff browsing records — and concentrates one: if that person's accounts are compromised, everything described in this policy is exposed at once. Multi-factor authentication and secret management exist mainly to hold that single point. You should weigh it knowingly rather than discover it later.

If personal data is breached, we will notify the people affected by email without undue delay, and notify the Data Protection Board as section 8(6) of the DPDP Act requires once that provision is in force. The notification will say what happened, which categories of data were involved, what we have done, and what you should do. We will not delay a notification to finish investigating, and we will not describe an incident as a technical issue.

We will never ask you for a password, a card number, a CVV, an OTP or a bank credential — not by email, not on a call, not in a support thread. Any message that does is not from us. Report it to the grievance address in section 11.

Deletion removes the record from the live database. Provider backups continue to hold a copy until they age out on the provider's own cycle, and we cannot reach into a backup to edit it. We do not restore a backup in order to recover data that was deleted at your request, and if a backup is ever restored for an unrelated reason, deletions are re-applied.

Send the request from the address in your record and we will not ask for anything more. If you cannot, we will ask for something that connects you to the record — a project reference, an invoice number, the date of the enquiry. We will not ask for a government identity document to service a routine request, because collecting an identity document to protect data is a poor trade.

Exercising any of these rights is free. We do not charge a fee, we do not require a form, and we do not require you to create an account to ask.

An erasure request will not remove an invoice or the payment record behind it, because clause 4.4 and clause 9.1 are obligations under tax law rather than preferences of ours. In that case we delete everything else, tell you precisely what remains and why, and delete the remainder when its retention period ends.

If we refuse a request outright, you get the reason in writing.

Section 15 of the DPDP Act places duties on you too: not to impersonate someone else when giving personal data, not to suppress material information, and not to raise a false or frivolous grievance. We mention it for completeness, not as a warning. In practice, the only one that ever matters is that the details you give us should be your own.

The acknowledgement and resolution periods in the block above are the periods we commit to, not the statutory maximum. Rule 5(9) allows a month to redress a grievance and other rules allow longer. Publishing a ceiling would read badly for a studio that answers email the same day, so we publish what we actually do.

The same address handles every request in section 10, any question about this policy, and any report of a suspected breach.

Escalate. Under the DPDP Act, a Data Principal who is not satisfied after exhausting the grievance route may complain to the Data Protection Board of India once the Board is constituted and its complaint process is operating. We will not treat a complaint to a regulator as a reason to end a working relationship, and we will cooperate with any enquiry that follows.

pixlnova.com sells development services to businesses. It is not directed at children, and we do not knowingly collect personal data from anyone under 18. If you are under 18, please do not send the enquiry form.

The sibling site projects.pixlnova.com sells academic project packages and does expect student buyers, some of whom may be under 18. It handles the question under its own privacy policy. This policy does not govern it, and we are not going to write a children's clause here that pretends to.

Under section 9 of the DPDP Act, processing a child's personal data requires verifiable consent from a parent or lawful guardian, and the same applies to a person with a disability who has a lawful guardian. The Act also prohibits tracking, behavioural monitoring and targeted advertising directed at children.

We do no behavioural advertising and no targeted advertising at all, to anyone, so that prohibition is met by not having the capability in the first place.

If you are a parent or guardian and believe a child has submitted personal data through this site, write to the grievance address in section 11. We will delete it and confirm that we have. No proof of guardianship will be demanded before a deletion — deleting is the safe outcome either way.

Article 3(2)(a) — offering goods or services to people in the Union. Recital 23 asks whether we envisage doing so. Our prices are published in Indian rupees and US dollars only, the site is in English only, there is no euro or sterling pricing, no EU-country targeting and no EU-language version. On the ordinary reading, simply being reachable from Europe does not meet the test. But if we take on a client based in the EU or the UK, that engagement plainly does, and we will treat it that way from the first email.

Article 3(2)(b) — monitoring behaviour that takes place in the Union. Our first-party analytics count page views and set a 365-day identifier. We think counting visits is a weak fit for monitoring as the Recital 24 profiling test describes it, but we would rather be conservative than clever about it, so we apply the protections in clause 13.2 to visitors from the EU and the UK regardless of how the question resolves.

Where the GDPR or the UK GDPR applies to processing described in this policy, you have the rights in Articles 15 to 22 — access, rectification, erasure, restriction, portability, and objection — in addition to everything in section 10. The route is the same: the grievance address in section 11. We answer within one month, as Article 12(3) requires, which is inside the period already published there.

Our lawful bases would be consent under Article 6(1)(a) for the enquiry form and the analytics, performance of a contract under Article 6(1)(b) for delivering an engagement, and legal obligation under Article 6(1)(c) for tax records.

The transfer point is the one that matters, and it is not comfortable. Our database is in Australia, and Australia is not covered by a European Commission adequacy decision or a UK adequacy regulation. A transfer within the scope of Chapter V would therefore need an Article 46 safeguard, such as standard contractual clauses with the hosting provider, or an Article 49 derogation. Before we accept an engagement to which the GDPR applies, we will put the Article 46 safeguard in place and say so in writing. We are not going to claim it is already done.

You also have the right to complain to your national supervisory authority, or to the Information Commissioner's Office in the United Kingdom. You do not need to come to us first.

Article 27 requires a controller outside the Union that is caught by Article 3(2) to designate a representative in the Union, unless the Article 27(2)(a) derogation for occasional processing applies. The same requirement exists under the UK GDPR for a UK representative. Whether this studio has appointed one, and if not the basis for not appointing one, is a decision recorded in the identity record rather than written into this page.

A change-notice clause that does not define material means nothing, so here is the definition. A change is material if it does any of the following.

A material change is published here and takes effect 30 days later. Anything else — a clarification, a corrected reference, a plainer sentence — takes effect when it is published. Neither kind is ever applied retrospectively to data already collected under an earlier version.

The version date, the date this version takes effect and the date a human last read it are at the top of this page. The version history at the bottom records every change in one line each, so you can see what moved without re-reading the document. If we hold your email address for a live engagement, we will email you about a material change rather than rely on you revisiting this page.

At least once a year, and immediately on any of these: GST or Udyam registration completing, a new subprocessor being added, a change in the storage region, notification of the DPDP Rules or the commencement of a further section of the Act, or a restriction notified under section 16. The last-reviewed date at the top is only meaningful if it moves, so it will not be updated without someone actually reading the document.