Orbit Logo

Orbit, Student Hub

A self-hosted dashboard for schedules, study sets, assignments, and student chat.

Live (when available): orbit.vlad-p.com
Repo: github.com/vafc21/orbit

Inspiration

School apps usually do one thing well and five things badly. Schedules live in one place, assignments in another, flashcards somewhere else, and messaging is either distracting or disconnected from classes.

I wanted one hub that feels calm and practical: open it, instantly see what’s next, what’s due, and what I should study, without getting sucked into a feed. Orbit started as a “student OS” idea, a single dashboard that matches how students actually plan their day.

What I built

Orbit is a local-first, self-hosted student hub that combines:

Schedule dashboard
A weekly schedule view, class cards, and a “next up” style focus section.
Study sets
Create flashcard sets, bulk import cards, and study using multiple modes (flashcards, practice, test, match).
Assignments / to-dos
Track tasks tied to classes, with due dates and completion states.
Chats and friends
Built-in class chats, DMs, and friend requests so the hub can replace scattered messaging.
Profiles
Shareable student profile and a friend schedule view concept.

The goal is not to be “every app,” it’s to be the single place you start your day.

How I built it

I built Orbit as a lightweight web project: static pages for the UI and a small Python backend for running locally and saving data.

Architecture (high-level)

Frontend: HTML/CSS/JS pages (landing, sign-in, dashboard, user profile, etc.)
Backend: a Python server that handles routes and stores local data
Storage: simple JSON files (and folders for chat-related data)

This approach keeps the project:

fast to iterate on,
easy to self-host (including on a Raspberry Pi),
understandable for other students who want to contribute.

A small math model I used while designing the schedule view

To keep the “What’s next?” panel accurate, I thought of the day as a set of time intervals. Each class is an interval ([s_i, e_i]). Given the current time (t), the “next class” is the class with the smallest start time that’s still in the future:

[ \text{next}(t) = \arg\min_i {\, s_i \mid s_i > t \,} ]

And the time remaining until it starts is:

[ \Delta(t) = s_{\text{next}(t)} - t ]

I didn’t need a heavy algorithm, but writing it down helped me keep the logic consistent as I added activities and different schedule styles.

Challenges I faced

1) Keeping the UI calm while adding features

Every feature is tempting to “surface everywhere,” but that makes the dashboard noisy. The hard part was deciding what should be visible by default versus tucked into a tab.

What I did:
I focused the home screen on three things: what’s next, what’s due, what to study.

2) Data design without overengineering

I wanted local-first storage without setting up a full database at the start. But I still needed the structure to be future-proof.

What I did:
I used JSON for simplicity while keeping the data shaped like it could later be moved into a database without rewriting everything.

3) Scheduling logic (real schools are messy)

Schedules aren’t always “same classes every day.” There are A/B days, block schedules, assemblies, and special events.

What I did:
I built the schedule as flexible blocks and planned for multiple schedule styles from the beginning, even if the UI starts simple.

4) Chat + privacy decisions

Messaging systems are complicated, and I didn’t want to accidentally design something unsafe.

What I did:
I kept chats lightweight and treated privacy as a real requirement, storing data locally and designing the structure so it can be improved (permissions, moderation, encryption improvements) as Orbit grows.

What I learned

Shipping beats perfection: building a real, working hub taught me more than planning forever.
Good UX is mostly choosing what not to show: clarity comes from removing noise.
Local-first is underrated: a project feels more “yours” when it runs on your own hardware.
Simple architecture can still be powerful: you don’t need a giant framework to build something useful.