DEV Community: Aashish Kumar Mahato

I built a tool that moves your Google Drive files between accounts. Here's how I made it safe enough to trust.

Aashish Kumar Mahato — Fri, 02 Oct 2026 18:25:22 +0000

My main Google account hit the 15GB free limit while my alt accounts sat empty. So I built Spillover — an open-source tool that rebalances your Google storage across your own accounts, running entirely on your machine.

But here's the thing about building a tool that moves people's files: if it loses even one file, nobody will ever trust it again. Safety wasn't a feature — it was the whole design. Here's how I layered it.

1. Dry-run by default

spillover run only ever previews the plan. Nothing moves until you pass --execute — and even then it asks for confirmation. The default path is the safe path; destruction requires intent, twice.

2. Verify-before-trash

This is the core guarantee: a source file is trashed only after the destination copy's SHA-256 hash matches the downloaded bytes. The pipeline is download → hash → upload → verify → trash, in that order, always. Hash mismatch? The source stays untouched and the move is logged as failed. There is no code path where the original is touched before the copy is proven identical.

3. Trash, never delete

Even after verification, originals go to the source account's trash — not permanent deletion. That's a 30-day undo window, courtesy of Google. If something ever looks wrong, you can pull it straight back out.

4. Crash-safe resume

Every file is tracked as a transaction: pending → in_progress → done/failed, with the last completed stage recorded. If the run dies halfway — killed process, dead laptop, dropped network — spillover resume continues from the first unfinished stage. A destination copy that was already uploaded and verified is never re-uploaded.

5. A permanent local ledger

Every move (done, failed, or skipped) lands in a local SQLite ledger: filename, size, hash, source → destination. Months later you can run spillover find vacation.mp4 and know exactly where it went. No cloud, no account — just a file on your machine.

6. Guardrails around the edges

1GB safety buffer per account — a destination is never filled to the brim.
Shared files skipped by default — moving a file you don't own breaks share links and strands collaborators, so they're flagged at plan time and skipped at run time unless you explicitly opt in.
Narrow OAuth scopes — Drive plus the Photos picker scope only. The picker exposes solely the items you select, never your whole library. No Gmail, no contacts, nothing else.

The honest limitation: Google Photos

Since March 2025, Google blocks third-party apps from reading your full photo library and provides no delete endpoint — so no tool on earth can fully automate Photos moves in 2026. Spillover uses the picker (you select in Google's own UI) plus Takeout imports, copies your picks hash-verified into your other accounts' Drive, and writes you a manual-deletion checklist. I'd rather tell you what it can't do than pretend otherwise.

Spillover is MIT licensed — Python, with a local web UI and CLI. v0.1.0 is out now.

Repo: https://github.com/aashish254/Spillover
7-minute tutorial: https://www.youtube.com/watch?v=EVb7bLrMGnY

If you've ever paid for Google storage while sitting on empty accounts, this one's for you. Issues, PRs, and feedback welcome.

How I Built an AI Studio That Turns Manhwa Chapters into Narrated Recap Videos

Aashish Kumar Mahato — Tue, 29 Sep 2026 22:02:41 +0000

If you've ever fallen down the rabbit hole of manhwa recap channels on YouTube — "The Weakest Hunter Becomes the Strongest..." — you know the format: dramatic narration over panning comic panels, 10 minutes per video, millions of views. I kept wondering: could that entire pipeline be automated, running locally, with no subscriptions?
That's how AniFlow was born — a self-hosted AI studio that takes manhwa/webtoon chapters and renders finished recap videos. It's open source (MIT): github.com/aashish254/Aniflow
Here's how the pipeline works, and what was hard about each step.
The pipeline

Chapter ingestion. Paste a chapter URL or point at a local folder. The downloader grabs every page image in reading order.
Panel detection (YOLOv8). Manhwa pages are vertical strips with irregular panel layouts. A trained YOLOv8 model detects panel boundaries so each panel can be cropped and sequenced for the video. This was the single hardest part — art styles vary wildly between series, and a detector trained on one artist's work falls apart on another's. Getting reliable detection across styles took the most iteration.
Speech bubble detection + text extraction. A second detection pass finds speech bubbles and text regions. OCR pulls the dialogue out, which becomes the script for dialogue-recap mode.
Bubble removal. For narrated mode, bubbles get removed and the art inpainted so panels look clean — like a friend telling you the story over the artwork. Doing this without leaving visible artifacts on detailed backgrounds was the second-hardest problem.
Narration writing (LLM). The extracted story content goes to a local LLM (Ollama by default, with optional Gemini/Claude) with a prompt tuned for that dramatic recap-channel voice. It writes the narration script panel by panel.
Voiceover (TTS). Multi-voice TTS — Edge TTS or Kokoro locally, ElevenLabs optionally — speaks the script. Different voices for narration vs. dialogue.
Video rendering. Everything gets composited with FFmpeg: Ken Burns pan/zoom over panels, background music, watermarks, subtitles. Out comes an upload-ready vertical video. Two modes Dialogue recap — keeps the original speech bubbles visible; extracted dialogue becomes the audio. Closest to reading the chapter. Narrated recap — bubbles removed and inpainted; the AI narrates the story like a recap channel. Fully local by default The whole stack runs on your own machine: Ollama for narration, Edge TTS for voice, no API keys, no subscriptions, nothing leaves your computer. Cloud models are optional upgrades, not requirements. There's also a batch mode that processes 50+ chapters unattended — a full series to video overnight. What I'd do differently If I started over, I'd spend more time on the training data for panel detection up front instead of iterating on model tweaks — data diversity beat architecture fiddling every time. I'd also build the evaluation harness earlier: a small set of "golden" chapters across art styles to regression-test every change against. Try it Repo: github.com/aashish254/Aniflow (MIT). There's a web UI, a v0.1.0 release, and tutorial videos in the README. If you're into self-hosting, computer vision, or the manhwa scene — I'd love your feedback, and contributors are very welcome.