Project Planning Platform: Replacing Jira-Centric Planning with Google Calendar

An internal platform that moves planning into Google Calendar — configurable hierarchies, one Bun process, built to cut Jira licensing costs.

4 min read

Role: Backend Lead — architecture, schema, API design, ~60% of implementation
Services: Backend Engineering
Stack: Bun, Elysia, Drizzle, PostgreSQL, ScyllaDB, ClickHouse, Kafka, gRPC, Google Calendar API

5
engineering team
backend lead — 3 backend engineers, 2 frontend engineers
~60%
of backend implementation
alongside owning architecture, schema, API design, deployment, and testing
1
process to operate
HTTP API, gRPC, and background workers run in a single Bun process

Business Problem

The organization's planning ran through Jira, and it wanted out — for two reasons that rarely arrive together. Licensing costs needed to come down, and the workflow itself didn't fit: employees live in Google Calendar, planning structures needed to be configurable per team, and the organization wanted an internal workflow tailored to how it actually operates rather than to a vendor's model.

Why existing tools were not enough

Licensing cost — reducing Jira licensing spend was an explicit goal of the project.
Fixed hierarchy — off-the-shelf planning assumes a fixed Epic → Story → Task breakdown; the organization needed configurable planning hierarchies.
Planning away from the calendar — employees should be able to plan work directly in Google Calendar, the tool where their time already lives, instead of a separate planning surface.
Generic workflow — the goal was an internal workflow tailored to the organization, not a general-purpose tool configured to approximate it.

Challenges

Constraint	Consequence
Django owns the database schema	The new platform consumes a schema it doesn't control — drift is a standing risk
Google Calendar is an external system	Synchronization must be asynchronous and safe to retry
Hierarchies must be configurable	No hard-coded Epic → Story → Task model anywhere in the schema or API
Small team, whole platform	Operational complexity had to stay low enough for five engineers to run everything

My Role

Backend lead on a five-person team — three backend engineers and two frontend engineers. I owned the high-level design, backend architecture, database schema, API design, deployment, and testing including load testing, and personally implemented roughly 60% of the backend. On the leadership side: code reviews and mentoring the junior engineers.

Solution

The backend is a single Bun process running Elysia, serving the HTTP API and gRPC alongside background workers. PostgreSQL is the source of truth; ScyllaDB serves high-performance read projections; Kafka is the asynchronous synchronization backbone for calendar events flowing between the platform and Google Calendar; ClickHouse handles logging and operational analytics. Database access is direct — the platform replaced the previous Client → Elysia → Django → DB request path with Client → Elysia → DB, consuming the Django-owned schema through typed schemas generated by Drizzle.

Planning where the work already lives

Rather than building a calendar into the platform, it integrates the user's existing Google Calendar, so planning happens in the tool employees already use. Calendar events synchronize asynchronously over Kafka.

Configurable planning hierarchy

The platform supports configurable work hierarchies instead of a fixed Epic → Story → Task structure, so each team's planning model is configuration, not code.

Read path and load testing

PostgreSQL remains the single source of truth while ScyllaDB serves read projections built for high-performance reads. Load testing was part of my remit on this platform.

Reliability and idempotency

The projection and synchronization machinery is built to be replayed safely: projection jobs use advisory locks, retries, and upserts, so a job that runs again converges instead of double-applying. Idempotency is the property that makes asynchronous projections and calendar sync trustworthy.

Observability

ClickHouse carries logging and operational analytics for the platform.

Architecture

Frontend
   │
   ▼
Elysia on Bun — one process: HTTP API · gRPC · background workers
   │
   ├──▶ PostgreSQL — source of truth (typed schemas via Drizzle; Django owns the schema)
   ├──▶ ScyllaDB — read projections (idempotent projection jobs)
   ├──▶ ClickHouse — logging & operational analytics
   └──▶ Kafka — async synchronization backbone ⇄ Google Calendar

One Bun process — HTTP, gRPC, and workers — over PostgreSQL as source of truth, with ScyllaDB read projections, Kafka-based calendar sync, and ClickHouse analytics.

Diagram description

The frontend talks to a single backend process: Elysia running on Bun, which serves the HTTP API and gRPC and also hosts the background workers. That process reaches four specialized systems. PostgreSQL is the source of truth for all planning data, accessed directly through typed schemas generated by Drizzle — the schema itself is owned by Django. ScyllaDB holds read projections, populated by idempotent projection jobs, for high-performance reads. Kafka is the asynchronous synchronization backbone carrying calendar events between the platform and Google Calendar. ClickHouse receives logs and powers operational analytics. The previous request path routed through Django (Client → Elysia → Django → DB); this architecture replaces it with direct database access (Client → Elysia → DB).

Engineering Decisions

Technology Stack

Every store in this stack exists because one system shouldn't do every job. PostgreSQL is the transactional source of truth. ScyllaDB exists for one purpose — high-performance read projections — and nothing else. ClickHouse takes logging and operational analytics out of the transactional path. Kafka decouples calendar synchronization from request handling. On top, a single Bun process running Elysia keeps the operational footprint at one deployable, and Drizzle's generated typed schemas let the platform consume the Django-owned schema without hand-maintained definitions drifting out of date.

Business Results

5
engineering team
backend lead — 3 backend engineers, 2 frontend engineers
~60%
of backend implementation
alongside owning architecture, schema, API design, deployment, and testing
1
process to operate
HTTP API, gRPC, and background workers run in a single Bun process

The platform was built to reduce Jira licensing costs and move planning into Google Calendar with an internal workflow tailored to the organization. The numbers above are verified scope and design facts — not outcome claims.

Lessons Learned

The biggest lesson from this platform: design for extraction, not perfection.

The principle it reinforced: design systems that evolve safely over time instead of optimizing only for today's implementation.