Why Proffer is Microsoft-only at launch (and why that's not a limitation)

The first question almost everyone asks about Proffer is whether it works with Google Calendar. The honest answer, today, is no. And that was a decision, not an oversight.

I want to explain the decision, because the reasoning behind it is the same reasoning that shapes everything else about the product.

A targeting decision, not a limitation

Proffer is built for a specific kind of person: the attorney who would never paste a booking link into an email to a client, the advisor whose whole business is trust, the coach scheduling with a C-suite calendar, the banker coordinating a board. These are people who schedule through email because email is how serious professional relationships are conducted.

That population lives in Microsoft 365. Law firms, financial services, professional services, enterprise sales — Outlook is the desk they work from. So launching Microsoft-first isn't a smaller version of the product. It's the product, pointed directly at the people most likely to feel the thing it fixes.

Building Google support at the same time would have meant doing two things adequately instead of one thing well. For a launch, that's the wrong trade.

The mailbox is the whole point

There's a second reason, and it's the more interesting one.

When you send a Proffer, the email goes out from your own Outlook mailbox. Not from a Proffer address, not from a notification service — from you. Your recipient sees a normal email, the kind they'd expect from a colleague, with a few times to choose from. Nothing about it announces that a tool was involved.

That's only possible because Proffer connects directly to Microsoft Graph and sends through your real mailbox. The integration isn't a convenience bolted on top of the product — it's the mechanism that makes the product feel like correspondence instead of software. Doing that well for one platform is worth far more than doing it loosely for two.

The layer we didn't build

There's an engineer's instinct, when you know a second integration is coming, to build an abstraction over the first one — a calendar-provider layer, neutral interfaces, the scaffolding to make the eventual Google work drop in cleanly.

We didn't. Proffer talks to Microsoft Graph directly, in Microsoft's own terms, with none of the indirection you'd add to anticipate a provider that doesn't exist in the product yet.

The principle is one I hold to across everything I build: first things first, second things never. Build for what's known now. The abstraction you write today to serve a future you're guessing at almost always turns out to fit that future badly — and in the meantime it's slowed down the thing in front of you. When Google support arrives, it will take whatever shape it actually needs, informed by a real, paying Microsoft customer base telling us what matters. That's a far better starting point than a layer designed in the dark.

The honest part

None of this helps you if you live in Google Workspace. If that's you, Proffer can't serve you today, and I'd rather say so plainly than wrap it in a roadmap promise with a date I can't defend.

Google support is planned. It's a v2, not a someday — and a live Microsoft customer base is exactly what strengthens the case for building it well. But it isn't here, and pretending otherwise would be the kind of thing Proffer is meant to be the opposite of.

The whole product is an argument for doing one considered thing rather than a scattered handful. It would be strange to launch it any other way.

— Joey