Privacy — Piplab

What we collect

From the grown-up who opens an account: a name, an email address, and a password. The password is stored only as a scrambled hash — we cannot read it back, and neither could anyone else.

From a child: a first name (whatever their grown-up typed) and a username. That is the whole list. A child is never asked for an email address — our database requires one on every account, so a child's record carries a made-up address ending in @child.piplab.invalid. The .invalid ending is reserved by internet standard specifically so an address can never exist: it cannot receive mail, is never shown to anyone, and is never used for anything. We mention it because a policy that skipped it would be leaving something out.

What a child makes while using Piplab:

Their builds — the code and files they write — and the saved versions of each build.
Their conversations with Pip, the AI assistant, so they can pick a project back up where they left it.
Their challenge attempts: which challenges they tried, the marking results, and the answers they typed to the two understanding questions.
Their lesson progress on the learn tracks.
Records that their own apps save — if a child builds an app with a database, the entries that app stores live with the build and are deleted with it.

From anyone who writes to us: the name, email, topic, and message from the contact form.

From your browser: one session cookie, which keeps you signed in. It is not used to track anything.

We do not collect any other personal information from a child. That sentence is meant exactly as written.

What we never collect

No child email addresses or phone numbers — there is nowhere in the product to enter one.
No location. We do not ask for it, and Pip refuses to help build location tracking — ask it for GPS and it explains the board has no way of knowing where it is.
No photos, audio, or video of a child. Nothing in sign-up or the product ever asks for one. Camera and microphone gadgets run in the child's own browser and start only when the child presses a button; what they capture is shown on the child's screen, not sent to us.
No birthdates, no school records, no browsing history.
No advertising and no ad-tech — nothing on Piplab is trying to sell a child anything.
No analytics and no trackers. There is no Google Analytics, no pixels, no fingerprinting, and no third-party tracking script anywhere on the site. The only outside services involved at all are the fonts this site uses (loaded from Google Fonts by your browser, like most of the web) and the AI provider described next.

And we never sell or rent personal data or a child's work. To anyone. Under any name for it.

Where the AI fits

Pip is powered by an outside AI service that we call from our own server. Three things go to it, each because the product cannot do that job locally:

Chat and code help — the conversation so far and the code of the build being worked on, so Pip's answers are about the child's actual project.
The plan wizard — the child's project idea, so the wizard can ask sensible questions about it.
Challenge marking — the child's build files and their typed answers, so the marking can quote their real work back at them.

What never goes with any of that: the child's name, username, email, account details, or anything else that says who wrote it. Every request is made from our server, not from the child's device, so the provider does not see the child's device or network address either. From its side, each request is code and words from an anonymous account of ours.

The provider's own handling of requests is governed by its terms, which is exactly why we send it nothing that identifies a child. What Pip will and won't help with is a separate page — the safety page — and the short version is that it only helps build things.

Publishing & public pages

Everything a child makes is private by default: visible to the child, and to the grown-up who made their login. Publishing is the one exception, and it is deliberately hard to reach:

A published build appears at a public address under a maker handle — a playful generated name that never contains a surname. The public page shows the handle, a first name, and the published builds. Nothing else about the child appears anywhere public.
A build is only public if it was published and the account is allowed to publish. Every child login created by a grown-up starts with publishing switched off.
The check happens every time a public page is opened, not just at the moment of publishing — so if publishing is switched off for an account, everything already published disappears from the public site at the same moment.

There is no switch in the product yet for turning publishing on for a child login. If you want your child's work on a public page, ask us — we would rather that road run through a conversation for now.

If you are a parent

You create your child's login yourself, on your own account page: you type their first name, pick their username, and set their password. Piplab never interacts with your child to set any of this up, and never contacts them — it has no way to.

You hold the keys afterwards, too. Your child's builds open for your account as well as theirs — read-only, so you can always see what they are making but cannot accidentally change it. You can see their public page if they ever have one, and if they forget their password, you set a new one from your account page. We never see or show the old one; like every password here it is stored scrambled.

If you want your child's data gone, that request is yours to make — see keeping & deleting below.

If you are a tutor or run a club

You create student logins in bulk from a list of first names. Each student gets a generated username and a readable password; the passwords are shown to you once, at creation, and stored only as hashes from then on — a lost sheet means a reset, which you do from the class page.

You can open your students' builds and see their challenge marking, because that is your job. You cannot edit their work — the server refuses every write to a build that is not your own, so a student's build is theirs even from their tutor's chair.

Consent is yours to obtain, and we want to say that plainly. Piplab has no way to contact your students' parents — we do not know who they are, and that is by design. So when you create logins for other people's children, it is your responsibility to get their parents' permission first, the same way schools do for classroom software. Tell parents what Piplab is, point them at this page, and keep a record of their yes. A written yes is best. There is no in-product consent flow yet; until there is, this paragraph is the honest description of how consent works, and if a login was ever created without it, tell us and we will delete that student's data promptly.

Keeping & deleting

We keep a child's work for as long as the account exists, because the whole point is that their builds are still there next week. Deleting works like this today:

Builds: the owner of a build can delete it themselves, from the editor. Deleting a build removes its code, all its saved versions, the records its app stored, and its chat with Pip.
Accounts: there is no self-serve account deletion yet. Ask us via the contact form and we will delete the account and everything attached to it within 30 days. A parent can ask for a child's login; a tutor can ask for a student's.
Contact messages: kept so we can reply and remember what we promised you; ask and we will delete yours.

Where data lives

Everything described above lives in a single database on Piplab's own server — not scattered across analytics platforms, marketing tools, or customer-data brokers, because we use none of those. Piplab is made and run in Anguilla.

One more thing worth knowing: email only ever goes to grown-ups, and only about their own account. A welcome when you sign up, a link when you ask to reset your password, a security notice when your password or sign-in email changes, and — for tutors — a note when a parent completes a consent form. No newsletters, no marketing, and nothing ever addressed to a child: a child's login has no email address at all, so there is no inbox of theirs for anything to arrive in. Sending is handled for us by Mailgun, which sees the address and the message it is delivering and nothing else.

Changes & contact

Piplab is built around the principles that children's privacy laws like COPPA and GDPR exist to protect — collect the minimum, show no ads, track nothing, and put a known grown-up in charge of every child's account. We describe our practices here rather than claiming legal certifications, and if a practice changes, this page changes with it: the date at the top moves, and a meaningful change gets flagged on the site, not buried.

Questions, worries, or a request about your data: the contact page reaches us, and hello@piplab.ai is the same inbox.

This page is written in plain words on purpose — a privacy policy a parent cannot read is not protecting anybody. If anything here is unclear, ask us.

Privacy policy