Why we built SideQuest as a local connector, not a SaaS
Every founder I know who heard about SideQuest told us to build it as a SaaS. We did the opposite. The reason matters if you're a distributor evaluating a tool that wants to see every PO you receive.
SideQuest runs on your computer. Not on our servers. Your incoming POs are read from your Gmail by a Python process living in your home directory. Your QuickBooks tokens sit in a config file in your home directory. The draft Estimates you build are stored in a SQLite file in your home directory. When you submit one to QuickBooks, it goes straight from your machine to Intuit's API. Nothing routes through us.
We made that choice on purpose. Three reasons.
1. Distributors won't put their order book in someone else's cloud
I spent six weeks pitching an earlier version of this — a SaaS — to distributors. Every meeting ended at the same sentence: "so where does the customer data live?" When I said "on our servers, encrypted at rest, SOC 2 in progress," I watched two operations managers visibly check out. One of them said, "I have a customer who I've been doing $4M a year with for fifteen years. If they find out I let some startup index every PO they ever sent me, the relationship is over."
That's not paranoia. That's table stakes. Distributors are stewards of their customer relationships, and the relationships have memory. A leak isn't a fine — it's a lost account. The SaaS pitch loses on contact with that math.
2. The compliance work is unbounded
The moment we route customer data through our servers, we become responsible for it. SOC 2. A privacy policy that holds up. A data processing agreement template. An incident response plan. A list of subprocessors. A breach notification process. Cyber insurance.
None of that is bad. All of it is six months of work that doesn't make our customer's life better. A local connector skips it: there's no customer data on our infrastructure to be compliant about. Our only datastore is a small Fly.io service that knows your license tier and a monthly PO counter. That's the whole scope.
3. The architecture is actually simpler
A SaaS version of SideQuest would need: per-customer OAuth token storage with rotation, a queue worker that polls Gmail at a sustainable rate, retry logic for QB rate limits, multi-tenant database isolation, observability, audit trails, a hot path for the heavy operations, etc.
The local version needs: a Python package the customer installs, an MCP server interface to Claude Desktop, two OAuth flows the customer does once, SQLite. Done.
The local version was four weeks of work. The SaaS estimate was eight months. We picked the four weeks.
What we give up
Honest cost: distributors who want a "set it and forget it" cloud product have to either run SideQuest locally on a workstation that stays on, or wait for a hosted version (which we may build for customers who explicitly want the trade-off). The local-first version doesn't run while the workstation is asleep — your POs queue up in Gmail and get processed the next time you open Claude Desktop.
In practice this is fine. Inside-sales reps open Claude Desktop the same way they open Gmail: every morning, all day. The window between PO arrival and processing is usually under an hour. For distributors who need 24/7 processing, we'll have an answer. We don't have it yet, and we're not going to invent one we don't believe in.
The architecture as a sales tool
The pitch we use now is one sentence: "your customer POs never leave your computer." The conversation that follows is fundamentally different from the conversation a SaaS pitch starts. The operations manager doesn't have to check with their CISO. The owner doesn't have to write a new vendor risk policy. It's a Python package and two OAuth flows.
If you're building anything in industrial-distribution back-office software and you haven't priced out the local-first version, do it. Then compare the customer reaction in the next ten meetings. We made the call and we've never regretted it.