Andy Wu

Cloud infrastructure

KubeVista

I built the Go API and React dashboard, then the platform around them: networking, identity, GitOps, telemetry, and failure tests. The API can inspect workloads, but cannot change them or read Secrets.

• Go
• React
• Kubernetes
• Terraform

Role

Solo builder

Owned

Product, Go API, React interface, AWS platform, delivery, and operations

Status

Recorded demo; paid AWS environment retired

System map

Architecture

How it works

Terraform builds the VPC, EKS control plane, managed node group, KMS keys, and AWS integrations. GitHub Actions publishes a scanned and signed image; Argo CD reconciles the manifests. Traffic enters through an AWS load balancer, while the Go API reads Kubernetes inventory under a restricted service account and emits telemetry through OpenTelemetry.

Engineering decisions

1. Workers stay private; one NAT gateway reduced demo cost, accepting an Availability Zone dependency that a long-running production setup would remove.
2. EKS Pod Identity and External Secrets replace long-lived AWS credentials inside pods.
3. The dashboard has read-only RBAC and cannot read Secrets, turning the product boundary into a security control.

Live testTwelve Argo CD applications were Synced and Healthy, and all 896 requests returned HTTP 200 while an API pod was replaced. The paid AWS environment was then torn down and checked for leftovers.

A controlled pod replacement

I used the dashboard as a real workload, kept the temporary AWS footprint cost-aware, and checked whether the platform controls behaved together under a small failure.

1. ProvisionTerraform created the three-AZ VPC, EKS cluster, private worker subnets, identity, and integrations.
2. DeliverGitHub Actions published a scanned and signed release; Argo CD reconciled 12 healthy applications.
3. DisruptFortio sent traffic while a running API pod was deliberately removed.
4. VerifyThe replacement became ready in two seconds and all 896 requests returned HTTP 200.
5. RetireI destroyed the paid environment and audited DNS, volumes, load balancers, and tagged AWS resources for leftovers.

Screenshot from the representative demo. The paid AWS deployment has been intentionally taken down.

AI & education

Illuma

I founded Illuma and built its AI tools and admissions probability model. The tools share state and validate their outputs before passing results to the next step.

• Multi-agent AI
• Python
• XGBoost

Role

Founder and lead engineer

Owned

Product direction, agent system, admissions model, and platform implementation

Status

Live product

System map

Architecture

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.

ScaleThe product grew to more than 5,000 users, with 39 typed tools and admissions modeling across 130 universities using 79,000 applicant outcomes.

Product figures are from my September 2026 résumé.

Product engineering

Ledgly

I built the member ledger, payment reconciliation, and review workflow. Charges, payments, expenses, and allocations are separate records, so partial payments and split allocations have somewhere sensible to go.

• Next.js
• NestJS
• PostgreSQL

Role

Solo full-stack engineer

Owned

Architecture, ledger model, reconciliation, permissions, and audit workflow

Status

Source available; public deployment protected

System map

Architecture

How it works

The Next.js client calls an organization-scoped NestJS API backed by Prisma and PostgreSQL. A Gmail worker reads payment notices, extracts candidate transactions, and proposes member matches with confidence. Treasurers review ambiguous matches before payments are allocated to charges; the API records the before-and-after state in the audit log.

Engineering decisions

1. Charges, payments, expenses, and allocations are separate records so partial and split payments remain representable.
2. Gmail is read-only, and low-confidence matches stop at a human review queue.
3. AI write tools require confirmation and use the same role checks and audit path as ordinary API actions.

TradeoffThe extra review step gives up fully automatic reconciliation in exchange for traceable financial changes, reversible batches, and fewer silent misallocations.

Dashboard image from the project repository.

Creative tools

Sizzle

A dish name or a few ingredients become a saved recipe and a step-by-step cooking view. I built structured recipe generation, background illustration jobs, and the Matter.js counter.

• Next.js
• FastAPI
• Matter.js

Role

Solo builder

Owned

Recipe pipeline, FastAPI service, interactive cooking view, and OCI deployment

Status

Source available

System map

Architecture

How it works

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 decisions

1. Recipe generation produces a fixed structure so the interface does not have to parse prose.
2. Image work runs after the recipe is saved, keeping the main request independent of slower media generation.
3. Matter.js owns placement and collision behavior while React owns the recipe and step state.

TradeoffA recipe can still load when image generation or object storage fails; the cost is accepting partially illustrated recipes and reporting those jobs separately.

AI & education

Academis

I built subject-scoped retrieval and a study interface for textbooks, questions, quizzes, and graphs. Microeconomics and Macroeconomics are the most complete courses; science content is partial.

• React
• FastAPI
• RAG

Role

Solo builder

Owned

Document ingestion, retrieval, tutoring API, and study interface

Status

Local demo and source available

System map

Architecture

How it works

An upload script extracts textbook PDFs, splits them into chunks, creates embeddings, and stores subject metadata with each record in MongoDB Atlas. At question time, FastAPI searches only the selected course, assembles the closest passages, and sends that context into the tutoring answer path used by the React interface.

Engineering decisions

1. Subject metadata constrains retrieval so a macroeconomics answer cannot silently borrow biology context.
2. Ingestion is a separate command-line pipeline, keeping expensive document processing out of student requests.
3. Tutoring, quizzes, graphs, and textbook routes remain separate FastAPI modules even though they share course data.

ScopeMicroeconomics and Macroeconomics have the most complete material. Science course shells remain visible but are described as partial rather than overstated as finished.

Product engineering

FilmVault

I built the original FilmVault before using generative-AI coding tools, and have since revisited the interface and local setup. TMDB supplies catalog data; the app owns accounts, ratings, and collections.

• React
• Express
• OCI

Role

Solo full-stack engineer

Owned

React client, Express API, member data, TMDB integration, and original OCI design

Status

Recorded local demo; historical cloud design

System map

Architecture

How it works

The React client uses one Express API for searches, people, authentication, profiles, ratings, and collections. The API enriches member-owned records with TMDB movie and television metadata, sends account email, and can process profile images before writing them to OCI Object Storage.

Engineering decisions

1. TMDB remains the catalog source while the application database owns users, ratings, and saved collections.
2. Authentication and admin checks live in API middleware rather than being inferred from client state.
3. The current SQLite demo path improves repeatability; the original OCI design retains MySQL and broader infrastructure.

TradeoffThe local demo is cheap and reproducible, while the checked-in OCI design shows the original production boundary. That history also leaves dependency upgrades and fresh deployment validation as explicit maintenance work.

Client work

Summit Tutoring Center

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

System map

Architecture

How it works

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 decisions

1. Google Sheets serves as the editing interface, avoiding a custom CMS and new staff accounts.
2. A five-minute cache limits repeat fetches while stale-data fallback keeps the last valid schedule visible.
3. 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.