Privacy, in plain English

The short version

Everything below is the same story with the details filled in. It's written to be actually read, because a privacy policy nobody can read isn't much of a promise.

Who we are

Second Bell Studio is a small, founder-run studio based in Massachusetts: hands-on AI build cohorts for teachers and for students ages 14–18, plus partnerships with schools. "We" in this policy means the studio and its founder, Chris Meehan — there's no data team, no marketing department, and no one else reading your application.

This policy covers the website at secondbellstudio.com, the application process, the Build with AI teacher cohort, the Summer Build Studio student cohort, and the newsletter. School partnerships involve a written agreement with the school, and where that agreement says something more specific about data, the agreement wins.

What this site collects: almost nothing

Browsing this site sends us no personal information. There is no analytics script, no advertising pixel, no fingerprinting, and no cookie banner because there are no tracking cookies to consent to.

• Three small preferences live in your browser's local storage — your day/night theme, whether the bell sound is on, and whether you've seen the lamp hint. They never leave your device, and clearing your browser data removes them.
• Our web host keeps standard server logs (IP address, page requested, time) for security and uptime, like nearly every site on the internet. We don't use them to identify or profile visitors.
• If you email us, we have your email — because you sent it. We use it to reply.

When you apply or enroll

The programs are where real information changes hands. Here's exactly what, and why.

Teacher applications

The application form asks for your name, email, school and role, your coding background, the classroom problem you want to solve, how you're paying, and how you heard about us. We use it to read your application, calibrate your build path, and — if your school is paying — send your business office an invoice and W-9.

Student applications

The application asks the student for their name, age, email, coding background, what they'd want to build, and something they've finished. It asks the parent or guardian for their name, email, and phone number. We use the student's answers to judge fit and scope a project, and the parent's contact details to schedule the fit call, run enrollment paperwork, and reach you about anything urgent during the cohort. The parent's phone number is used for exactly that — never marketing.

Payment

Payments run through Stripe. Card numbers go to Stripe, not to us — we never see or store them. What we keep is the receipt-level record: who paid, how much, and when, because tax law requires it.

Calls & the newsletter

Booking a call through our scheduling link shares your name, email, and chosen time. Joining the newsletter shares your email, which is used for one email a month and nothing else — every issue has an unsubscribe link that works on the first click.

Applications that don't lead to enrollment are deleted — see how long we keep things.

Students & families

The Summer Build Studio is for builders 14–18, which means most participants are minors. That shapes how everything here works.

• A parent or guardian completes enrollment. The application has a required parent section, the fit call includes a parent, and the enrollment paperwork — including written consent for a minor to participate — is signed by the parent, not the student.
• Parents can see everything. Every session is recorded and any recording is available to parents on request. Parents may sit in on any session without notice. There are no private DMs — all written communication runs through a shared project space parents can join.
• Parents control their student's information. A parent or guardian can ask to review, correct, or delete their student's personal information at any time by emailing hello@secondbellstudio.com. Deletion during an active cohort may mean withdrawing from the program, and we'll talk that through with you first.
• We collect the minimum. No birthdates beyond age, no addresses, no school records, no grades. If we don't need it to run six good weeks, we don't ask for it.

Session recordings

Live sessions run on Zoom and are recorded. This is a deliberate safety and transparency choice, not a content-production one:

• Who can access them: the participant, their parent or guardian (for student sessions), and us. Teacher-cohort recordings are shared with enrolled teachers in that cohort so anyone who misses a session can catch up.
• What they're for: catch-up, parent transparency, and reviewing a build step. Nothing from a session appears anywhere public without a signed release.
• Sometimes we share a moment publicly — with written permission. A testimonial quote, a screenshot, or a short clip of a build may appear on the build wall or in something promotional, but only under a media/testimonial release signed at enrollment. The release spells out what can be used and how the participant is identified (first name or initials if you prefer), and you can revoke it for future uses at any time; we'll also take down existing uses where we reasonably can. No release, no excerpt.
• Where they live: in access-controlled storage, not on a public link.
• How long: recordings are kept for one year after the cohort's final session, then deleted — long enough for families to request copies and for released excerpts to be pulled, not an indefinite archive. Parents can request a copy any time before deletion, or earlier deletion of any session their student appears in.

Student work, demo day & the build wall

The whole point of the studio is shipping something real — and "real" means public. Here's where the line sits between your work being public and you being public.

• Deployed apps are public by design. Every student ships to a public URL. We coach builders to keep personal information — their own and other people's — out of what they ship. The app is public; the builder's personal details don't have to be.
• Demo day has invited guests. Family, friends, and anyone the family chooses to invite. We don't livestream or publish demo day.
• The build wall and testimonials run on written permission. When a project hangs on our build wall or a quote appears in our marketing, it's because the participant — and for students, a parent or guardian — signed a media/testimonial release at enrollment. The release spells out exactly what appears (project name, what it does, and how the builder is identified). You can limit a student to first name or initials, and a parent can revoke a release for the future at any time by emailing us.

The services we rely on

We're a one-person studio, so a handful of well-known services do the plumbing. They process data on our behalf, under their own security and privacy commitments, and only for the purpose listed.

That's the complete list of who we share personal information with, plus the two cases every honest policy has to name: if the law compels us, or if the studio is ever sold or restructured (in which case this policy's promises travel with the data, and we'd tell you). We do not sell personal information, we do not share it for advertising, and there is no third-party "marketing partner."

Tools you'll use while building

During a cohort you'll create accounts on tools we don't run — that's the point: you leave owning your own stack. Those accounts are yours, governed by each tool's own privacy policy, not this one.

Typical examples: GitHub for code, a hosting platform like Vercel or Netlify, and an AI assistant like Claude or ChatGPT. Two things we do about that:

• For students, accounts are set up with the parent. Most developer tools require users to be 13 or older, some require parental permission for minors, and a few are 18+ with a workaround through a parent-held account. We flag the age rules for each tool we use during setup week and recommend the parent create or co-manage the accounts.
• We coach data hygiene from day one. No real personal data in test databases, no secrets in public repos, no classmates' information in a project. It's in the curriculum because it's the habit that matters most later. Our field manual on student data & the law is the long version.

For teachers & schools (the FERPA part)

Teachers and school leaders rightly ask where student records fit into all this. The clean answer: they don't.

• We're not a school and the cohorts need no education records. Nothing in the teacher cohort requires real student data — names, grades, IEPs, rosters, anything. Builds use sample or synthetic data, and we'll hand you a fake gradebook before we'll let you upload a real one.
• Teachers agree not to bring student records into cohort sessions or tools. Pasting a real roster into a consumer AI tool can be a FERPA disclosure your school never authorized. We teach the compliant pattern instead: build and test on sample data, then deploy through your school's approval process. The student data field manual walks through exactly how.
• School partnerships are governed by written agreement. If a Faculty + Stack Partnership ever involves access to student data, that access is defined in the agreement with the school — scope, security, retention, deletion — and we act only as the school directs, consistent with FERPA's school-official requirements. By default, partnerships are about faculty training, policy, and stack audits, none of which require student records.

How long we keep things

Default: as short as we can defend, then deleted. The specifics:

Ask us to delete something sooner and we will, unless a signed consent or a tax record legally has to stay.

Your rights & choices

You don't need a legal basis to ask us something reasonable. Email hello@secondbellstudio.com and we'll do it — these rights are for everyone, not just where a statute requires them:

• See it — ask what personal information we hold about you or your student, and get a copy.
• Fix it — correct anything inaccurate.
• Delete it — subject only to records we're legally required to keep.
• Stop hearing from us — unsubscribe from the newsletter any time; we don't do marketing email beyond it.

We'll answer within 30 days, usually much faster, and we'll never charge for a request or treat you worse for making one.

If you're in California

We don't sell or "share" personal information as the CCPA defines those terms, and we never have. The access, correction, and deletion rights above match what the CCPA grants, and we extend them to everyone regardless of the law's business-size thresholds.

If you're in the EU or UK

The studio is US-based, the cohorts run on US hours, and we don't target the European market — but if you reach out from the EU or UK, the data you send is processed in the United States on the basis of your consent or our steps to fulfill what you asked for (GDPR Arts. 6(1)(a) and (b)). The rights above cover GDPR's core requests — access, rectification, erasure — and you can lodge a complaint with your local supervisory authority, though we'd rather you just email us first.

Security, changes & contact

Security: accounts protected with strong, unique passwords and two-factor authentication, recordings and paperwork in access-controlled storage, and a strict data-minimization habit — the safest data is the data we never collected. No system is perfect; if a breach ever affects your personal information, we'll tell you directly and promptly, not in a footnote.

Changes: if this policy changes in any way that matters, we'll update the date at the top and — for enrolled families and cohort members — tell you by email before the change applies to you. We won't quietly swap promises.

Contact: hello@secondbellstudio.com. A human answers, and it's the same human who wrote this policy.