At a glance
A micro-SaaS founder carries enterprise-grade duties with a team of one: the DPDP Act doesn’t scale its breach clocks, consent standards or log-retention rules to headcount. The saving grace is timing — a small codebase can build privacy in for almost nothing, where enterprises retrofit for millions. The essentials: know which role you’re in per product (fiduciary for B2C users, processor for B2B customers’ end-user data), wire consent, deletion and the one-year security logs into the build now, and know your stack’s geography before a customer’s procurement form asks.
Educational resource only. This explains how India’s Digital Personal Data Protection Act, 2023 (DPDP Act) applies to micro-SaaS products and indie founders; it is not formal legal advice.
The situation
Indie SaaS culture optimises for shipping: auth from a template, analytics from a snippet, three third-party APIs, and a users table growing quietly in a cloud region you picked for latency. Every one of those defaults is a data decision, made in minutes, governing real people’s information. The DPDP Act reaches this stack exactly as it reaches an enterprise’s — same duties, same clocks, same penalties — and the founder is the DPO, the security team and the grievance officer at once. The asymmetry sounds unfair until you notice its flip side: nothing is cheaper to make compliant than a product that’s still small.
Does DPDP apply to a side-project-sized SaaS?
Yes — revenue and headcount are irrelevant; Indian users’ personal data brings the duties in full. A products-of-one company deciding why and how users’ data is processed is a Data Fiduciary: notice, valid consent, security safeguards, breach notification, retention limits, rights fulfilment on a clock. The stack doesn’t dilute it — your cloud provider, auth service and analytics tool are your processors, chosen by you, answerable through you. And solo doesn’t soften the sharp edges: a breach starts the same without-delay notifications to the Data Protection Board and affected users whether you have a security team or a Sunday afternoon.
Which role is your product in?
B2C makes you the fiduciary; B2B makes you your customer’s processor — and most SaaS is both at once.
- Your users’ own data (accounts, billing, usage): you’re the fiduciary — your notice, your consent flows, your purposes.
- Data your customers load into the product (their clients, their team, their end-users — the CRM rows, the form responses, the subscriber lists): your customer is the fiduciary; you’re the processor, handling it under their instructions and a valid contract. That’s why B2B customers will send data terms — and why a micro-SaaS should have its own standard data processing terms ready instead of negotiating from zero each time.
- The same product, both piles: the account holder’s email is yours to govern; the ten thousand contacts they imported are theirs. Architecture and contracts both need to know the difference.
The obligation that actually bites: enterprise duties, solo capacity
Four duties don’t care that you’re one person — pre-build them or they arrive as emergencies.
- Breach response has no small-team clock. Notify affected users and the Board without delay, detailed report within 72 hours — a solo founder needs the templates pre-filled and the “what do I check first” list written before the bad Tuesday. This site’s breach-notification template exists for exactly that drawer.
- Security logs: one year, minimum. The Rules require retaining logs for at least a year for breach detection and investigation — an infrastructure decision (log retention settings, storage) that costs minutes now and is unrecoverable retroactively.
- Rights requests need a working path. Access, correction, erasure — publishable channel, identifiers, response inside the 90-day outer limit. At micro-scale this is an email address plus a written-down procedure; the point is having it before the first request, not after.
- Consent must be provable. Who agreed, to what, when, against which notice version — a consent-log table designed in from the start, because a challenged consent you can’t produce is a consent that doesn’t exist.
Build it in now: the cheap-while-small list
Privacy-by-design is a founder’s arbitrage — every item below is trivial pre-scale and painful after.
- Collect at signup only what the product needs — every extra field is future liability, not future optionality.
- Unbundle the consents — service, product emails, marketing: separate unticked choices, stored with timestamps and notice version.
- Write deletion as a feature — account deletion that actually cascades (rows, files, backups on their cycle, processors via API where possible), because bolting it on later is a migration project.
- Know your regions — where the database, backups and third-party tools actually hold data; transfers abroad are broadly permitted except to restricted destinations, but knowing your geography is what procurement forms, and India-residency-minded customers, will ask.
- Keep the vendor list written — every tool touching user data, so a breach’s “who else has it?” is a lookup, not an investigation.
- Turn on the year of logs — and disk encryption, and 2FA on every admin surface: the solo-scale security baseline.
The developer-facing privacy-by-design checklist on this site is the longer version of this list; at micro-SaaS size, most items are configuration, not engineering.
Common mistakes indie founders make
Template defaults, unexamined.
- The analytics snippet tax — trackers added for curiosity, collecting behavioural data no stated purpose covers.
- The copied privacy policy — another product’s policy with the name changed, describing practices that aren’t yours; a false document is worse than a thin one.
- Signup fields as wishlist — phone, company, role, “how did you hear” — collected because the form builder made it easy.
- Deletion as support ticket — no built path, so every request becomes manual archaeology across tables, files and backups.
- Production data as dev data — real users’ rows in local environments and test databases, the indie version of the enterprise data-sprawl problem.
- No processor terms of your own — every B2B customer’s legal team gets a blank canvas, instead of your standard data terms doing the work.
Handling user data compliantly from day one
Wire the four flows — in, consent, out, gone — and write down the rest. In: minimal signup, purpose-labelled fields, notice at collection (the templates on this site fill in an evening). Consent: unbundled, logged, versioned. Out: the vendor list, your standard processor terms for B2B, geography known and stated. Gone: deletion as a cascade you’ve actually tested, retention defaults per table, the year of security logs running. Then the one honest document: a privacy policy that describes what your product really does — which, if you’ve done the above, is short, true and finished before dinner.
FAQ
My SaaS has 200 users and no revenue — do the duties really apply in full?
Yes — the Act attaches to processing Indian users’ personal data, not to traction. What scales is the surface area: 200 users’ worth of minimal, well-organised data is a genuinely small compliance job if you build the flows in now.
Am I a fiduciary or a processor?
Both, usually: fiduciary for your users’ own account data, processor for whatever your customers load into the product about their people. Sort every table into those two piles and the contracts, consents and duties fall into place.
What’s the one-year log rule?
The Rules require security and processing logs to be retained for at least a year, for breach detection and investigation. It’s a settings-and-storage decision — turn it on now; you can’t backfill logs after an incident.
Can I host on foreign cloud regions?
Transfers abroad are broadly permitted except to destinations the government restricts — so yes, generally. Know your geography anyway: enterprise customers and sectoral buyers increasingly ask, and “I’d have to check” is the wrong answer on a procurement call.
What breaks first when a micro-SaaS grows?
Whatever wasn’t built in: deletion that doesn’t cascade, consents that weren’t logged, data in regions nobody chose deliberately. The pre-scale hours spent on those three are the cheapest compliance you’ll ever buy.