Andy Wu

Software & infrastructure.

I build Kubernetes platforms, workload identity, and infrastructure automation at Oracle. A few side projects got out of hand.

  • CKACertified Kubernetes Administrator
  • OCI Architect AssociateOracle Cloud Infrastructure
  • OCI Developer ProfessionalOracle Cloud Infrastructure
The villa is imaginary. The projects are real. Scroll to explore ↓

Selected work.

GitHub
Cloud infrastructure

August 2026–present

A Kubernetes console for investigating failed workloads, reviewing a fix, and checking recovery. Built around an EKS platform I deployed on AWS.

  • Go
  • React
  • Kubernetes
  • Terraform
View source
AI & education

June 2026–present

A college admissions platform for researching schools, reviewing essays, and building a college list.

  • Next.js
  • FastAPI
  • PostgreSQL
Visit site
Product engineering

Mar–Jul 2026

A shared ledger that helps club treasurers match payment emails to dues. Fewer spreadsheet detective stories.

  • Next.js
  • NestJS
  • PostgreSQL
View source

A few more things I built.

Creative tools

Mar–Aug 2025

Recipes with an interactive kitchen counter. The ingredients have actual physics.

  • Next.js
  • FastAPI
  • Matter.js
View source
AI & education

Apr–Sep 2025

An AP study workspace that brings textbook retrieval, tutoring, quizzes, and graphs together.

  • React
  • FastAPI
  • RAG
View source
Product engineering

Original build: Feb–May 2023Originally built without AI

Films, television, ratings, and saved collections—with live catalog data from TMDB.

  • React
  • Express
  • MySQL
View source
Application correctness

Jun–Jul 2023Originally built without AI

An animal-themed calendar with offline drafts and a plan for when two edits disagree.

  • Angular
  • Firebase
  • TypeScript
Client work

Spring 2024Originally built without AI

A working website for a tutoring center, with schedules the staff can update themselves.

  • React
  • Google Sheets
  • DreamHost
Earlier projects & coursework

AnimalCalendar, Ants, Ngordnet, MazeGame, and the original FilmVault predate my use of AI coding tools. The Berkeley projects build on course-provided frameworks.

KubeVista
KubeVista operations console showing its validated deployment snapshot

Cloud infrastructure

KubeVista

August 2026–present

AWS lab and subsequent incident-response and release-testing work: 2026.

I built the Go API, React console, and AWS platform around them. The console connects Deployments, ReplicaSets, Pods, and events so an investigation can lead into a reviewed restart, scale, or rollback. Recovery checks look at the rollout—not just whether Kubernetes accepted the request.

  • Go
  • React
  • Kubernetes
  • Terraform
Role
Solo builder
Owned
Product, Go API, React interface, AWS platform, delivery, security boundaries, and operations
Status
Incident and blue-green release labs merged; AWS environment retired

System map

Architecture

KubeVista architecture from GitHub Actions through Argo CD into a private EKS node group, with AWS ingress, pod identity, secrets, and an observability stack
The original AWS platform. The newer operator path adds reviewed restart, scale, and rollback without granting arbitrary cluster writes.

How it works

Terraform provisioned networking across three availability zones, two private worker nodes, Pod Identity, and KMS encryption. Twelve Argo CD applications delivered the platform, with metrics, logs, and traces through Prometheus, Grafana, Loki, Tempo, and OpenTelemetry. The newer Go operator path checks identity, dry-runs the change, and follows rollout state after execution.

Engineering decisions

  1. The browser never submits YAML. Restart, scale, and rollback are typed operations; rollback pins the reviewed template from an owned ReplicaSet.
  2. Review plans expire after five minutes, work once, and are bound to the request and Kubernetes resource version to prevent edits or replay.
  3. Recovery requires the expected controller generation and updated/available replicas. A local kind lab exercises probe, crash-loop, image-pull, memory, and scheduling failures. Plans and receipts remain process-local.
  4. A blue-green release lab validates a candidate before switching Service traffic, checks latency and errors, and rolls back without overwriting a concurrent Service edit.

Controlled lab resultsAll 896 AWS test requests returned HTTP 200 while an API pod was replaced; its replacement became Ready within two seconds. Separate kind labs exercise five failure classes and guarded blue-green releases, with 20 desktop/mobile browser tests covering the console.

How a change gets through

The write path is deliberately narrower than the inventory API. Each stage removes a class of accidental or unauthorized change before Kubernetes accepts it.

  1. ChooseSelect restart, scale, or rollback for an allowed Deployment and explain why the change is needed.
  2. ConstrainThe API rejects unsupported kinds, namespaces, actions, and replica counts before touching the cluster.
  3. Dry runKubernetes authorization and admission evaluate the same request without persisting it.
  4. BindA five-minute, single-use plan locks the reviewed request to the current resource version.
  5. ExecuteThe API rechecks identity and dry run, applies the scoped change, records a receipt, and checks rollout recovery.

The original AWS lab has been torn down. Guarded operations, incident recovery, and blue-green release checks were tested separately in disposable kind clusters and merged into main.

Illuma
Illuma college admissions platform homepage

AI & education

Illuma

June 2026–present

I founded Illuma to bring college research, planning, and essay feedback into one workspace. I built the platform and its typed AI tools, then traced a slow streaming workflow to database writes that were making the model wait on progress updates.

  • Next.js
  • FastAPI
  • PostgreSQL
Role
Founder and lead engineer
Owned
Product, typed AI tools, admissions model, backend performance, and platform implementation
Status
Live product

System map

Architecture

Illuma architecture showing a student workspace, an agent coordinator, research and writing tools, shared state and validation, and admissions data and prediction services
A coordinated tool system: each specialist works against the same student context instead of producing isolated chat responses.

How it works

A student request enters a coordinator that selects typed tools for school research, college-list planning, or essay review. Every tool reads and updates shared application state, and deterministic checks gate what can move to the next step. The prediction path combines a student profile with historical applicant outcomes and university data.

Engineering decisions

  1. Typed tool inputs and outputs make handoffs inspectable and reject malformed results early.
  2. Shared state keeps recommendations consistent across research, essays, and the evolving college list.
  3. Admissions prediction is kept as a separate data pipeline rather than hidden inside an unconstrained language-model answer.
  4. Progress updates are coalesced in a background writer. Conditional database updates protect completed results from late progress writes, while final results are saved separately.

Measured on stagingProgress-callback overhead fell from 318 seconds to 23 milliseconds in a before/after staging comparison. The fix is deployed; these timings describe that sample, not a production latency guarantee.

The platform has 39 typed tools and admissions modeling across 130 universities. Product figures in my September 2026 résumé: 5,000+ users, $10K+ revenue, and 4M+ organic social views.

Ledgly
Ledgly financial dashboard with charges, payments, and membership balances

Product engineering

Ledgly

Mar–Jul 2026

Original build: March–July 2026. Transaction and recovery improvements shipped September 2026.

A club ledger should not create a second payment because someone clicked twice. I built the financial model and reconciliation workflow, then added idempotent writes, concurrency-safe allocations, durable email jobs, and recovery tests for the less cooperative days.

  • Next.js
  • NestJS
  • PostgreSQL
Role
Solo full-stack engineer
Owned
Architecture, ledger model, reconciliation, permissions, and audit workflow
Status
Reliability changes deployed; background workers separately controlled

System map

Architecture

Ledgly architecture showing the Next.js interface, NestJS API, PostgreSQL ledger, Gmail ingestion, and a review gate before financial records are changed
Incoming payment email becomes a proposed ledger match, not an automatic financial fact.

How it works

The Next.js interface calls an organization-scoped NestJS API backed by Prisma and PostgreSQL. Durable Gmail jobs discover and process payment notices, with sender matching and confidence scores for review. Imports commit atomically. A transactional outbox records notification work alongside database changes, then retries delivery per destination.

Engineering decisions

  1. Amounts use integer cents. Serializable allocation transactions and bounded retries prevent competing requests from overallocating a payment or charge.
  2. An organization-scoped idempotency key binds to the request fingerprint. The payment, audit entry, and replay response commit together; changed-payload reuse is rejected.
  3. Durable ingestion jobs and notification outbox entries survive process restarts. Replay is audited, and ambiguous payment matches and AI financial writes still require review.

Recovery testingTests terminate a worker after payment commit, restart the database, and restore a backup before redelivery, checking that the payment is not duplicated. External notification delivery can still repeat after an ambiguous provider acknowledgment.

The reliability changes are merged and deployed. Gmail ingestion and notification delivery have separate activation flags; deployment does not mean those workers are enabled. Ledgly records payments; it does not move money.

Sizzle

Creative tools

Sizzle

Mar–Aug 2025

Original project dates. Performance and accessibility updates: September 2026.

A dish or a few ingredients become a saved recipe and an illustrated cooking view. I built the generation pipeline and physics counter, then separated frame-by-frame movement from React rendering so the playful part does not keep rerendering the app.

  • Next.js
  • FastAPI
  • Matter.js
Role
Solo builder
Owned
Recipe pipeline, FastAPI service, interactive cooking view, and OCI deployment
Status
Performance and accessibility upgrade tested on a feature branch

Behind the project

A natural-language request first searches saved recipes. If nothing fits, FastAPI creates structured ingredients, equipment, and steps, persists them in Supabase, and starts illustration work in the background. The Next.js cooking view renders each step and uses Matter.js to place the relevant objects on a virtual counter.

Engineering choices

  • Recipe generation produces a fixed structure so the interface does not have to parse prose.
  • Illustrations run in a bounded, in-process worker pool after saving the recipe. This is background work, not a durable job queue.
  • Matter.js updates element transforms through refs; React owns recipe state. A single runner pauses when hidden or paused, with keyboard movement and a static reduced-motion layout.

Local measurementWith 20 items, React commits fell from 301 to zero over a five-second development sample while physics movement continued. Browser checks cover pause, keyboard controls, reduced motion, and runtime errors without paid APIs.

The performance and accessibility upgrade is tested on codex/cooking-performance, not production-deployed. The benchmark is a local React rendering measurement, not an FPS or CPU claim.

Academis

AI & education

Academis

Apr–Sep 2025

Original project dates. Session isolation and versioned retrieval improvements: September 2026.

I built Academis around course documents so tutoring has something concrete to refer to. The latest work tracks where each passage came from, keeps retrieval within the selected course and document version, and declines to answer when usable evidence is missing.

  • React
  • FastAPI
  • RAG
Role
Solo builder
Owned
Document ingestion, retrieval, tutoring API, and study interface
Status
Versioned retrieval and abstention tested on a feature branch

From textbook to answer

  1. Versioned PDFs
  2. Course-scoped chunks
  3. Retrieve & validate
  4. Answer or abstain

PDFs become overlapping chunks with document hashes, page numbers, course and corpus versions, and embedding metadata. Atlas queries filter that scope before retrieval; the API validates returned passages again. Verified user, course, and session identity isolate conversation history. Missing evidence or retrieval failure produces an abstention rather than an unsupported answer.

Engineering choices

  • Deterministic chunk identifiers and content hashes make ingestion and source provenance inspectable across document versions.
  • Course, corpus version, schema, and embedding-model filters prevent unrelated material from entering the answer context.
  • Server-generated references include source title, page, version, and chunk identifier. These identify retrieved evidence; they do not prove every generated sentence is supported.

Policy and contract testsFourteen backend tests and client type checks passed. A small synthetic evaluation checks course/version boundaries and abstention; it does not measure live Atlas retrieval quality or real-world answer accuracy.

Versioned retrieval and source references are implemented and tested on codex/retrieval-provenance. Live Atlas ingestion and retrieval-threshold calibration remain before rollout. Economics has the most complete content; science courses remain partial.

FilmVault

Product engineering

FilmVault

Original build: Feb–May 2023Originally built without AI

v1: Feb–May 2023; v2: Jun–Oct 2024; v3: Apr–Aug 2025. The first two versions were built without AI; later versions and September 2026 updates include AI assistance.

TMDB owns the movie catalog; FilmVault owns your ratings and collection. I revisited this earlier project to handle upstream outages and stop loading an entire collection just to show its first page. The updated client searches and sorts on the server, with bounded cursor pages.

  • React
  • Express
  • MySQL
Role
Solo full-stack engineer
Owned
React client, Express API, member data, TMDB integration, and original OCI design
Status
Catalog resilience and pagination merged; not currently deployed

Behind the project

React calls an Express API for catalog browsing and member-owned collections. A shared TMDB client bounds upstream requests and can explicitly return stale catalog data during eligible failures. Collection queries use validated cursors, whole-collection search, stable sort tie-breakers, and authenticated ownership checks.

Engineering choices

  • Only public catalog reads enter the bounded, process-local cache. Concurrent requests coalesce; retries share a deadline and stale responses are explicitly marked.
  • The updated client requests cursor pagination explicitly, preserving older API formats. Search is debounced, obsolete requests are canceled, and late results cannot replace the current view.
  • MySQL query plans guided the pagination work. Deep pages can still scan many index entries; cursor pagination is not a constant-work guarantee.

Synthetic MySQL benchmarkFor a 10,000-item collection, warm median database/response-construction time was 33.62 ms for a full read and 0.56 ms for the first 15 items. Initial JSON fell from 6.27 MB to 9.55 KB. MySQL, SQLite, API, and client tests cover the contracts; these are not end-to-end production timings.

Catalog resilience and pagination are merged into main. FilmVault is not currently deployed; the video is a local demo. Benchmark figures come from synthetic MySQL data, not production traffic.

AnimalCalendar

Application correctness

AnimalCalendar

Jun–Jul 2023Originally built without AI

Original build without AI. Offline editing and Firebase correctness updates: September 2026, with AI assistance.

One of my earlier projects, revisited at the point where calendars get awkward: no connection, another tab, or an event edited elsewhere. Drafts stay in the browser until they can sync, and conflicting edits stay available for review instead of silently replacing newer data.

  • Angular
  • Firebase
  • TypeScript
Role
Solo builder
Owned
Calendar interface, authentication, event persistence, security rules, and emulator tests
Status
Offline editing and conflict handling tested on a feature branch

What I changed

  • Account-scoped IndexedDB drafts and snapshots survive reloads and overlay pending edits on the calendar.
  • Reconnection checks the original event version. Concurrent edits and deletion tombstones trigger an explicit conflict instead of restoring stale data.
  • Operation identifiers recognize the last accepted write after an acknowledgment is lost. Conditional queue removal protects newer drafts from older completions.
  • Two Firebase emulator clients exercise offline edits, competing changes, deletion conflicts, and replay. Fifteen date, queue, and emulator tests passed.

Implemented and tested on codex/offline-conflicts; not deployed. Browser storage can be cleared or evicted, and conflicting fields are not automatically merged. Firebase rules must be updated before the new client is released.

Summit Tutoring Center

Client work

Summit Tutoring Center

Spring 2024Originally built without AI

I built this for a tutoring business owned by family friends. It covers classes, staff, counseling, and inquiries, and fits the hosting setup they already had.

  • React
  • Google Sheets
  • DreamHost
Role
Designer and developer
Owned
Information architecture, frontend, staff-managed content flow, and deployment
Status
Live client website

Behind the project

Staff edit schedules, seminars, and posts in familiar Google Sheets. The React site fetches the published CSV, parses quoted and multiline fields, and keeps the latest good response in browser storage. The production build stays on the business's existing DreamHost account.

Engineering choices

  • Google Sheets serves as the editing interface, avoiding a custom CMS and new staff accounts.
  • A five-minute cache limits repeat fetches while stale-data fallback keeps the last valid schedule visible.
  • The inquiry form uses Web3Forms when configured and can fall back to an email draft.

ResultThe site is live for a real tutoring business, and nontechnical staff can update frequently changing information without asking for a code deployment.

About me.

Andy smiling in a suit on the UC Berkeley campus
Berkeley, California.

I'm Andy. I graduated from Berkeley in 2024 and now work at Oracle, where I build around Kubernetes, infrastructure automation, workload identity, and backend services.

Most of my side projects start with a problem I have run into myself: applying to college, managing club finances, studying, cooking, or keeping track of movies. I like building the infrastructure, but I care just as much about whether the finished thing is pleasant to use.

Away from the keyboard, I read fantasy, draw and paint, and take an unreasonable number of cat photos. That is how this portfolio ended up inside an imaginary villa.

Oracle

Oracle

Software Engineer · OCI

I build cloud infrastructure and backend services at Oracle. My work includes a WebLogic-to-Spring Boot migration that cut full ETL runtime from four hours to one, and coordinating with application owners to move services onto a new Kubernetes cluster.

Received Oracle’s Gold Award for team-level initiatives and delivery.

University of California, Berkeley

B.A. Computer Science · 2024

Andy with two friends in graduation stoles at UC Berkeley
Graduation day with friends, 2024.

UC Berkeley

I graduated in 2024 with a B.S. in Computer Science. A lot of my earliest work here came from Berkeley courses: graph-backed word tools, simulations, and procedurally generated games.

I keep those projects in the archive because they show the point where software stopped feeling abstract and started feeling like something I could shape.

Say hello.

andyw98@berkeley.edu

I am always happy to talk about infrastructure, useful products, Berkeley, or the fantasy novel currently keeping you up too late.