Privacy policy

In short: we never sell personal data, and never use your code or workspace data for advertising. We read your code only to do the work you ask for, and keep as little of it as we can.

1. Introduction

Avokaido makes two products. Avo Monitor reviews software every week and reports what it finds. Avo Builder turns a request into a change in a customer’s own code. This policy explains what personal data we handle, why, how long we keep it, who helps us, and what you can do about it.

Avokaido is run by Avokaido AB (org.nr 559577-9736), Drottninggatan 32, 111 51 Stockholm, Sweden.

2. Who is responsible

We decide, so we are responsible, for:

• this website, avokaido.com
• accounts and workspaces in the Avokaido app
• demo requests, messages sent through Contact us, billing, emails and support

Our customer decides, and we work for them, for:

• the code in the repositories they connect
• what people send through the suggestion box on the customer’s website

For these, the customer is responsible, and our data processing agreement sets out how we handle the data for them.

3. Why we may use it (legal basis)

• To deliver what you signed up for: your account, workspaces, Avo Monitor, Avo Builder and billing.
• Because you said yes: Google Analytics and Google Ads cookies, and screenshots you choose to share in a suggestion box.
• Because we have a reasonable need: keeping the service safe, stopping spam, counting visits, following up a demo you asked for, and answering a message you sent us.
• Because the law requires it: bookkeeping.

4. What we collect

4.1 On this website

• Book a demo: full name, email, company, team size, what you’d like to build (optional) and the time you pick.
• Contact us: full name, email, company (optional), what it is about, and your message. It is sent by email to contact@avokaido.com and kept there, not in our database.
• Free website check: the address of the website you check. Nothing about you.
• Our visit counter: which page, where on it you clicked, how far you read, and which link brought you. No name, no cookies.
• Cookies, only after you click Accept: see section 9.

4.2 In the Avokaido app

• Account: name, email, and how you sign in (Google, GitHub, or email and password).
• Workspace: its name, its members and their roles, connected repositories, settings and rules.
• Billing: plan, payments and invoices, and a usage record for each AI request: who made it, which AI model, how many tokens and what it cost (never the prompt or the reply). Card details go straight to Stripe. We never see them.
• Activity: who asked for, built, approved and merged each change, when, and with which AI model.
• Connected tools: access to GitHub, Linear or Jira when you connect them, and your own AI keys if you add them.

4.3 What you ask for that Avokaido can’t do yet

When you ask the project wizard, or a suggestion box while signed in as one of the company’s team, for something Avokaido can’t build in yet (like SMS messages or BankID sign-in), we keep it as a feature request: a short name for the wish, which workspace and app it came from, when, and your words, with anything that looks like an email address or phone number taken out. It never says who asked. Our staff use it to decide what to build next, and may copy the wish and a few people’s words into our own issue tracker (Linear). Each ask is kept for one year, and goes at once if the workspace is deleted.

When a visitor to a company’s website asks a suggestion box for something like that, we only count it (which wish, which website, when), never their words.

4.4 Support and email

• What you write to us, and the emails we send you.

5. Your code

Avo Monitor and Avo Builder have to read your code to work. This is what our customers ask about most, so here is exactly what happens.

Access

You install the Avokaido app in GitHub and choose which repositories it may use. Each access key we use lasts one hour. Remove the app in GitHub and our access ends at once.

What Avo Monitor does

It reads your code every week and reports what it finds. Some checks use AI to map how your code connects, and one check runs your project’s own tests in a sealed container. It never changes your code.

When a scan finds something critical, each admin of your workspace gets one email about it: the overall score, how many findings there are of each severity, and up to ten critical findings by repository and title. It contains no code. It is sent through SendGrid, and its button signs that admin in to Repo Health for about an hour.

What Avo Builder does

It works in your repositories through branches and pull requests. A change is merged only under the rules your admins set. Your admins can also define kinds of change of their own, each by the files and folders it covers, and give each its own sign-off rules: a change that touches those paths is never merged on its own, and where the rules ask for a sign-off, Avokaido does not merge it until the people they name have signed it off. The suggestion box’s interview is told each kind’s name and description, so it can say which kind a request is, but never its paths.

When a change adds a package from a public registry (npm, pub.dev or PyPI), Avo Builder looks that package’s name and version up on that registry and on osv.dev, to check that it exists, which licence it has and whether it has known security problems. Only the package’s public name and version are sent. Packages from your own private registries are not looked up anywhere.

When your app needs a photo nobody supplied, like a picture on each card, Avo Builder looks for a freely licensed photo of that subject on Wikimedia Commons, Unsplash or Pexels. Only a few words naming the subject are searched for (like “hass avocado”), never your code or personal data. The photo is not copied into your app: your app links to it on that site, with the credit its licence asks for. So that site sees each visitor’s IP address when the picture loads, as with any picture shown from another site. If you’d rather it didn’t, replace those photos with your own.

Where a new project is kept

A project Avo Builder creates for you has its code in one of two places: Avokaido’s own GitHub organisation, or one of yours. In ours, we own the repository and can fix or remove it. In yours, it is yours: we reach it only through the Avokaido app you installed, and lose that the moment you remove it.

A workspace admin can delete a project kept in our organisation in Settings › Repositories and access. That deletes it for good: its repository and history on GitHub, its website, and the Firebase project we made for it, if it has its own (Google holds a deleted Firebase project for 30 days before it is gone). Deleting the workspace deletes them all the same way.

On Enterprise, your admins choose in Settings › GitHub whether new projects go to Avokaido’s organisation only, to yours only, or to whichever the person creating the project picks. Services and mobile apps are always kept in Avokaido’s organisation, because what builds and signs them lives there.

Moving a project between our GitHub and yours

A workspace admin can move a website we host from Avokaido’s organisation to one of yours, or from yours to ours, on the Repositories page. Moving it to yours needs Enterprise. We copy every branch and tag into a new repository, move our records for the project to its new name, and publish the app once from there. Its address doesn’t change, and we keep hosting it.

• Into your organisation: the new repository is yours, like anything else there. Its checks and deploys run on GitHub Actions in your organisation and use your GitHub plan’s minutes. We add only the workflow that runs them, never secrets. Our old copy is made read-only and deleted 30 days later.
• Into ours: the new repository is ours, as above. Your old copy stays yours. We make it read-only only if you ask, and never delete it.

Services and mobile apps can’t move, for the same reason.

A new project before it is created

While you describe a new project in the project wizard, what you write, the wizard’s questions and your answers, and the plan are saved as you go, so a refresh or a closed tab loses nothing and you can carry on from another device. The draft is kept in your workspace, where only you can read it, with a copy in your browser on the device you use. Documents and images you attach are not kept in it.

The draft is deleted when the project is created, or when you choose Start fresh. One you don’t come back to is deleted 30 days after your last change.

Files you attach when planning a project

When you plan a new project in the project wizard, you can attach PDFs, Excel files and CSV files. They are read in your browser, and what the plan needs from them goes to the AI model your workspace uses (see AI, below): a PDF whole, a spreadsheet as its column names and first rows.

A file you keep in the app goes into the new project’s repository, in its data/ folder, when the project is made, and the app starts with it. Keeping is on for spreadsheets and off for PDFs until you change it. The file then stays in the repository for as long as the repository does, like the rest of the project’s code; we keep no other copy of the file, and until the project is made it is only in your browser. A website without sign-in shows what it keeps to anyone who opens it, and the wizard says so beside the file.

So the wizard can show your app with your own data before it is built, we keep a small part of each Excel, CSV or JSON file you attach: the name of the file, each table’s column names and what kind of value each column holds, how many rows it has, and its first 25 rows, with long cells cut short. Nothing is kept of a PDF or a picture. It is kept in your workspace, where only you can read it, and you see it under Your data in the wizard, where you can use it in another project or delete it. What you don’t delete is deleted 30 days after you attached the file.

Email your app sends

An app Avokaido makes for you can send email to the people who use it, such as an invitation to join your team, a confirmation or a reminder. The app has nowhere to send from, so it asks us, and we send it through SendGrid from an address reserved for your app. You are responsible for that email and the addresses it goes to; we send it for you.

• What goes through us: the recipient’s email address, the subject and the message. The message is sent and not kept.
• What we keep: a record of each email sent, with the recipient, the subject and the sender address, never the message, so that you and our support can see what went out. It is kept as long as the project is in Avokaido. An email booked for later is kept, with the values it needs, until it is sent.
• Who can send: a person signed in to your app, or the app itself with a message you wrote in advance. Each app has a daily limit, and we stop an app’s sending if too much of its mail bounces or is reported as spam.

If you received an email from an app made with Avokaido, the company running that app is responsible for it. Ask them first; we will help them answer.

Files your app saves to Google Drive or SharePoint

An app Avokaido makes for you can save a file it produces, such as a signed agreement, into a Google Drive, OneDrive or SharePoint account. The person using the app chooses the account and connects it by signing in to Google or Microsoft. The sign-in page names Avokaido, because the app connects through our own sign-in apps at Google and Microsoft, and the file goes through us. You are responsible for what your app saves and where; we deliver it for you.

• What goes through us: the file and its name. They go straight on to Google or Microsoft and are never kept or logged by us.
• What we keep: for each connection, whether it is Google or Microsoft, the connected account’s email address, which of your app’s users connected it, the key Google or Microsoft gave us to keep saving there (encrypted), and when it was connected and last used. It is kept in Avokaido’s database in the EU until the person disconnects it, Google or Microsoft cancel it, the app or workspace is deleted, or it goes 12 months unused. While someone connects, a short code that ties the sign-in to their app is kept for 10 minutes. We also count how many files each app saves a day.
• What we can reach: on Google Drive, only the files we put there. Microsoft’s permission is wider and covers the files and SharePoint sites the account can reach; we use it only to save your app’s files where the app sends them.

If an app made with Avokaido saved a file to your account, the company running that app is responsible for it. You can disconnect in the app, or remove Avokaido’s access in your Google or Microsoft account settings.

Agreements your app sends for signature

An app Avokaido makes for you can send agreements for signature through Avokaido Sign, our own signing service. It runs in Avokaido’s own Google Cloud project in Belgium. When you add e-signing to an app, we set up your organisation in Sign, invite your workspace’s admins to manage its agreements there, and register your app, so that the people signed in to your app can send agreements in your organisation’s name. You are responsible for the agreements and who they go to; we run the signing for you.

• What Sign keeps: each agreement’s document, its parties’ names and email addresses, who sent it (by the email they signed in to your app with), the signature each signer draws or types and the fields they fill in, the signer’s IP address and browser when they sign or decline, and an audit trail of who did what and when. Signers sign with a drawn or typed signature; no national e-ID and no personal number is used.
• Email: Sign emails each party their own signing link, reminders and the signed copy, through our email service (SendGrid). A signer’s link stops working once they have signed or declined, or the agreement is closed.
• Who can see an agreement: the person who sent it, your organisation’s admins in Sign, and the parties, each through their own link. Someone else signed in to your app sees only the agreements they sent.
• What we keep about your app: which of your apps are connected, and the Firebase project and sign-in tenant their users sign in through, never the users themselves.
• How long: until the agreement, or your organisation in Sign, is deleted. Your admins can delete agreements, and we delete your organisation’s agreements when you ask or when the workspace is deleted.

If you signed an agreement sent through an app made with Avokaido, the company that sent it is responsible for it. Ask them first; we will help them answer.

Errors in your app

When something goes wrong in an app Avokaido makes for you, the person using it sees a short reference, such as “Reference K7PQ2M”, and the error is written to the logs of the app’s own Google Cloud project, so your IT admin can find it from that reference and fix it.

• What is logged: the kind of error and where in the code it happened, the screen it happened on (its path, never the rest of the address), the app’s version, the device’s platform and browser, the reference, and the id of the person signed in, if anyone was. Messages are cleaned of email addresses, passwords, tokens and keys before they leave the device, and again when they are logged. Never document contents or anything a person typed.
• Where: only in your app’s own project, at Google. Google’s request log for that project also records the caller’s IP address, as it does for every request. Nothing is sent to Avokaido’s own systems.
• How long: 30 days, then Google deletes it.

If the logs investigator is switched on for your workspace, it reads these logs where they are, as for the rest of your app’s logs (see Logs from your apps).

Groups and shared calendars in your app

An app Avokaido makes for you can let the people who use it form small groups, such as a family or a team, and invite each other by link. It can also merge the calendars those groups subscribe to, such as a sports club’s, a school’s or a preschool’s, into one calendar that each member adds to their own Apple or Google calendar.

• Where it runs: only in your app’s own Google Cloud project. Avokaido does not receive the groups, the calendars or their events.
• What the app keeps: each group’s name and who is in it; invitations, kept as a scrambled code and, if the inviter chose one, the invited email address; the calendar links a group adds; the events from those calendars (title, time, place and description, as the club or school published them); and for each member, a scrambled form of their private calendar address.
• What it never does: sign in to another service for someone, or ask for or keep a password to one. It only reads links a service publishes for subscribing.
• Who it contacts: the addresses in the calendar links a group adds, chosen by the people in the group. It reads them about every 30 minutes.
• How long: events that ended more than 60 days ago are removed at the next read, and a calendar’s events are removed with the calendar. An invitation stops working after 7 days or once it is used. Everything else stays until it is removed in the app or you delete the project.

A merged calendar often shows what children do and where. You decide whether your app has this feature, and you are responsible for it towards the people who use it. That includes telling them, in your own privacy policy, which services the app reads calendars from. If you use an app made with Avokaido, ask the company running it first; we will help them answer.

What we keep

What you see in your workspace: each finding’s file and line with a short excerpt around it (passwords and keys blanked out), short excerpts of the functions and tests we score, and a summary of each change. We keep findings and these excerpts for 12 months after they were last seen, then delete them.

What we don’t keep

Full copies of your repositories. Each build works on a fresh copy in its own container, and the copy is gone when the build ends. Avo Monitor’s temporary copy is deleted within a day.

Trying a change

In Plan › Develop a developer describes a change in a chat, with screenshots if they like, and sees it built. The chat, the screenshots and the links to the pull requests stay in your workspace until the developer archives the session or the workspace is deleted. What is typed there goes to the AI model your workspace uses, like the rest of your code (see AI, below).

The built change gets a preview site on your workspace’s own stage project. It is deleted after 7 days.

For a mobile app, a test build can be streamed from Appetize, a service in the USA, so a developer can try the change on a real device in the browser. The build is unsigned, it is sent only when a developer opens the Phone tab, and Appetize keeps it for up to 7 days before we delete it. We don’t store what appears on the screen. This starts on 5 December 2026, 30 days after we announced it; until then it is switched off.

A developer can also send requests to your own services (stage and production) and read their logs in the Service tab. The requests pass through Avokaido so the developer never holds your credentials. We don’t store what is sent or returned. We keep only who called which address and when, until the workspace is deleted. The log lines are read where they are and not copied.

AI

To do the work, your code is sent to the AI model your workspace uses: Claude unless your admins choose OpenAI, Gemini or Berget. We don’t store what is sent or returned. Our AI providers don’t use it to train models, and neither do we.

Anthropic, OpenAI, Google (paid Gemini API) and Berget each say in their business terms that they don’t train on what we send.

Logs from your apps

If your admins switch on the logs investigator, Avokaido reads the logs and metrics of the Google Cloud projects you connect and of the apps we make and host for you. It only reads them; it never changes them, and it doesn’t copy your logs.

When it finds an error, or users going round in circles, it keeps a short record in your workspace: the error message, how often it happened, the page or request path, and a shortened session id. Never a name or email. It sends the log lines that matter and the code they point to to the AI model your workspace uses, to work out the cause. It files what it found as a feature idea in your workspace, with the diagnosis and the kind of change it would be, so your team decides what to do with it, as with any other idea. It emails the people your admins choose, or your workspace admins, with a link to that idea. It never builds a fix on its own: a fix is built only when someone in your team asks for it, under the same rules as Avo Builder.

Your admins choose who gets these emails: up to 10 addresses, which don’t have to belong to people in your workspace. Left empty, the emails go to your workspace’s owners, admins and IT people. We keep the addresses in settings only our servers can read, use them for these emails and nothing else, and delete them when your admins remove them or the workspace is deleted.

Connecting a Google Cloud project gives our logs investigator read access to that project’s logs and metrics. Remove it in Google Cloud and the access ends. Every app we make for you gives it the same read access when the app’s projects are made, so its errors can be looked at; nothing is read until your admins switch the investigator on.

What to build next, and the documents you give it

Your workspace admins can ask Avokaido to put your team’s work in order: the feature ideas in your workspace, the findings Avo Monitor keeps open, and what the logs investigator filed. It gives each a score and suggests how much of this month’s budget to plan for fixing, for building and to keep back. It is advice: nothing is built or spent because of it unless your admins approve it or switch that on, and then only within the amounts they approved. It never changes your code itself: it asks Avo Builder to build the ideas it ranks highest, under the same rules as any other build. Each run ends in a short proposal of ideas to build now; an admin approves or dismisses it, and the build is requested in that admin’s name. If your admins switch on its morning run, it ranks again each day, but only when something it reads has changed. It builds nothing until an admin approves, unless your admins also let it build on its own: then, for at most 30 days at a time, it approves the morning proposal itself, within the builds a day and the monthly limit they set, and only for ideas your architecture documents say fit. It never builds a fix the logs investigator found on its own, and never a change that needs a developer’s approval. Each build it starts is in your audit log.

To do this, the ideas, findings and health results it orders are sent to Claude, as the rest of your planning is (see AI, above). Your admins can also upload documents for it to read, such as specs and notes on how your system is built: PDF, plain text or Markdown, at most 20 MB each. We keep each document and its text in your workspace, where only your workspace admins can open it. To find the parts of a document that matter to an idea, its text is turned into numbers (embeddings) by Google Cloud’s AI service in Belgium, which doesn’t keep or train on it; the parts that matter go to Claude with the idea. A document stays until your admins remove it or the workspace is deleted. Each result keeps a short quote of at most 200 characters from a document it relied on, and results are deleted 90 days after they were made.

Your own privacy policy and terms

Avo Monitor’s Privacy & terms check reads your public privacy policy and terms of service, from the addresses your admins give or found on the websites your workspace monitors, and compares them with what your code handles: personal data, outside services and how long things are kept. To read the pages it sends their text, and the names of the services it found in your code, to Claude. It never sends your code for this check. It keeps the latest reading, replaced on every run: which pages it found, when they say they were last updated, which sections they have, and where in your code it saw personal data or an outside service. Its findings are kept with your workspace’s other findings.

From a finding, someone in your workspace can have the Cloud Runner draft the change to your policy’s text as a pull request in your own repository, for you to review, or file the finding as a ticket in Linear or Jira, if you connected one. Either way, the finding, your policy’s address and the place in your code it points to go with it.

6. The suggestion box on our customers’ websites

Our customers can put a suggestion box on their own websites. If you use one, the company running that website is responsible for your data. We handle it for them.

• What we collect: what you type, files you add, screenshots only if you choose to share your screen, your name and email only if you give them, and the page you were on (without the rest of the address).
• AI: an AI helps turn your message into a clear request. A separate AI reads the website’s code to understand what you mean. The chat itself never sees that code.
• Who can read your chat: the company’s admins can read your conversation with the box in Avokaido, also one you never sent, for as long as it is kept (30 days if never sent, 180 days if sent). An AI (Claude, by Anthropic) writes them a short summary of it and, once your suggestion is built, notes where what you asked for and what was built differ. The box tells you this in one line. Other members of the company’s team can’t read it. We don’t use it for anything else.
• A copy of the page, if the company has turned this on: before you send, the box can show your change on the page you are on. To do that, it copies that page as you see it: when you ask to see your change, or as soon as your suggestion is ready if the company chose that. What you typed into fields is left out, and anything that looks like an email address or phone number is replaced. An AI draws your change into the copy, in named parts you can switch off one by one, and writes one sentence saying what it changed, which is shown to you beside it. The copy, the edits that draw your change into it and that sentence are kept only as long as the before-and-after link works (at most 72 hours), or with the suggestion if you confirm it and the company keeps confirmed previews. If you confirm a version and the company keeps confirmed previews, what you confirmed, including the edits that drew it, goes with your suggestion and into the instructions for whoever builds it, which may be an AI the company uses; it is kept as long as your suggestion. To make the box better, our server logs also note how you looked at it: whether you opened it large, how you compared, for how long, and which reason you picked if you asked for another version. Never what you typed. Server logs are kept for 30 days.
• Questions about the website, if the company has turned this on: the box can also answer simple questions, like where a page is or how to do something, from a short guide the company keeps about its own website. An AI sorts your message into a question or a suggestion, and sees only that guide, never the website’s code. If the website has signed you in and tells the box so, the box uses the role the website gave you to choose which pages it may tell you about; it does not keep that role. The company’s admins can see the questions people asked for 30 days, with anything that looks like an email address or phone number removed, and whether the person asking was signed in or one of their own team, never who.
• Help on the page you are on: the box can help you use the website or app you are in. It answers how-to questions, and when you ask, it points at the right control or clicks, types and moves between pages for you. It asks you first before anything that submits a form or deletes something. To do that, it reads an outline of the page as you see it: headings, labels, the text on buttons and links, and what is in form fields, but never password, payment or one-time-code fields, hidden fields, or anything the company marks private. Anything that looks like an email address or phone number is replaced before the outline leaves your browser. You can also click a part of the page to ask about it; an outline of just that part, by the same rules and at most 2,000 characters, goes with your question. To answer a “why” question, like why something is not connected, the box may look up a fact the website or app offers about itself for this, such as a connection’s state. Only lookups the company built into its own website or app can be used, they only read, and the answer is cut short (at most 4,000 characters) with anything that looks like an email address or phone number replaced. The outline, the part you picked and any fact looked up are sent to an AI (Claude, by Anthropic) with your question and are not stored; a fact looked up is not written to our logs either. Only a short label for each step the box carried out, like “Add destination”, is kept, with your conversation and for as long as it.
• Things the box can’t add yet: if you ask for something Avokaido can’t build in yet, like SMS messages, Avokaido counts that the wish was made on this website, for its own planning. Your words are not kept for that (what people ask for that Avokaido can’t do yet).
• Spam protection: a scrambled version of your IP address, kept for one day.
• In your browser: the box remembers your conversation so you can come back to it.

7. How we use personal data

• To run Avo Monitor and Avo Builder
• To book and hold demos
• To bill you and keep the books
• To answer support questions
• To decide what to build next, from what people ask for that Avokaido can’t do yet
• To keep Avokaido safe and stop abuse
• To see which parts of the website and app are used, so we can improve them

8. AI and your own keys

Your admins choose which AI models are used. You can use our AI access, or add your own keys for Anthropic, OpenAI, Gemini or Berget. Berget runs in Sweden. With your own key, your contract with that provider applies to what is sent.

The same goes for services you connect with your own account, such as Vercel or Supabase for hosting: they work for you, under your contract with them.

9. Cookies and visitor statistics

Our own visit counter

It uses no cookies and stores nothing on your device. Each visit gets a random number that lives only in the page’s links, so we can see how a visit moved from page to page. These records are kept for 90 days.

Google Analytics and Google Ads, only after you click Accept

Before you choose, nothing is sent to Google. If you click Accept, Google Analytics counts how the site is used, and Google Ads tells us which ad led to a booked demo. If you click Decline, neither loads.

The Avokaido app asks separately before it turns on its own analytics.

10. Who helps us

We share only what each service needs to do its job. The full list, with what each one gets and where it is, is on our list of outside services.

Google Cloud (hosting and storage), Anthropic (AI), OpenAI, Gemini and Berget (AI, only if chosen), GitHub, Stripe (payments), SendGrid (email), Google Workspace (our own email and calendar, including demo invites), Linear and Jira (only if connected), Appetize (streamed test devices for mobile apps, only when a developer opens the Phone tab, from 5 December 2026), Google Drive and Microsoft OneDrive and SharePoint (files your app saves, only into an account its user connects, from 10 December 2026), Google Analytics and Google Ads (only after Accept).

11. Data outside the EU

Avokaido’s database, files and servers run on Google Cloud in Belgium. Some services we use are American. Google, Microsoft, GitHub, Stripe, SendGrid and Atlassian (Jira) are in the EU–US Data Privacy Framework, and their contracts add the EU’s standard contract clauses. Anthropic, OpenAI and Linear are not in that framework, so for them we rely on the standard contract clauses in their data processing agreements. Appetize (USA, from 5 December 2026) is covered the same way. Berget keeps data in the EU. Each one is on our list of outside services.

12. How long we keep it

13. How we protect it

• Encrypted on the way (TLS) and when stored (Google Cloud)
• Each build runs in its own container
• Each workspace sees only its own data
• Roles for who may build, review and approve
• Passwords and keys blanked out in findings
• Access keys to your code last one hour
• Sign-in links into the project wizard only lead back to Avokaido, never to another site
• Only Avokaido staff who need it can see customer data

Found a security problem? Write to security@avokaido.com.

14. Your rights

You can ask to see the data we have about you, correct it, delete it, get a copy to take elsewhere, object to how we use it, or take back a yes you gave. Write to privacy@avokaido.com. You can also complain to IMY, the Swedish privacy authority (imy.se).

15. Children

Avokaido is made for businesses and is not meant for anyone under 16.

16. Deleting your account or workspace

You can delete your account or a workspace in the app. Nothing is removed for 30 days, so a mistake can be undone. After that it is deleted, except payment records, which the law makes us keep for 7 years.

17. Changes to this policy

When we change this policy, we update the date at the top. If a change matters to you, we tell you by email or in the app first.

Contact

• Privacy questions: privacy@avokaido.com
• Security issues: security@avokaido.com
• Help with Avokaido: support@avokaido.com