What we learned after shipping a GDPR-compliant EdTech SaaS

Body

Building software for schools is very different from building software for developers or startups.

We recently finished an EdTech SaaS focused on digital report cards, document workflows, and privacy-first AI features for schools.
The product is live, technically stable, and used in real environments — so this is not a “build in public” story.

Instead, I want to share a few lessons learned after the product was already done.

1. “Finished” is not the same as “ready”

From a technical perspective, the product was complete:

• core features implemented
• infrastructure stable
• performance acceptable But for schools, that is only the starting point.

What really matters:

• documentation quality
• predictable behavior
• very clear workflows
• zero surprises during grading or report generation Schools don’t want flexibility first — they want reliability.

1. GDPR is not a checkbox, it’s a design constraint

When people say “GDPR-compliant”, they often mean:

“We added a privacy policy and a consent banner.”

That is not enough.

For us, GDPR affected:

• data models
• logging strategies
• AI feature design
• support workflows
• even how errors are handled Especially in education, privacy is not negotiable. Designing for GDPR early saved us from painful refactors later.

1. AI features must feel boring (and that’s good) We use AI to assist with things like:
2. structured text generation
3. report card wording
4. document consistency But teachers don’t want “magic”. They want:
5. predictability
6. control
7. the ability to review and adjust everything

The best feedback we got was:

“It doesn’t feel like AI — it just helps.”

That’s exactly the goal.

1. Selling to schools is mostly about trust Technical excellence matters — but trust matters more. Schools ask questions like:
2. Who hosts the data?
3. Who has access?
4. What happens if something goes wrong?

5. Will this still exist in 5 years?
   Clear answers beat fancy features every time.

6. Building is easier than explaining
   One unexpected challenge:
   Explaining a finished product clearly is harder than building it.
   Especially when:

7. you don’t want to reveal internal details

8. you don’t want to oversell

9. you want to stay honest and transparent
   This is something we’re still actively improving.

Closing
This post isn’t meant as advice or promotion — just a reflection.

If you’ve worked on:

• EdTech
• privacy-sensitive software
• or products for non-technical users I’d be interested to hear what you learned after shipping.