BUILD RECORD 06Active build2026

Stackjet

A remote file URL travels directly into cloud storage without using the person's device as a temporary warehouse.

CreatorCreator · full-stack product engineeringGoogle Drive upload workflow implemented
PRIMARY EVIDENCE

The work, not a mockup.

Stackjet URL-to-cloud-storage product interface capture

Stackjet URL-to-cloud-storage product interface capture
product capture1200 × 720APPROVED PUBLIC MEDIA
ARCHITECTURE

WEB ↔ CLOUD ↔ TOOLING

01WEB
02CLOUD
03TOOLING
01 / OVERVIEW

What exists.

Stackjet evolves the original DriveUploader idea into a storage-operations platform. Its first live workflow authorizes Google Drive and orchestrates remote URL uploads with an inspectable event timeline.

02 / PROBLEM + CONSTRAINT

Where it resisted.

The normal download-then-upload flow wastes local storage, bandwidth, time, and battery—especially on a constrained device.

03 / INTERVENTION

What I changed.

I built separate platform and Drive authorization, encrypted refresh-token storage, Convex-backed jobs, direct file streaming, and support for signed or authenticated sources.

DIFFICULT DECISION

The obvious implementation was not the product.

Stream from source to destination and persist job state rather than turning the browser into the transfer engine.

Current proof

03
  1. Google sign-in and a separate Drive consent flow are implemented.
  2. Remote URL uploads support direct files and authenticated headers.
  3. Type checking, lint, and production build pass in the current project.
LESSONS

What this build changed.

Removing one unnecessary hop can reshape an entire product architecture and make the result more useful on mobile hardware.

BUILD MATERIALS

The implementation surface.

01Next.js02TypeScript03Convex04OAuth05Google Drive API
Next build recordAcode Beyond Android