Technology
AI & integrations
How we approach AI features, model providers, and third-party integrations.
Last updated 2026-04-27
AI features and third-party integrations are where most modern projects either flourish or quietly die. Both deserve the same engineering rigor as the rest of the system — not a "wrap an API and ship" treatment.
Our approach to AI
We build AI features that actually solve a problem in the workflow, not AI features that exist because everyone is shipping AI features.
What that looks like in practice
- Inputs are well-defined. "Take this document, extract these specific fields, validate them against this schema, return JSON." Not "do something useful with this document and we'll see."
- Outputs are validated. Every AI response is parsed, schema-checked, and either accepted or rejected. We don't ship UI that just dumps model output to the screen.
- Failure modes are graceful. When the model hallucinates, returns junk, or rate-limits, the user gets a useful error, not a blank screen.
- Costs are bounded. Token budgets per request, soft caps per user, hard caps per day. AI features should not be uncapped costs of doing business.
Model providers
We've shipped production work on:
- Anthropic Claude — current default for most workflows. Reasoning quality, tool use, JSON-mode, and rate limits are all best-in-class.
- OpenAI GPT-4 family — well-established, deep ecosystem of tools.
- Open-source models via Together / Replicate / Modal — when the workload is high-volume enough to justify it.
- On-device models for edge cases where data can't leave the device.
We don't pick the model based on hype. We pick it based on what actually works for the task, evaluated on real samples from your data.
What we won't do
- Wrap a chatbot onto every product. Most products are not improved by a chat interface.
- Train custom models as a default. Fine-tuning is rarely necessary; prompt engineering + RAG covers most cases at a fraction of the cost.
- Ship features that violate user privacy by default. PII goes through redaction; model providers' DPAs are reviewed before any client data is sent.
Third-party integrations
Most projects need to talk to other systems — CRM, payments, email, analytics, support, scheduling, etc. We've integrated with most major providers; here's how we approach it.
The shape of a good integration
- Idempotent. Re-running an import or webhook handler shouldn't double-create records.
- Backed off. Rate-limit responses are respected; failures are retried with exponential backoff.
- Observable. When something goes wrong we want to know in Sentry, not from a customer complaint.
- Clearly versioned. When the third party deprecates an API endpoint, we want to know which version we're on.
Integrations we've shipped
A non-exhaustive list:
| Category | Providers |
|---|---|
| Payments | Stripe (most common), Paddle, Square |
| CRM | HubSpot, Salesforce, Attio, Pipedrive |
| Resend, SendGrid, Postmark, Mailchimp | |
| Calendars | Google Calendar, Microsoft 365, Cal.com |
| Auth | Clerk, Auth0, custom SSO |
| Support | Intercom, HelpScout, Zendesk |
| Analytics | GA4, Plausible, PostHog, Mixpanel, Segment |
| Scheduling | Calendly, Cal.com, Acuity |
| Telephony / SMS | Twilio, Vonage |
| Maps | Google Maps, Mapbox |
If you need an integration that's not on this list, we evaluate the API quality (good docs? sane error responses? webhooks?) and price the work accordingly. Bad APIs cost more to integrate against — we'll tell you up front when one will.
Webhooks vs. polling
We default to webhook-driven integrations where the third party supports it. Webhooks are real-time, cheap, and don't burn API quota. When webhooks aren't available we fall back to scheduled polling on a sensible interval.
Vendor lock-in awareness
For any integration, we think about: if this vendor becomes a problem (price hike, deprecation, acquisition), how hard is it to switch? We'd rather pay slightly more for a vendor with a clean migration story than save a few dollars on something we can't get out of.