How We Run Post-Sale Support for a Desktop Tool Installed at the Client

A desktop tool installed on a client's computer doesn't update itself, and when someone on the other end finds a problem, the most common way to flag it is a message lost in a WhatsApp thread. The admin dashboard behind our production desktop tools already had usage telemetry and error reporting (we cover the details in How We Monitor a Tool Running on Multiple Physical Kiosks at Once). What we hadn't shown yet was the other half of the cycle: how a new version leaves our machine and reaches the client's, and how a client's reply makes it back to us without getting lost along the way.

Publishing a version, in practice

The founder uploads the installer directly on the client's page inside the dashboard. Before anything else, the browser validates the file: the name has to end in .exe or .dmg, the size has to fall between 1 KB and 200 MB, and the file's own bytes have to match the format's real signature (an MZ header at the start for .exe; a koly UDIF trailer signature, always in the last 512 bytes, for .dmg). Only then does the upload go to Vercel Blob, signed, and the version record lands in the database: semver version number, size, file URL, and the client's current-version field gets updated in the same request. The moment the version is published, the message composer opens on its own, with subject and body already pre-filled with the download link for that specific version. Publishing and notifying became the same gesture, instead of two separate tasks that depend on remembering the second one.

Messages aren't just the founder sending email

Each client's message history is a two-way street. When a client replies to the email (from whatever email client they normally use, no login required), Postmark receives that reply and calls our webhook, verified by an HMAC signature. The system matches the reply to the right client by the sender's address or the In-Reply-To header, records the message as received in that client's history, and notifies us by email. If we're slow to reply, the client gets an automatic acknowledgment confirming the message arrived, capped at one per client every 6 hours, and it never fires if the reply comes from our own sending domain (to avoid an auto-reply loop).

Why this exists

Neither half solves an exotic problem. They solve the ordinary problem of anyone shipping bespoke software instead of SaaS: without a system, the trail of which client is on which version, and what's already been answered to whom, lives in the head of whoever built it, or in a manual search through an old conversation. Here, every version and every message stays tied to the right client, without depending on anyone's memory.

The gap that slipped by: email with no branding

Every message sent from the dashboard used plain text only, no HTML. It worked, but it clashed with the rest of the site: the welcome email, the payment confirmation, the automatic reply-received notice, all use the same moss-green card on an off-white background that is the brand's visual identity. We fixed that: the body the founder writes freely, with no formatting, is now split into paragraphs and rendered inside the same shared template, with a plain-text fallback for email clients that don't render HTML.

And the second one: it only ran on Windows

File validation only accepted .exe. A client on a Mac simply had no way to receive an update through the dashboard. We added .dmg alongside .exe, with its own validation: accepting any file that merely ended in .dmg wasn't enough, because a file extension is just a name, it proves nothing about the actual contents. .dmg has a real signature (the UDIF trailer, identified by the koly bytes at the end of the file), so validation reads exactly that trailer before accepting the upload, the same way it already did with the .exe's MZ header.

Publishing a version and replying to a client message aren't glamorous tasks, but they're the kind of thing that, without a system, quietly leaks trust: a client who's never sure the new version is the right one, or who sends a question and doesn't know if anyone saw it. If your operation also ships bespoke tools to clients and still depends on sending a file over WhatsApp and hoping someone sees the message, tell us about your context.