I wouldn't pay for a download manager, and I wouldn't pirate one. So I built one.

It started as a written scope document: three parts (a browser extension, a local download engine, a desktop app), explicit non-goals (no DRM, no cloud, no accounts), and five build phases, each ending in a gate that had to pass before the next phase began. Phase one's gate was blunt: a 1 GB file must download at least 2× faster than Chrome and survive the process being killed. No UI and no extension until that was true.

Reviewing that scope before building caught the first serious mistake. It planned to use httpx with HTTP/2. HTTP/2 multiplexes every request over a single TCP connection, which is exactly the thing a download manager exists to avoid: sixteen "parallel" range requests would all queue through one pipe. The engine uses aiohttp over HTTP/1.1 instead, where every worker really is its own connection.

The gate result, against a local test server that limits each connection to 4 MB/s: a 100 MB file took 25.4 seconds on one connection and 2.0 seconds on sixteen, about 12.5×. Killing the process mid-download and starting it again resumed from the saved parts, and the SHA-256 of every finished file matched the source. Only then did the desktop app get built.

The extension never downloads anything itself. It spots media in network responses, takes over the browser's own downloads, and hands the request (URL, page, headers, the site's cookies) to the desktop app. The obvious way to do that is a WebSocket on localhost, and the scope even listed it as a fallback. It was removed: any website you visit can open a WebSocket to 127.0.0.1, and with no authentication, any page could have queued downloads on your machine.

The bridge uses the browser's native messaging instead. Chrome or Firefox starts a small helper program and talks to it over stdin/stdout, and only extensions whose ID is listed in the helper's manifest may connect. The helper then forwards messages to the running app over a local socket. That socket listens on a random port, and the port and a random token are written to a file only your Windows account can read. A connection that doesn't send the token first is dropped.

Some smaller problems came up on the way. An unpacked Chrome extension's ID is derived from its folder path, so moving the folder silently broke the bridge. A fixed public key in the manifest pins the ID. Edge reads native-messaging registrations from its own registry path, not Chrome's. And if the app wasn't running, the browser cancelled a download and handed it to nobody. Now the helper starts the app on demand, and the extension only takes a download over once the helper has answered.

Site downloads originally went through yt-dlp, run as a subprocess. On a long 1440p YouTube video, the first real-world report was a download frozen at 0.0%: the partial file was 0 bytes, and the app had no timeout, so it waited forever. Run without the browser's cookies, the same video downloaded, but at about 200 KB/s. YouTube throttles long single requests, and yt-dlp's concurrent-fragment option doesn't apply to plain HTTPS formats.

The fix splits the job. yt-dlp now only resolves which video and audio streams to fetch and returns their real URLs. TurboGet's own engine downloads both streams in parallel, over several connections, with every request capped at 10 MB, a size YouTube serves at full speed. ffmpeg then joins the two streams into one file without re-encoding. On the same video and the same line, speed went from about 200 KB/s to 3–4.4 MB/s, and pause and resume work exactly as they do for any other file.

Two more problems appeared during testing. Links obtained with logged-in browser cookies can be refused with a 403, so TurboGet now retries automatically with fresh, cookie-less links. Most public videos work that way. And asking for "best quality up to 1440p" quietly selected format 623, which turned out to be an HLS playlist (slow) rather than an HTTPS file. Format sorting now prefers HTTPS formats first, then H.264 up to 1080p, so the files play on any player. Downloads that make no progress for two minutes now stop with an explanation instead of sitting at 0% forever.

Quit didn't quit. In Qt 6, QApplication.quit() first asks every window to close, and the main window refuses, because closing it is supposed to minimise TurboGet to the tray. That silently cancelled the quit. The tray's Quit now calls exit() directly.

Quitting restarted the downloads it was stopping. On shutdown, running downloads are marked "queued" so they resume next launch. But each cancelled task's cleanup ran the queue scheduler, which saw queued downloads and started them again, so the app hung on exit. A closing flag now stops the scheduler during shutdown.

The installer ran out of memory. Inno Setup's compiler is a 32-bit program, and compressing about 500 MB at its highest LZMA2 setting failed with "Out of memory." Running the compressor as a separate 64-bit process fixed it, and the installer came out at 150 MB.

The rename. The project started as "SIDM." Renaming it to TurboGet meant moving the user's data folder, renaming the history database and the .sidmpart partial files, swapping the startup registry entry and re-registering the browser bridge under a new name, all without losing an unfinished download. Every one of those happens automatically on first launch.