Upload Drive-In

A Laravel web app that lets businesses receive files directly into their existing cloud storage. Clients get a clean drag-and-drop upload portal; files land organized and ready in the business owner’s Google Drive.

  • Role: Solo developer — architecture, frontend, backend, deployment
  • Timeline: 6–7 weeks to production-ready, 2025
  • Stack: Laravel, PHP, OAuth 2.0, Google Drive API, JavaScript, DDEV, Laravel Forge
  • Links: Live · Code
  • Recognition: First place, Code with Kiro Hackathon ($30,000 prize, ~10,000 participants) — my first hackathon entry

The Problem

File sharing is supposed to be simple, but for most small businesses it’s a mess. I watched my clients struggle with the same friction for years: emailed attachments hitting size limits, clunky FTP servers, shared cloud drives with confusing permissions. Every solution either required the client to manage an account they didn’t want, or required me to manage infrastructure I didn’t need.

I wanted something that worked the way file handoff should feel: the client drops files in, and they show up organized in storage the business already pays for. One step. No accounts for the sender. No new infrastructure to maintain.

Constraints

  • Use existing cloud storage. The app had to deposit files into services the business owner already uses — starting with Google Drive — rather than creating another silo to manage.
  • Non-technical senders. The upload experience had to work for clients who would never touch an FTP client or navigate a shared drive’s permission settings.
  • Large file reliability. Clients regularly send large files. Uploads had to be resilient to connection issues and size limits.
  • Future-proof architecture. Google Drive was the first provider, but the storage interface needed to support Amazon S3 and OneDrive without reworking the core application.
  • Self-hosted vs. SaaS. I had to decide early whether this was a tool I run for people or a tool people run themselves. Each path creates different infrastructure, onboarding, and support requirements.

Approach

Architecture

Upload Drive-In is a Laravel application with a modular storage provider interface. The core of the app doesn’t know or care whether files land in Google Drive, S3, or OneDrive — it talks to an abstraction layer that each provider implements. This decision cost more time upfront but means adding a new storage backend is a contained task, not a rewrite.

OAuth 2.0 and the non-technical user

Connecting to a user’s Google Drive requires OAuth 2.0, which is inherently complex. The technical challenge wasn’t implementing the flow — it was hiding the complexity from business owners who just want their files to show up. I spent significant time on the onboarding experience to make linking a Google account feel like a single, obvious step rather than a security gauntlet.

Chunked uploads

The frontend uploader breaks large files into chunks before sending them. This solves two problems: it keeps uploads moving reliably even on unstable connections, and it avoids server-side file size limits that would otherwise block the kind of large assets clients regularly send — design files, video, project archives.

Queue and background job management

File processing and cloud storage operations run through Laravel’s queue system rather than during the HTTP request. This keeps the upload experience fast for the sender while handling the actual file transfer to cloud storage asynchronously. Getting queue behavior consistent across development and production environments took more iteration than I expected.

The self-hosted decision

I chose to build Upload Drive-In as a self-hosted tool for this version. A SaaS model would simplify onboarding but introduce billing, multi-tenancy, and infrastructure I wasn’t ready to commit to before proving the core product worked. Starting self-hosted let me validate the concept with my own clients first. If I want broader adoption, a managed SaaS version is likely the right next step — and having a working self-hosted version has been essential to thinking through what that would actually require.

Outcome

Upload Drive-In is in production and handles file collection for my own clients. The source code is public and the project won first place in the Code with Kiro Hackathon — $30,000, out of roughly 10,000 participants. It was my first hackathon entry.

Beyond the competition, the most practical outcome is that a problem I’d been working around for years is solved. My clients drop files into a clean interface, and the files show up organized in my Google Drive. No email attachments, no shared folder permissions, no follow-up.

Reflection

The biggest lesson from this project was about when to let go of existing code. I brought a basic working version of the Google Drive integration with me when I started building the full application. In retrospect, I should have scrapped it entirely and built the storage interface from scratch. It probably would have been faster than adapting code that wasn’t designed for the modular architecture I ended up needing.

This project also changed how I think about building speed. Over the six or seven weeks of development, I learned to work with AI-assisted tooling more effectively as I went — not just writing code faster, but making better architectural decisions earlier because I could prototype and discard ideas quickly. The velocity I gained carried directly into my next project.