I'm keeping implementation specifics private for now. This section is about product direction and why we're building it this way. Happy to go deeper in conversation.

If you've ever been about to take a class you were nervous about, you probably noticed you didn't know anyone else in it. And if you've ever joined LinkedIn as a student, you probably noticed it's a weird place to be a student: a platform built for people who already have careers, and you're staring at it with a half-empty profile wondering what you're even doing there.

Circle started from a handful of observations like that. The existing tools for academic life are scattered across a dozen apps (Discord for one thing, Notion for another, LinkedIn when you feel brave). None of them really let you connect laterally with your peers in any meaningful way. That's the gap we're trying to fill.

We've done 50+ interviews with professors and 100+ with students across different programs, asking what their actual workflows look like, where the friction is, and what they'd want a tool to do for them rather than guessing from the outside.

The three-pillar product was shaped against that research, not a whiteboard. Every feature scope decision (which study-group mechanics to build, what an institutional org hub really needs, where AI-assisted scheduling helps vs annoys) ties back to a recurring pattern from those conversations.

The product is organised around three things that reinforce each other rather than competing for attention:

Connecting with people who are doing the same thing as you, in small groups that you actually want to spend time in.

Having a workspace inside the platform that makes it easier to do your work — study timers, accountability, team goals, that kind of thing. Less friction between 'I should start' and 'I started.'

Making it easy to be visible to the right people — peers, mentors, recruiters, institutions. Your profile does the heavy lifting.

For the user side, the hope is that you come in and realise you can stop using four other apps. The job a student does every day shouldn't be spread across Discord, a task manager, a calendar, and LinkedIn.

For institutions, it works more like a GitHub organization — a central place where a university department, a fraternity, or a program can communicate top-down, hand out deadlines, run analytics, and hook into their own systems via API. That's also the part of the business that makes the free side possible to keep free.

We work in short sprints, write tests before code where it makes sense, keep CI/CD in place from day one, and keep documentation as lean as we can without it getting useless. None of this is flashy, but it's what separates a project that works for a few cohorts from one that falls over the first time something unexpected happens.

Currently in the design phase. Not at beta yet, but already accepted for a small beta testing run with real student users in real classrooms once we get there. The pilot pathway and willing partners are lined up; we just need the product to be ready for them.

The rough forward path: finish the design phase, build to beta, run the classroom pilot, iterate, and then move toward a more complete product and a first institutional partner in Alberta.