If real people use your app, you are almost certainly holding personal data. It rarely feels dramatic. A signup form here, an email field there, a support inbox, a payments provider quietly storing card details on your behalf. None of it announces itself as "personal data," and if you built the app with AI or no-code tools, nobody sat you down to explain what you took on the moment a stranger typed their email into your form.
This post helps you do one calm, concrete thing: figure out whether your app collects personal data, name exactly which fields count, and adopt a few minimal responsible defaults you owe the people who trust you. It is part of the security self-audit that surrounds this, and it stays deliberately practical.
One thing up front, and it matters: this is educational, not legal advice. Rules about personal data vary by where you and your users live, and only a qualified professional can tell you what applies to your specific situation. What follows helps you see clearly and act responsibly. It does not tell you that you are compliant, because no article can.
What counts as personal data (in plain terms)
Personal data is any information that can identify a specific person, on its own or when combined with other things you hold.
The obvious examples are the ones you would guess: full name, email address, phone number, home or billing address, a photo of someone's face. But the category is wider than most builders assume. It also includes things that point at a person indirectly:
- A user ID tied to a real account
- An IP address collected in your logs
- Device identifiers and cookie IDs
- Location data
- A username or handle a person chose that reveals who they are
- Anything you store that, stitched together, singles someone out
A useful mental test: if you can look at a row in your database and figure out (or reasonably guess) whose row it is, that row involves personal data.
The sensitive kinds that raise the stakes
Some categories carry heavier obligations and deserve extra care because the harm from a leak is worse. Treat these as escalation triggers, not routine fields:
- Health information — symptoms, conditions, fitness or medical data, anything about someone's body or mind.
- Financial information — card numbers, bank details, income, anything that could enable fraud.
- Government identifiers — passport, national ID, tax, or social security numbers.
- Children's data — if minors can realistically use your app, obligations often increase sharply. Exactly when and how varies by jurisdiction.
- Other sensitive traits — things like race, religion, sexual orientation, or precise location, which can expose people to real-world harm.
If your app touches any of these, slow down. This is one of the clearest "get a professional involved" signals, and we come back to it at the end.
How to inventory what your app actually collects
You cannot protect what you cannot see. Before you change anything, map what you hold. Keep it low-tech: a simple table works fine.
Walk through your app the way a new user would, and write down every place a piece of information gets captured or stored. Then note, for each one, what it is and why you have it.
| What you store | Where it lives | Is it personal data? | Sensitive? | Why do you have it? |
|---|---|---|---|---|
| Email address | Auth provider / users table | Yes | No | Login + receipts |
| Full name | users table | Yes | No | Personalization |
| Support messages | Inbox / helpdesk tool | Often yes | Sometimes | Answer questions |
| IP + request logs | Hosting logs | Yes | No | Debugging |
| Card details | Payments provider | Yes | Yes (handled by them) | Charge customers |
Where should you look? Cover more than the signup form:
- Forms and inputs — signup, profile, checkout, contact, surveys, comments.
- Your database — open your tables and read the column names. AI-built apps often create fields you never explicitly asked for.
- Files and uploads — profile photos, documents, attachments people send you.
- Connected services — your auth provider, payments provider, email sender, and helpdesk each hold data on your behalf.
Understanding where each item physically sits is half the battle, so it is worth reading where your app's data actually lives alongside this inventory. When you finish, you will have something most builders never make: an honest list of what you hold and why.
The minimum you owe your users
Once you can see your data, three defaults cover most of the responsible baseline. None of them require you to become an engineer.
Collect less
The safest data is the data you never collected. Go through your inventory and ask, for each field, "Do I actually use this?" A phone number you never call, a date of birth you never check, a full address for a product you deliver by email: if it has no job, stop collecting it. Less data means less to protect, less to leak, and less to explain.
This is the single highest-leverage habit for a solo builder. Default to asking for less, and add fields only when a real feature needs them.
Protect what you keep
For the data that earns its place, apply basic hygiene:
- Make sure it travels over an encrypted connection (your site should be on HTTPS).
- Limit who can see it. If you are the only person who should read user records, don't leave a dashboard or export open to the world.
- Don't paste real user data into random tools, spreadsheets, or AI prompts to "test something." Copies leak.
- Keep your accounts (hosting, database, email, payments) behind strong, unique passwords and two-factor login.
You do not need a security team to do these. You need to do them consistently.
Be honest about it
People are owed a plain answer to "what do you do with my information?" A short, truthful privacy notice that says what you collect, why, and who you share it with goes a long way. It does not need legal-sounding language to be useful, though the specifics of what you must disclose depend on your situation. For the practical version of this, see privacy and consent basics before launch. You can also work through the broader launch checklist on Ship Responsibly.
The data you did not mean to collect
Here is the part that surprises people. Your forms are the visible tip. Most apps quietly collect personal data through the plumbing, and it never appears on any screen you designed.
Logs. Your hosting and server logs routinely record IP addresses, request details, and sometimes URLs that contain identifiers. That is personal data sitting in a place you rarely open. You do not have to delete logs (they help you debug), but you should know they exist and not keep them forever without reason.
Analytics. If you added an analytics or tracking snippet, it may collect IP addresses, device details, and behavior tied to individuals. Some analytics tools are more privacy-preserving than others. Check what yours actually captures rather than assuming it is anonymous.
Third-party embeds. Chat widgets, comment systems, embedded videos, social buttons, ad or marketing pixels, and "sign in with…" buttons often send data to their vendors the moment your page loads. You invited them in; they are collecting too.
AI-built defaults. Tools that generate code or apps sometimes wire in tracking, logging, or third-party services by default. Look at what your build included that you never chose.
Add all of these to your inventory. The goal is not to rip everything out. It is to stop being surprised by data you hold, so you can make deliberate choices about it.
A caution on the flip side: once you find data you would rather not keep, resist the urge to delete in a panic. Deleting production data hastily can break your app or destroy records you (or your users) actually need. Back up first, understand what depends on the data, and remove it deliberately.
When personal data becomes a reason to get help
Doing the basics yourself is reasonable and responsible. But some situations move beyond a self-audit, and the mature move is to recognize the line rather than push past it. Consider bringing in a professional (a privacy-aware lawyer, a security specialist, or both) when:
- You handle health, financial, government-ID, or children's data. These categories carry heavier obligations and heavier consequences.
- You take payments or store anything that could enable fraud. Let a dedicated payments provider hold card data; do not build that yourself.
- You handle account logins and passwords for other people and are unsure whether your setup is safe.
- Your users span multiple countries or regions, so more than one set of rules may apply.
- Specific laws you have heard of (for example, GDPR or CCPA) might cover you, and you genuinely do not know whether they do. Whether any given law applies to your app depends on facts only a qualified professional can assess for your situation.
- Something already went wrong, or you suspect data was exposed.
For a fuller framework on this decision, read when a professional should get involved. Expert review is genuinely recommended for anything touching sensitive data. This is not fear; it is the same judgment you would use before wiring your own house.
In Plain English
What this means: If people use your app, you are holding personal data, some of it in places you never designed. Personal data is anything that can identify a person: names, emails, IPs, user IDs, uploads, and the log and analytics trails behind them. Sensitive kinds (health, finance, government IDs, children's data) raise the stakes.
Minimal responsible defaults: Collect less than you think you need. Protect what you keep with HTTPS, tight access, and good account security. Be honest in a plain privacy notice. Know your hidden sources (logs, analytics, embeds). Never delete user data in a hurry without a backup and a plan.
Who this helps: Solo founders and non-technical builders who shipped an AI or no-code app and aren't sure what they collect or what they owe users.
When to use it: Now, once your app has real users, and again whenever you add a form, an integration, or a third-party tool.
What to do next: Make the inventory table, mark the personal-data and sensitive fields, and decide what to trim, protect, and disclose. If sensitive data is involved, get expert review.
Your next step
Map what you store using the ownership audit, then flag every personal-data field so you know exactly what needs protecting. When your list is done, take it into the wider security self-audit on the Secure hub and work through it one field at a time. Owning your app starts with knowing what it holds.
Kodbe is an independent commercial publication about maintaining and owning software built with AI or no-code tools. It is not affiliated with Kodbe Inc, Kodobe, Kodable, or Kodu.