Thomas Cayne

Founder · Product architecture, implementation, testing, and delivery · Active proprietary product

Gravity English

A live, multi-tenant English-learning product with server-defined courses, queued curriculum generation, and white-label delivery.

I am designing and implementing Gravity English as a paid product: a SvelteKit application that combines tenant-specific delivery, structured curriculum, identity, billing boundaries, and a separate autonomous-generation service.

Technology

SvelteKit
Svelte 5
TypeScript
Node.js
PostgreSQL
Drizzle ORM
Clerk
AWS S3

Read project case study View architecture diagram & data flow

Gravity English platform landing page introducing its English fluency infrastructure — Representative product artwork for the active Gravity English platform; the live product is available through the project link.

Constraint and context: Schools, teachers, and enterprise customers need distinct branding, membership, curriculum, and domains without a separate application build for every tenant. Curriculum generation also cannot block the interactive application or weaken tenant isolation.
Implemented approach: I implemented request-time host resolution that maps a subdomain to an organization, branding profile, localized dictionary, membership context, and subscription state
I separated Clerk authentication from application-owned users, organization memberships, and per-organization role authority stored in PostgreSQL
Engineering decisions and tradeoffs: I replaced the legacy Angular/AnalogJS application with SvelteKit 5 because the active product needed server-driven behavior without the former SSR and build constraints
I kept curriculum in typed server-defined content so course structure can change independently from page deployments while the application still validates tenancy and rendering
Resulting capability: I made one application resolve tenant-specific brand, localization, organization, role, and subscription context for every request
I moved blueprint and thumbnail generation into persisted PENDING jobs instead of holding the browser request open

Public engineering, private products, and exploration

College project · Sole architecture and implementation · Live deployment · Public source

JRKC Bookstore

An end-to-end bookstore system I selected from professor-provided options and delivered during a five-week Colorado Technical University course.

The course used group assignments, but I completed the architecture, application design, implementation, database, testing, documentation, CI/CD, and Oracle deployment. It was the course's working end-to-end bookstore application rather than a demonstration or concept submission.

Technology

Next.js
React
TypeScript
PostgreSQL
Drizzle ORM
Docker
Stripe

Read project case study

JRKC Bookstore catalog showing filters, ratings, pricing, and paginated book inventory — Deployed JRKC Bookstore catalog with filtering, rating, pricing, and pagination.

Constraint and context: A five-week college assignment required a working bookstore, but the original hosted database became unavailable and the public deployment had to coexist safely with other Docker workloads on one Oracle host.
Implemented approach: I replaced the unavailable hosted data dependency with application-owned PostgreSQL and typed Drizzle access
I containerized the application and database as an isolated Compose project with persistent storage and an explicit Oracle host port
Engineering decisions and tradeoffs: I replaced the unavailable paid hosted backend with application-owned authentication and typed Drizzle routes so identity and PostgreSQL access remain under the application's control
I isolated the bookstore in its own Docker Compose project, private database network, named volume, and explicit Oracle port so it cannot collide with other workloads
Resulting capability: I deployed the catalog, account, cart, and bookstore workflows against persistent PostgreSQL data on Oracle Cloud
I preserved database records across application replacement through a named volume scoped to the bookstore Compose project

Founder · Product architecture and active implementation · Private product in development

Coverlay Studio

An actively developed browser-based editor for reversible timeline operations, media composition, overlays, and AI-assisted production workflows.

I am designing and implementing Coverlay Studio as a private product. Its current codebase contains a real non-linear editing foundation while public access remains intentionally unavailable during active development.

Technology

React
Next.js
TypeScript
Zustand
Zundo
Express
PostgreSQL
Drizzle ORM
Clerk

Read project case study View architecture diagram & data flow

Coverlay Studio landing page presenting its AI-assisted video creation suite — Representative product artwork for the active Coverlay Studio codebase; the private product remains in development and has no public link.

Constraint and context: A browser editor must keep tracks, linked clips, compound clips, selection, and panel state synchronized while making destructive-looking timeline operations reversible and predictable.
Implemented approach: I built a typed Zustand project store wrapped by Zundo so timeline changes participate in a shared undo and redo history
I implemented linked and compound clips plus split, trim, ripple, roll, slip, slide, move, duplicate, mute, lock, visibility, and targeting operations
Engineering decisions and tradeoffs: I centralized editing state in one typed model, accepting greater store complexity to keep timeline, canvas, properties, assets, and assembly behavior consistent
I modeled linked and compound clip relationships as explicit data so editing operations update related media deliberately instead of relying on visual conventions
Resulting capability: I built a reversible multi-track editing foundation rather than a static timeline mockup
I established one shared action contract for editing tools consumed across multiple studio surfaces

Concept exploration

VoxAlloy

A high-fidelity interface concept for configuring synthetic speech across cloud and local voice models.

I used VoxAlloy to explore how speech controls, voice profiles, synthesis feedback, and model selection could coexist inside one focused studio interface.

Technology

Next.js
TypeScript
Python
FastAPI
Docker

Read project case study

VoxAlloy Studio neural voice synthesis interface concept — Interface concept for the VoxAlloy neural voice synthesis studio.

Constraint and context: Speech synthesis tools expose many interdependent controls; this exploration asks how an operator could understand those settings without losing the prompt and output context.
Implemented approach: I mapped the speech-synthesis workflow into voice, synthesis, articulation, and output concerns before composing the interface
I tested a workspace hierarchy that keeps prompt, profile, processing state, and model choice visible at the same time
Engineering decisions and tradeoffs: I grouped stability, similarity, pitch, articulation, and output controls by operator concern so interdependent settings remain understandable
I kept prompt input, processing feedback, voice selection, and model choice visible together so configuration does not lose synthesis context