On this page
Whose data you are actually holding
The first time you build something real for a client, you are handed a login. Behind it sits a list. Tenants, patients, students, drivers, donors, job applicants. Names, phone numbers, home addresses, sometimes photographs of identity documents. Mindflows builds AI business apps across 15+ industries, including property, healthcare, education, logistics, construction and non-profits, and every one of them keeps records like that.
None of those people know your name. They gave their details to a business they chose to trust. That business then chose to trust you. You are the third link in a chain, and the only link the customer never agreed to.
That is the whole idea in one sentence: you are handling data that belongs to someone else's customers. It is not really the client's data either. They are holding it on behalf of the people who gave it to them, and now so are you. Once you see the job that way, most of the decisions below answer themselves.
Data you may see, data you may keep
Looking at client data is part of the work. You cannot check whether a filter behaves correctly without opening a record. You cannot fix a broken automation without reading what it produced.
Keeping data is a completely separate decision, and it is the one most freelancers make without noticing. Exporting a table to CSV so you can work offline. Screenshotting a dashboard for your notes. Forwarding a client email with an attachment to your own address so it is easier to find. Each of those turns something you were allowed to see into something you now have to protect.
While the data lives only inside the client's system, it is protected by the client's platform, the client's backups and the client's account controls. The moment it lands in your Downloads folder, all of that stops. It is now protected by you.
Before you copy anything, ask one question: can I finish this task without a copy? The honest answer is usually yes. When it genuinely is no, say so to the client, agree where the copy will live and how long it will exist, and delete it when the reason has passed.
Why client data never moves into a personal account
Personal accounts are where client data goes to be forgotten. Your Gmail, your personal Drive, your notes app, a Messenger thread with a colleague, a spreadsheet on a laptop your family also uses. It feels harmless because it is convenient and because nothing bad happens immediately.
The problem is what you have given up. You cannot revoke it. You cannot show the client where it went. You cannot prove it was deleted. If your client is ever asked by one of their own customers where their information is held, "on my freelancer's personal laptop" is not an answer they can give. And if you lose access to that account, or someone else opens it, the failure is yours alone.
The same applies to AI tools, which is easy to forget because typing into a chat box does not feel like moving a file. Pasting a customer list into a chat window is a copy, and it now sits in a history you do not control. Work inside the accounts the client provides. Ask which tools are approved before you use them. When you need help thinking through a structure rather than the people in it, strip out the identifiers first and reason about the shape of the data instead. This is the sort of habit that separates delivering a system from running a few prompts.
Portfolio screenshots deserve the same care. Blur or replace real names and numbers, and ask the client before you publish anything at all.
Test data should not be real data
Building means breaking things on purpose. You create records to see what happens, delete them to check the rules, trigger automations twice to find out what happens on the second run. That is exactly the right way to work, and it is why the rows you practise on should not belong to real people.
When test data is real data, a test email goes to a real customer. A misconfigured notification texts a real phone in the middle of the night. A deletion you meant as an experiment removes a record someone needs on Monday. The mistake is ordinary and forgivable; the consequence lands on a stranger.
The real cost of a test message reaching a live customer is not your embarrassment. It is your client having to explain themselves to someone who never agreed to be part of your testing.
Build yourself a set of fake records that behave like the real ones. Same fields, same awkward edge cases: very long names, missing phone numbers, an address with a comma in it, a date in the wrong format. Fake values, real shapes. If you must work against live data, use a record the client has created specifically for testing, or your own details, and nobody else's.
One more habit worth building early: before testing anything that sends, disconnect the outbound step or point it at your own address. Emails, SMS, webhooks and Slack messages are the parts that leave the building.
Ask for the smallest amount of access
Ask for the least access that lets you do the work, and ask for it in your own name. A named account you were invited to is better than a shared login every time, even when the shared login is faster to arrange.
The reason is not suspicion, it is clarity. A shared login means the system cannot tell your actions from anyone else's. When something goes wrong late at night, you want the log to show plainly that it was not you. If a client offers their own username and password, decline politely and ask for an invitation instead. Asking for it is a reasonable request to make.
Keep a short record of what you were given: which system, which account, what permission level, and the date. It takes a minute, and it makes the next section straightforward. If the scope of the work shrinks halfway through, give back the access you no longer need rather than waiting for the end. Deciding who is allowed to see what is one of the things AI still cannot do for a business, and it is covered properly in backend security when you are not a developer.
When you no longer need access
Not every freelance relationship ends with a formal handover. The messages just stop. Six months later you still have admin rights to a system you have not opened since, holding data about people who have no idea you exist. Closing a project properly is a short job that is easy to skip.
- Confirm the client is the owner or admin of everything you built, not you.
- Transfer anything created under your account: databases, automations, forms, connected apps.
- Remove any API keys, tokens or integrations you set up under your own credentials.
- Delete local copies. Exports, screenshots, downloaded attachments, files in your AI tool history, anything sitting in a shared folder.
- Ask the client to remove your account rather than simply deactivating it, and confirm when they have.
- Send a short message listing what you removed and what remains in their hands.
That last message matters more than it looks. It tells the client the work is genuinely finished, and people remember it.
What you may keep is what was always yours: your own notes and templates, the patterns you learned, and screenshots you have permission to use with the real details removed.
Why so few freelancers do this
Because nobody asks them to. A client hiring help for the first time is not thinking about access levels. They send a password because it is quick, and the freelancer uses it because it works, and neither person raises the subject again.
Which is precisely why raising it changes the conversation. Asking who is allowed to see what, before you build anything, is not a delay. It tells a business that you understand what they are actually handing over. Work that AI can already absorb, the copying and formatting and encoding, sits at around $4 to $7 an hour. Judgement about other people's data is not that kind of work, and it is not the kind of thing a tool will hand you.
JobTayo puts this in the foundation rather than leaving it to be learned the hard way. Conduct and client data is a session in the second course, and the quiz that gates the third course asks about it directly: what is safe to publish, what you say when you break something, and what has to be true before real data goes anywhere near a test. It is one of the skills that outlast the tools, because it belongs to the work rather than to any particular platform.
This is a guide to professional conduct, not legal advice. Contracts, NDAs and the rules that apply to your client's industry or country may ask more of you, and nothing here is a guarantee of work, rates or clients. When you are unsure what you are allowed to do with a set of records, ask the client in writing before you act.
You do not need to be a lawyer or a security engineer to handle this well. You need a few consistent habits and the willingness to say them out loud.
Where to go next
- Backend security when you are not a developer — permissions, roles and who can see what, explained without jargon
- From prompts to systems — how AI work is actually delivered to a client
- The skills that outlast the tools — what stays valuable when the software changes
- See what the foundation covers