Case study / Product engineering

Ciiircle: an academic product built around circles

A bilingual academic collaboration product with parent circles, operational workspaces and a permission-aware AI assistant. The case study separates implemented work from launch-readiness gaps.

In active development — readiness reviewed 22 October 2026

Ciiircle product branding with three workspace illustrations.
On this page
  1. Context and product premise
  2. Role and scope
  3. Key product and engineering decisions
  4. Architecture and evidence in the repository
  5. Constraints and tradeoffs
  6. Current status and limits
  7. Related work

Context and product premise

Ciiircle is an academic collaboration product for teachers, learning centres and communities. Its product premise is to keep people, learning activity and shared materials in a related workspace rather than spread across disconnected tools. That premise is reflected in the product architecture; it is not a claim from a published user-research study.

The product uses a two-level model. Parent circles handle the organization and its membership. Child workspaces hold operational activity such as tasks, resources, calendars, chat, announcements and quizzes. The public product is branded Ciiircle; the source repository is titled Ciiircles Academic OS.

Role and scope

I worked across product design and implementation: the React and Vite interface, the NestJS API, the PostgreSQL and Prisma data model, Arabic/English layout, and the Gemini-powered Neo integration. The repository also contains CI, automated tests, deployment documentation and operational monitoring code.

This is a personal product build. The scope describes implementation visible in the source; it does not imply that every workflow is complete or that the product has passed a general launch gate.

Key product and engineering decisions

Separate organization governance from workspace activity

The parent/child hierarchy gives an organization a place for membership and governance while keeping daily work inside a workspace. This keeps the product's main metaphor—circles—intact and leaves room for different learning groups without introducing a separate product mode.

Keep Neo inside the access model

Neo is an AI assistant built around Gemini and product tools. Its conversation context distinguishes organization and workspace modes. Tools execute against the signed-in person's permissions; the model's instructions are not treated as authorization. Some write actions are prepared as proposals for a person to confirm.

Treat Arabic and English as interface requirements

The product has Arabic and English surfaces with right-to-left and left-to-right layouts. Direction affects the arrangement and reading order of controls, not just translated strings.

Architecture and evidence in the repository

  • Frontend: React 19, Vite, TypeScript and Motion.
  • API: NestJS 11 with PostgreSQL and Prisma.
  • Realtime collaboration: Socket.IO.
  • AI: Gemini-backed Neo with scoped tools and context modes.
  • Operations in source: CI workflows, automated tests, k6 scenarios and Prometheus/Grafana configuration.

The 22 October 2026 readiness review counted 19 registered backend modules and 142 HTTP route definitions in the local source. Those are inventory counts, not user outcomes or a measure of completeness, so they are not presented as product success metrics.

Constraints and tradeoffs

Access boundaries matter more in an educational product than a polished AI demo. Neo's tools need to honor the same membership and workspace rules as the rest of the API. File access, submissions, grades and account data also need consistent visibility rules.

The product's hierarchy and collaboration foundation are substantial, but a foundation is not a complete learning-management system. The current product still needs a reliable gradebook and a clearer structured-learning and progress path. Correctness and privacy work also remains before a broader launch.

Current status and limits

As reviewed on 22 October 2026, the public site and API were responding, but the deployment was not ready to be described as a complete LMS. The deployed gradebook route was unavailable, while source and tests showed more functionality than the deployment. The readiness review also identified submission integrity, grade consistency, privacy and operational issues for follow-up.

That distinction matters: a reachable URL proves availability at the time checked, not that every feature is live, complete or ready for general use. The project remains in active development, and I do not attach a completion percentage to it.

Related work

The accompanying article explains how I review AI-generated changes for authorization, race conditions, duplicate requests and edge cases. The relevant service is AI integration and workflow design with permission boundaries kept in the application.

Working on a product or workflow like this?

Ask about AI integration