LIBUIT.ORG
Back to About

Technical stack

How an idea becomes a live project.

LIBUIT.ORG uses a small, understandable core platform. Codex helps build and verify the code locally, GitHub preserves it, Google Cloud turns each approved release into the live site, and Cloudflare connects that service to the domain.

Current approach

One stable core, with optional integrations owned by each project.

Delivery lifecycle

From conversation to production

The workflow remains deliberately visible. Each stage has a clear job, and no single tool quietly owns the entire process.

  1. 1

    Build locally

    Turn the idea into working code

    The project takes shape in the shared local workspace before anything reaches GitHub or Google Cloud.

    1. Idea + requirements

      Define the useful need and the boundaries for the project.

    2. Codex + local workspace

      Inspect, explain, edit, and test the application alongside Kevin.

    3. Lint + production build

      Verify the change locally before it can move forward.

  2. 2

    Release intentionally

    Create a durable release

    Only reviewed work becomes part of main, giving every production version a clear source and history.

    1. Private GitHub repository

      Commit approved changes to main and preserve the code history.

    2. Google Cloud Build

      Turn that source into a production-ready container.

  3. 3

    Serve reliably

    Connect the release to the domain

    Google runs the application while Cloudflare provides the public domain and DNS layer people use to reach it.

    1. Google Cloud Run

      Serve the container, manage revisions, and route production traffic.

    2. Cloudflare

      Manage libuit.org DNS, DNSSEC, and the path to the live service.

Core application

The reusable foundation

These tools support the whole site. Individual projects can look and behave differently without replacing the foundation beneath them.

Application framework

Next.js + App Router

Routes, layouts, server components, protected server logic, and production rendering.

Application language

TypeScript

Types make project data, component contracts, and server boundaries easier to understand and maintain.

Interface system

Tailwind CSS

Shared design tokens and responsive utility classes support both the restrained core site and project-specific themes.

Local tooling

npm + Git

npm runs development, linting, and builds; Git records each intentional change before it reaches production.

Project-specific integrations

Data sources plug in at the project boundary

Not every project needs a database, an API, or an external service. When one does, the integration belongs to that project and stays behind the server-side application boundary.

Optional sourceNotion or another project service
Server boundaryNext.js server logicCredentials stay here
Project experienceApproved views and tools

Notion

In use

Summer School

Approved lesson and progress records are read through a server-only, read-only integration for password-protected family pages.

ChatGPT

Manual today

Summer School planning

ChatGPT currently helps shape curriculum and next-lesson drafts through a human-led conversation. The website itself does not send lesson data to an AI service.

Future data sources

Project by project

Other personal tools

A future project may use its own service or structured data source, but it should connect through a documented server boundary instead of becoming a site-wide dependency.

Two kinds of history

Code and daily records live in different places

The repository stays focused on software. Ongoing project notes and logs can evolve in Notion without turning every daily update into a code change.

Code history

GitHub

Application code, configuration, commits, and release points. GitHub answers what changed in the software and when it entered main.

Working history

Notion

Day-to-day project documentation, lesson logs, observations, and other manually maintained operational records that do not belong in the code repository.

Operating principles

Keep the system understandable

  • Secrets stay out of Git and client-side code.
  • Production secrets are supplied to the Cloud Run service at runtime.
  • External data is integrated only when a project actually needs it.
  • Private project information stays behind the appropriate server-side boundary.
  • Every release is built and verified before it receives production traffic.