Chauffeur

Hey IH 👋

I'm a solo dev. The problem that drove me nuts: losing my "working state." Deep in a task with 6 files open in my editor, a few Excel sheets, a dozen browser tabs, a Notepad++ window — then a reboot, a task switch, or a Windows update wipes it all, and rebuilding it by hand kills the flow.

So I built Chauffeur: a local Windows context service that captures the working state of multiple apps (open files, tabs, projects) and restores it on demand. Think "save game" for your desktop.

Why I'm posting (the part I'm proud of):

Everything runs 100% locally — no cloud, no account, no telemetry. A small background service exposes a local REST API, and each app integrates through it: Excel, browsers (Chrome/Edge), VS Code, Notepad++, and more. No data ever leaves the machine. In a market where every productivity tool wants your data in their cloud, "it all stays on your PC" turned out to be the feature people react to most.

Stack, for the curious:

- Core service in C++ (Qt 6), local REST API

- Desktop GUI in TypeScript

- Add-ins per app (C# VSTO for Office, JS browser extensions, a VS Code extension, a C++ Notepad++ plugin) — each registers with the core over the API and heartbeats

- Licensing/payments via Paddle (merchant of record, so I don't touch tax/VAT myself)

The architecture fork I want to talk about — in-process vs out-of-process plugins:

Early on I had to decide how other apps plug into the core, and I ended up running two different models on purpose:

- In-process plugins are C++ shared libraries the core loads directly into its own process, behind a plain extern "C" boundary. Fast, share memory with the core — perfect for trusted, first-party, performance-sensitive stuff. The cost: a misbehaving plugin can take the whole core down, and the ABI has to stay stable forever (every signature change is an extern "C" entry point you carry around).

- Out-of-process add-ins are separate processes — the Excel VSTO add-in, the browser extensions, the VS Code extension. They don't share memory; they register with the core over the local REST API and heartbeat. If one crashes, hangs, or gets killed, the core just sees a dead socket and moves on. No shared address space, no ABI headaches, and the language becomes irrelevant — C#, JS, whatever speaks HTTP.

The lesson that surprised me: the question isn't really "C++ or Python or JS for plugins" — it's in-process or out-of-process, and the language question mostly answers itself after that. The process boundary buys you crash isolation and language freedom for free; you only pay the in-process cost when you genuinely need low-latency, in-memory calls.

Where I'm at:

Live and selling. Chrome & VS Code extensions published, installer signed, ships as one Windows setup. Now I'm at the part every solo founder hits — distribution. Building it was the easy half. 😅

What I'd love feedback on:

1. Does "local-only, no cloud" land as a selling point for you, or is it a non-issue?

2. For a paid Windows utility like this, where did you find your first real users?

3. Anyone integrated with Office VSTO / browser extensions and have war stories? I have a few.

Thanks for reading 🙏