DEV Community: David

"ShuttleSCP, three weeks and 30 releases later"

David — Sat, 14 Nov 2026 14:00:38 +0000

Three weeks ago I wrote about building a real app with Claude Code: ShuttleSCP, a free SFTP, SCP and FTP client for Linux, macOS and Windows, written in Rust with GTK 4. It was at version 0.13.0. It is now at 0.26.0.

In between: 30 releases, the code grew from about 22,000 to about 34,000 lines of Rust, and the tests from 149 to about 200. Most of the work wasn't new buttons. It was making copies hold up on real networks and real servers, and being able to prove they did.

The "what's next" shipped first

The last article ended with one goal: make the Linux AppImage run on older systems. That was 0.14.0, the next day. It now runs on Ubuntu 20.04, 22.04 and 24.04 and on Debian 12 and 13, and every release is checked on all of them in containers before it ships.

Copying between two servers

The biggest new feature is site to site (0.15.0): one server in each pane, and you drag files from one to the other. The servers never talk to each other. ShuttleSCP reads from one and writes to the other at the same time, without storing the files on your disk, like scp -3. That means it works between any two kinds of server, even SFTP on one side and FTP on the other.

Making transfers survive real networks

Tests on a fast local network passed. Real servers found the problems:

Slow servers. Downloads from servers slower than about 0.4 MB/s failed with a timeout. The library waited for a whole batch of requests, not for each one. Fixed in 0.21.3.
Dropped connections. A lost SSH connection used to fail the transfer. Now ShuttleSCP logs in again by itself and continues the file where it stopped, up to three times.
Browsing during a copy. On one connection, opening a folder waited behind the copy's queued reads: seconds per click on a slow line. Transfers now get a second connection of their own.
Closing the app. Partial copies are kept. The next login offers to resume them, and the Login dialog has an Unfinished tab listing them.

Knowing the copy is right

Since 0.22.0, every copy is checked against its original by SHA-256 checksum. The server computes its side itself when it can (sha256sum over SSH, or FTP's HASH command). When it can't, ShuttleSCP reads the copy back, up to a size you choose. A copy that differs counts as failed, and a move keeps the original.

This is where testing on the Windows machine paid off: one FTP server answered the hash command with "501 Option not understood", and ShuttleSCP took that as a failure instead of "this server can't do it". It shipped as a fix two hours later.

A feature that changed after use

0.20.0 added a limit on transfers running at once. Using it, it was the wrong unit: one transfer of 500 files and one of a single file counted the same. 0.24.0 changed it to count files, oldest transfer first, with Start now to jump the queue. The first version wasn't wrong in the code. It was wrong for the person using it, and only using it showed that.

Two-factor logins

The newest release (0.26.0) logs in to servers that want a key or password and then a one-time code. I tested it on a VM set up with Google Authenticator, and the first finding wasn't a bug in ShuttleSCP: even with my key set up, the server still asked for my password. Its PAM settings put the Unix password in front of the code, so I was being asked for a key, a password and a code.

The design question was mine to answer. ShuttleSCP opens a second connection for transfers, and with two-factor each connection needs a fresh code. Two codes per session would be annoying. So on these servers, transfers now run on a second channel of the same SSH connection: one code per session. A dropped connection asks once more, and one login serves both.

Six languages, labelled honestly

The interface is in English, French, Spanish, German, Brazilian Portuguese and Simplified Chinese. I only speak English, so the translations were made with AI, and the app says so next to each language name until a native speaker reviews it. A test checks that every translation has the same messages and placeholders as the English.

A user guide, with clips the app recorded itself

0.25.0 added a user guide: Help › User Guide opens it offline in your browser, and it's online too. The clip above is from it.

The clips had to be anonymous: no real hosts, users or paths. Claude didn't screen-record. It wrote a debug-only recorder inside the app: a drawn pointer drives the real interface and picks the app's own Copy Here menu, in a made-up home folder, against throwaway servers with example.com names, behind a small relay that slows copies down enough to watch. GTK renders each frame, and ImageMagick builds the GIF. It took several rounds: menus didn't appear in the frames, the desktop took the focus away, and the renderer sometimes returned empty frames. Re-recording the clips is now one command.

Guardrails, and where they failed

The engineering around the app grew too: dependency checks against the RustSec advisory database on every change, weekly Dependabot updates, and secret scanning with gitleaks over the whole history.

The most useful lesson came from a failure. Claude's merge script once merged a pull request before CI had finished. The command it used to wait returned early, and a shell alias hid the exit code. Nothing broke, but it could have. The script now polls until no check is pending and merges only if every one passed. An assistant that is fast at writing code needs guardrails as strict as a new teammate's, and probably stricter.

What's next

ShuttleSCP is still a public beta, and I'm still learning Rust by reading what each change does. Next is more testing on real servers, and native-speaker reviews of the translations. If you try it, I'd like to hear what breaks, good or bad.

Download: [shuttlescp.dsalvado.ca](https://shuttlescp.dsalvado.ca/]
Code (GPL-3.0):github.com/dsalvado/shuttlescp

What I learned building a real app with Claude Code

David — Thu, 22 Oct 2026 17:24:45 +0000

Why I built it

I recently finished The Complete Claude Code & Claude Cowork Masterclass. A course shows you what Claude and Claude Code can do. It doesn't show you what it's like to lean on that tool for a real project, with real bugs and real releases. I wanted to find out.

I had a real problem to use. When I moved my laptop from Windows to Linux, the thing I missed most was WinSCP: my files on the left, the server's on the right, drag a file across, done. There are good file-transfer tools on Linux, but none felt like that to me.

So that became the project. The result is ShuttleSCP, a free, open-source SFTP, SCP and FTP/FTPS client for Linux, macOS and Windows, written in Rust with GTK 4. It's a public beta at version 0.13.0. This is what I learned getting it there.

How we split the work

The short version: I decided and checked, Claude wrote the code.

My background is databases and IT infrastructure, not Rust. So I worked the way I would with a capable contractor. I described what I wanted in plain words, it built it, and I tried it. A typical request looked like this one:

Can we add drag and drop? Files within a pane can be dropped into a folder. If dragging from source to target, a menu should come up asking if it's a copy or a move.

A while later there was a branch to test. I used it, said what felt wrong, and it went round again until it was right.

I also set the ground rules, and they mattered more than I expected:

Every feature goes on its own branch, and nothing merges until I've tried it.
Explain each step as you go. I wanted to learn the engineering, not just collect an app.
Never handle my passwords or keys. When something needed a secret, it gave me a script that asked me for it directly.
Be honest that an AI built this, in the README and on the web page.

I didn't read every line of Rust. I can't judge Rust idioms yet. What I did review was what each change did and why, and whether it behaved that way when I used it.

What worked

The speed is real. ShuttleSCP is now about 22,000 lines of Rust with 149 automated tests. It runs on Linux, macOS and Windows, and has had eight public beta releases. Alone, I'd still be reading the GTK documentation.

The bigger surprise was the engineering around the code. These are the parts a solo hobby project usually skips, and they got done properly:

CI/CD. Every pull request is linted and tested on GitHub Actions. Pushing one release tag builds, checks and publishes the Linux AppImage, the macOS disk image and the Windows installer.
Safe self-updates. The app checks a release manifest signed with an Ed25519 key, verifies the download's SHA-256, and swaps the file in one step.
Secrets in the right place. Saved passwords go to GNOME Keyring, the macOS Keychain or the Windows Credential Manager, never a plain file.
Release hygiene. A changelog, release notes and a security policy, from the first release.

It also checked its own work in ways I wouldn't have thought of. To review the look of every dialog, it built a debug mode that opens each window, saves a screenshot and quits. When I said the dialogs looked like old GNOME ones, it could compare before and after without me clicking through the app.

And I learned a lot. I asked it to teach as it went, and it did: why a release is tied to a git tag, what signing actually protects against, why you never reuse a version number.

What didn't

The failures were the most useful part, so here they are.

Bugs only a person finds

The tests passed and the screenshots looked fine, but using the app told a different story:

The first release built by GitHub Actions was missing GTK's add-ons. Icons didn't load and drawing fell back to software. It worked on my laptop because my laptop had them installed.
In the next release, choosing a theme did nothing, and odd colours showed under the menus. The packaging tool was quietly forcing the default theme.
My installed app started reporting itself as a "debug" build. Running a development copy had rewritten my desktop's launcher entry to point at itself.

Each was fixed quickly once I described it, and the first two now have automatic checks so they can't come back. But I had to notice them first.

Version numbers

I had already tagged and published 0.9.2 when more work was added under that same number. It had to ship as 0.9.3. A published version can't be reused, because installed copies may already have it. The lesson: check what's actually released before calling something "part of" a version.

Trusting the status line

At one point Claude told me it was waiting for a CI job to finish. I looked at GitHub Actions and nothing was running. The job had finished successfully, but GitHub never cleared its "in progress" label, and the AI was watching the label instead of the result. It was an honest mistake, and it was mine to catch.

What I learned about the work

Writing code turned out to be the smallest part of building software. The rest was still mine:

Deciding. What the app should do, what it should feel like, and what comes next. The AI offers options well, but someone has to pick.
Testing like a user. Every real bug above was found by using the app, not by the test suite.
Noticing. A wrong label, a stale status, a version that doesn't add up. Twenty years of production support helped more than any Rust knowledge would have.
Saying no. Some suggestions were good and still not for now. Keeping the scope small is what got releases out.

I think this way of working suits people who know a domain well and can tell when something is off, even if they don't know the language. It doesn't remove the need for judgement. It moves almost all of the work there.

What's next

ShuttleSCP stays in public beta while people try it. Next on my list:

Make the Linux AppImage run on older systems such as Ubuntu 22.04 and Debian 12. Today it needs a 2024-or-later distribution.
Keep fixing what testers find, one small release at a time.

If you use SFTP or FTP, I'd value your feedback, good or bad:

Downloads: shuttlescp.dsalvado.ca
Code and issues: github.com/dsalvado/shuttlescp

dsalvado / shuttlescp

A graphical SFTP, SCP and FTP/FTPS client for Linux, macOS and Windows, inspired by WinSCP. Two panes, drag and drop, resumable transfers. Rust and GTK 4.

ShuttleSCP

A graphical SFTP and FTP client for Linux, macOS and Windows, inspired by WinSCP: your computer's files on the left, the server's on the right, and copying between them is a drag, a right-click or a key press away.

Written in Rust with relm4 and GTK 4.

Status: public beta. It is used day to day on Linux and macOS, and the Windows version is new; feedback is very welcome: please open an issue See the changelog for what each release brought.

Features

Connections

SFTP and SCP over SSH, and FTP with plain, explicit or implicit TLS (FTPS), in passive or active mode.
SSH login with a password, a private key file (OpenSSH or PuTTY .ppk, with its passphrase if protected) or the keys of an SSH agent (the desktop's; on Windows Windows' OpenSSH agent or PuTTY's Pageant).
Saved sites, with passwords kept in the desktop keyring…

View on GitHub

The code is GPL-3.0. If you read Rust, a critical look at it is as welcome as one at the app.