Building ORBIT: My Personal Planning App

From a chaotic brain dump about astrophysics, muay thai, and career anxiety to a fully deployed, cloud-synced scheduling app here’s how it happened, what it runs on, and what broke along the way.

From brain dump to shipped app

I didn’t sit down one afternoon and decide to make a scheduling app. I’d tried plenty before either too complicated or too limited. Then one frustrated night around 11:30 p.m., I dumped into a chat session everything that was on my mind: life goals, two active research projects, a to-do list, and as I was told – a laughably ambitious plan to recap special relativity and then study Nakahara and Sean Carroll in three months, while holding a 9-5, plus a backstory spanning three countries and two careers (yes, i thought context was relevant at that point).

The prompt that kicked everything off looked something like this:

help me make an app that i could use to manage my daily, weekly and monthly schedule and keep track of tasks, prioritize

[followed by a full life brain dump: Artemis 1 simulation wrapping up, flood prediction ML project, taxes this weekend, my name fixed on all government IDs Monday, physics syllabus from Taylor & Wheeler SR through Sean Carroll GR, I really want to make time to study Nakahara to better develop my mathematical toolkit before Sean Carroll, oh I also have a 9–5 job so account for that..]

I needed something personal enough to reflect my actual life – not another generic Notion template (I’ve tried several; it never sticks) or a Google Calendar with color-coded events alone. I wanted tasks nested inside projects, study tracks that behaved like long-running efforts, a calendar that reflected my real recurring schedule, and a vision board for hard days, or things I will schedule later.

That’s ORBIT: a personal command center that treats your week like a mission plan. Every feature exists because I needed it – not to pad a feature list.

ORBIT came together across two intensive stretches plus polish. Elapsed time from first scaffold to deployment was roughly one focused day (~8 hours) – deep sessions with AI as an implementation partner. Without that, the same scope would likely have taken me weeks solo.

1. Scaffold and first version: React app, localStorage persistence, dark theme, hardcoded schedule blocks.
2. Feature expansion: Drag-and-drop reordering, inline editing, due dates, progress, dynamic calendar blocks, study tracker, vision board, categories.
3. Pivot to the Google ecosystem: Google Drive appDataFolder, OAuth, Calendar push, environment configuration.
4. Polish: Three calendar views, collapsible sidebar, clearer errors, search, Demo Mode for visitors.
5. Ship: Hostinger subdomain, SSL, SPA rewrites, OAuth authorized origins, production build.

What ORBIT does (and how I run my week)

Most days I start from the dashboard: top priorities, what projects are active, the date, and a small quote – enough context to choose what matters before I dive into execution.

For operations, I lean on the calendar: weekly view for layout, daily for “what’s next,” monthly for horizon scanning. I create time blocks with real start/end times and titles; when I’m signed in with Google, I can push blocks to Google Calendar so reminders land where I already live. I can even sync my whole week (pull and push events and tasks!)

Tasks aren’t the same as projects or study tracks. Finishing a task moves a project forward; finishing a chapter or module moves a study track. I link tasks to parents where it matters, so progress rolls up instead of living in a flat list that ignores structure.

Feature groups

Planning surface

• Dashboard: Priorities, project snapshots, date, daily quote.
• Calendar (three views): Weekly timeline, daily list, monthly grid.
• Collapsible sidebar: Full and compact workspace; vision board anchors visible when I need the long view.

Entities

• Task board: CRUD, deadlines, top-three priorities, links to projects or study tracks.
• Projects: Medium-term milestones with auto-computed progress.
• Study tracker: Long-form learning tracks (books, chapters, articles as tasks).
• Vision board: Up to three long-term anchors.
• Custom categories: Shared taxonomy across tasks, projects, and study items.
• Search: Cross-entity search.

Data and sync

• Demo Mode: Seeded data from demoTemplate.json, persisted in localStorage – no OAuth required to try the full UI.
• Google Mode: User-owned sync via Drive and optional Calendar push (disabled in Demo Mode).
• Data tools: Import/export JSON, cleanup helpers.

Polish

• PWA tooling in the build so the app can feel app-like when installed – still static hosting, no server runtime.

Calendar in detail

The calendar evolved from hardcoded JSX strings into a dynamic block model: create blocks in the UI, set start/end times, titles, and optional links to tasks. Each block renders in the correct slot; in Google Mode, “Push to Google Calendar” sends blocks into my real calendar.

Task, project, and study linkage

Tasks can attach to a project or a study track. Progress on tasks rolls up to parents, so project and study completion reflect actual work – not manual percentage tweaks.

Design, Demo Mode, and visual language

Most productivity apps collapse everything into one list. My life doesn’t work that way—writing a blog post about PDEs is a task; “quantum mechanics” as a goal is a study track. ORBIT gives each entity its own view while tying them together with categories.

The schedule supports weekly, daily, and monthly lenses on purpose: weekly for planning, daily for doing, monthly for scanning ahead.

Visually I wanted something scientific and deliberate—dark mode, glassy surfaces, icon navigation—not generic “corporate dashboard.” The name ORBIT nods to astrophysics and to planning as something cyclical.

The app is a web app (React + Vite). It had to be shareable and sync across devices, not stuck on one machine. That led to two modes:

• Google Mode: Sign in with Google (OAuth 2.0). Data syncs to your private Drive appDataFolder. I don’t run a database or hold your password—Google handles identity; scoped consent covers Drive and Calendar APIs. Calendar integration lives here.
• Demo Mode: No sign-in. State loads from seeded JSON and saves to localStorage so visitors can explore realistic data; Calendar push stays off. Publishing richer OAuth scopes can trigger Google verification work—Demo Mode keeps the door open for people who just want to click around.

Tech stack: boring on purpose

I build heavy distributed ML pipelines at work. For my own life I wanted minimal ops: no servers to patch, no paid backend database – just a static front end, user-owned cloud storage, and APIs I don’t host.

Technology	Role	Why this choice
React + Vite	Frontend SPA	Fast HMR, component model, faster loop than CRA-era tooling.
Lucide React	Icons	Consistent SVG icon set.
vite-plugin-pwa	PWA shell	Installable, offline-friendly packaging without a custom backend.
react-markdown	Markdown rendering	In-app / legal-style content where markdown is the source.
ESLint	Quality	Catch footguns during development (npm run lint).
Google Drive appDataFolder	Cloud storage	No app-owned DB; data stays in the user’s Drive.
Google Calendar API	Calendar push	Notifications and scheduling where people already are.
Google OAuth 2.0	Identity & consent	No custom auth server; scoped access to APIs.
localStorage	Demo Mode	Instant, no OAuth friction for trials.
Hostinger (static)	Hosting	Subdomain + SSL without managing a VM.
Node (dev only)	Tooling	Build and dev server; production is static files only.

Architecture: static app, user-owned cloud

High level: the browser loads a static SPA from Hostinger. When you use Google Mode, the app runs OAuth in the client, then reads and writes JSON (or equivalent payloads) in your Drive appDataFolder and talks to the Calendar API for push. There is no ORBIT-owned database only Google’s APIs and your account.

Early versions used localStorage for everything. That broke when I wanted phone and desktop in sync. Firebase was an obvious suggestion; I spend a lot of time in Colab and value mounting Drive and restoring checkpoints—so user-owned Drive sync felt natural: same account many devices, data portability, and no server for me to maintain.

Hosting (Hostinger)

Production is a Vite build served as static files at orbit.livnlearns.com over HTTPS—no Node runtime in prod.

1. Subdomain: Point orbit to something like public_html/orbit (your host’s layout may vary).
2. SSL: Enable HTTPS and redirect HTTP to HTTPS.
3. Deploy: Run npm run build, upload the contents of dist/ to the site root for that subdomain.
4. SPA fallback: Rewrite unknown paths to index.html so refreshes on client routes don’t 404.
5. File permissions: Folders readable by the web server (commonly 755), files 644—standard static hosting hygiene.

Google Cloud project & OAuth

1. APIs: Enable Google Drive API and Google Calendar API for the Cloud project.
2. OAuth consent: Configure the consent screen and scopes your app requests.
3. Authorized JavaScript origins
4. Credentials: Create an OAuth 2.0 Client ID (Web application). Optionally restrict the API key by HTTP referrer if you use key restrictions.
5. Build-time env: Vite injects variables at build time – set CLIENT_ID and API_KEY in .env, rebuild after changes.
6. Iterate: Use browser devtools and Google’s API error messages until Drive and Calendar calls succeed end-to-end.

Security posture

There is no centralized ORBIT data server – user data lives in each person’s Drive app folder. Deployment notes include security headers (e.g. HSTS, X-Frame-Options, CSP) and a practical hardening checklist: validation, sync visibility, auth/session handling, and defensive limits on fields.

What broke and what I learned

OAuth vs a frictionless demo: Real Google integration means consent screens, origins, and sometimes verification if you broaden scopes or user type. Demo Mode exists so people can try the product without signing in – trading full Calendar integration for accessibility.

SPA hosting: Single-page apps need server rewrites; otherwise a shared link to a route returns 404 from the host. That’s a small fix, easy to forget until someone refreshes.

AI as implementer: Models scaffold components and chase stack traces fast – they still hallucinate architecture. Product shape, entity model, dual modes, and the “no backend DB” call were mine to own.

Building with Cursor and AI

ORBIT was built mostly in Cursor with AI-assisted development throughout (after other tooling credits ran dry). “Used AI” here means a first-pass implementation partner and debugger – not autopilot product design.

What AI accelerated

• Scaffolding React components from plain-English requirements.
• Cross-file refactors e.g. threading isDemoMode through App.jsx, calendar views, and auth flows.
• Narrowing obscure errors from Vite console traces.
• Drafting README, deployment notes, and policy-style docs from accumulated context.

What I had to drive

AI is an implementer, not an architect. Meaningful decisions—entities, Demo vs Google Mode, Drive instead of a hosted database – came from deliberate choices, not prompts alone. The gap between vague prompting and a clear system design is where the product actually appears.

Prompts that shaped the build

“Help me set up Google sign-in so data is stored in the user’s Google Drive, sync with Google Calendar, and friends can use the app with their data staying in their accounts.”

“Build Demo Mode with a ‘Try Demo Mode’ button under Google Sign-In—bypass OAuth, initialize from JSON mock data, use localStorage.”

Who it’s for

ORBIT was built for my mess of commitments research, job, training, long-term learning—but categories and the vision board are flexible enough to swap domains. Because storage is per-user Drive, anyone hitting the same URL gets an isolated dataset without multitenancy plumbing on my side.

• Researcher + day job: Separate deep work from fixed schedule blocks; track study on its own rails.
• Grad student: Map study tracks to courses or papers; projects to thesis or lab milestones.
• Solo developer / freelancer: Clients, products, bugs vs features, milestones.
• Generalist juggling careers: Recurring training plus weekly priorities without losing the long view.

Building ORBIT refreshed my React and Google API muscles after years away—and clarified how I want to use AI: not to skip thinking, but to ship faster once the design exists. Off-the-shelf tools didn’t match my mental model; building my own gave a perfect fit, and AI made that feasible in less than a weekend of focused time instead of a quarter.

If you’re at the intersection of research, ambition, and an overloaded calendar, try Demo Mode. If it clicks, sign in and make it yours or build something equally personal; I’d love to hear about it.