10 Blog

We Build Hetk With AI. We Don't Run Hetk With AI.

Hetk has no AI features. We use AI to build the product, but not to run it. What that means for your data, and the line we drew.

Updated By Andrei Reinus

Yes, we use AI to build Hetk

Honest start: AI helps us write Hetk’s code. We use Claude (Anthropic’s model) for code generation, refactoring, tests, and review. A lot of recent commits in our repo were either drafted with Claude or read by it before they merged. That’s the truth.

What AI doesn’t do: write any code that runs in your sync engine, decide which events to copy where, parse your calendar data, or sit anywhere in the request path between your calendar and ours. The AI helps two engineers ship faster. It doesn’t ship inside the product.

If that distinction sounds too convenient, fair. Plenty of companies say “we don’t use AI” and mean “we don’t market AI features,” not “AI isn’t in our service.” So let me be precise about where the line is.

The line we drew at the product boundary

Here’s what counts as “in the product”: the sync engine on Azure App Service, the backend API that handles requests from the frontend, the Angular app you log into, the scheduled jobs that renew webhook subscriptions, and the auth path that talks to Google, Microsoft, and Apple. None of that calls any AI model. There’s no Anthropic key, no OpenAI key, no Gemini key in production. The dependency tree confirms it: zero AI client libraries.

Edge cases get the same answer. We don’t run AI on support emails. We don’t classify customer messages with AI. We don’t summarise anything you’ve sent us. If you email [email protected], a human reads it and writes back.

Here’s the why. Hetk’s goal is to be a simple product without too many bells and whistles. Adding AI doesn’t serve that simplicity. If you want an AI product, the rest of the market is selling you that. Reclaim, Motion, Amie’s “AI scheduling assistant,” Clockwise (before it shut down). They’re all chasing the same buyer. We’re not in that fight. Hetk does one thing: copy events between calendars. Adding an AI layer would mean either bolting a feature onto a tool you already understand, or rebuilding the tool around a feature you didn’t ask for. Neither helps you.

What that means for your data

Your calendar event lives in your Google Calendar. Hetk reads it through Google’s API, copies it to your Outlook calendar through Microsoft’s Graph API, and that’s the round trip. The data goes from one calendar provider to another, with Hetk’s sync engine in the middle. There’s no third party in the loop except the calendar providers themselves.

A scheduling AI works differently. To suggest a better time for a meeting, the AI has to read the meeting title, the attendees, the description. To respect a focus block, it has to know what kind of work you do. To propose a reschedule, it has to model your preferences. The AI provider receives all of that, processes it, and returns a recommendation. Whether the data leaves your tenancy, gets logged, gets used for training: those are questions you have to ask, and the answers depend on the AI vendor’s terms.

Hetk needs the same reads. Title, attendees, description, location. To copy an event we have to know what’s in it. The difference is what happens next. We don’t interpret. We move. The data isn’t sent to a third-party model for inference. It’s sent to your other calendar provider and recorded as a sync.

You can verify the supplier list yourself. Our subprocessors are Microsoft (Graph API), Google (Calendar API), Apple (CalDAV), Stripe (billing), Azure (hosting), and Cloudflare (DNS and CDN). The list is on our privacy page. No AI provider in it. If we ever added one, you’d see it there before you saw a feature announcement.

For buyers doing vendor reviews, that simplifies things. The data processor chain is short. The DPA only has to cover the providers on the list. There’s no “AI subprocessor schedule” to negotiate, no model-training opt-out clause, no question about whether the AI vendor uses your data to improve their model.

How we keep that line

Code we generate with Claude gets reviewed by a human before it lands in main. That’s the rule. AI-drafted commits go through the same pull-request process as anything else, including the part where we read the diff and ask whether the change makes sense. Nothing ships unread.

The dependency tree is the second guard. dotnet list package against the production projects shows every library Hetk runs on. There’s no Anthropic.SDK, no OpenAI, no LLM client. The frontend’s npm list is the same. Adding an AI provider would require a deliberate code change visible to anyone reading the repo, and that change isn’t in the plan.

If the line ever moves, you’ll hear about it from us before you see the feature. We won’t ship an AI feature and explain it after. We’ll say so first, in the release notes or on this blog, with what changes for your data. That’s the commitment. Softer than we could make it (we haven’t promised “never”), but specific about the order of operations.

For the full picture of how Hetk handles your data, see /security/. The subprocessor list is at /privacy/.

FAQ

Will Hetk add AI features later?

There’s no AI feature on the roadmap. If that changes, we’ll say so on this blog with what shifts for your data. The product exists to do calendar sync. AI features pull attention away from that.

Is the sync engine AI-powered?

No. The sync engine is a deterministic state machine. It reads events from one calendar, applies your privacy and direction rules, and writes them to the other. No model in the loop, no prediction, no inference. Just code following rules you set up.

Do you train AI on customer calendar data?

No. Customer calendar data doesn’t enter any AI training or inference pipeline. We don’t run customer data through Claude or any other model, even internally. Data goes from one calendar provider to another and stays there.

If a calendar sync tool that doesn’t try to schedule your day for you is what you want, start a 21-day trial. No credit card needed.

← All posts