Six integration landings: the three-pattern template that fell out

Six integration landing pages later — Zapier, Slack, QuickBooks Online, Samsara, Geotab, John Deere Operations Center — they all converged on the same three-pattern shape. Documenting the pattern explicitly because the next time we write one (Verizon Connect? Komatsu KOMTRAX?) the shape should be a 90-minute template, not a 4-hour invention.

The three patterns, every page

Pattern 1 — Minimal, 10-30 minutes

The lowest-effort path that delivers real value. For Slack this is the Incoming Webhook URL. For Zapier it's the Catch Hook + Slack-channel action. For Samsara/Geotab/John Deere it's the vehicle metadata sync that runs once at cutover. For QuickBooks Online it's the monthly CSV drop.

The defining property: zero code at runtime, zero infrastructure on the customer's side, executable in one sitting by someone who can use a browser. The cost: you trade latency or richness for simplicity. The trade is always worth it for the first integration.

Pattern 2 — Middle, 1-2 hours

The pattern most customers ultimately settle on. Some code — usually 30-100 lines — running on infrastructure the customer already has (a cron, a server, a serverless function). Pattern 2 typically uses the bulk endpoints (/api/v1/{resource}/batch) for migration-style data flow, or the receiver-side webhook verification helper for event-driven flow.

The defining property: real-time or near-real-time, with signature verification on inbound traffic. Customer pays the engineering cost but the runtime cost is zero (their existing infra absorbs it). The page always includes complete copy- pasteable code with the signature dance done correctly — that's the value the page provides that ChatGPT doesn't.

Pattern 3 — Deep, dependency on first customer

The expensive integration most customers don't need. For Slack it's a dedicated app with slash commands. For QBO it's OAuth + transactional integrity. For Samsara/Geotab/JD it's DTC routing into AI-narrated flags. For Zapier it's a Marketplace-published Zap template.

The defining property: shipped only when a real customer commits to using it. We've learned the hard way that building Pattern 3 before there's a customer leads to abandonware — the integration drifts as both sides ship features, nobody uses it, and the maintenance debt accrues silently. So Pattern 3 is always documented as "here is what it would look like + the prerequisites we've shipped on our side; email us to activate."

Why this works as a sales conversation

The procurement team can read the page and immediately know what activation looks like for their case. They don't have to call sales engineering to find out how much engineering effort the integration will cost. The three patterns are differentiated effort levels for exactly that reason.

The structure also handles the "what about my niche integration?" question without us having to write a bespoke landing per niche. Most niche integrations fall cleanly into Pattern 1 (use Zapier as a transformer) or Pattern 2 (write a 50-line shim against the receiver contract). The landing pages teach the customer the shape; the shape generalizes.

What we deliberately don't do

• Pre-build Pattern 3 for hypothetical customers. The only Pattern 3 we've built ahead of first-customer is the JD Operations Center OAuth flow — and only because JD's OAuth is a 90-minute spec to read, not a 4-week build. The DTC routing, the Slack app, the QBO OAuth UI? All scaffolded but inert until the customer ask makes them worth finishing.
• Make Pattern 1 too thin. A 10-minute Slack webhook setup is fine, but it has to actually workend-to-end with the example code in the page. If we trim the page to a screenshot and a "contact sales" link, customers correctly read that as "this integration doesn't actually exist."
• Hide the trade-off. Every page says out loud: "Pattern 1 is no code but lower fidelity. Pattern 2 is some code but real-time. Pattern 3 is the deepest integration but requires us building together." The honest framing is what makes the page useful instead of marketing pablum.

The template

Next integration page we write, it's this shape:

1. Lead paragraph: "X handles A; DirtFleet handles B; here's how to connect them."
2. "Why both" section: 2 paragraphs on what each system is good at and where they overlap.
3. Three patterns in order of effort. Each pattern has: title, one-sentence summary, "when to pick this" line, collapsible code block with the full setup.
4. Field mapping table when relevant (vendor field → DirtFleet field → notes).
5. "Honest scope" section: 3 bullets on what the integration explicitly doesn't cover.
6. Cross-link to related integration pages so mixed-vendor customers can land on the right page.
7. Footer: mailto link for first-customer activation of Pattern 3.

Six pages followed this shape. Two of them (Geotab, JD) landed in under 90 minutes after the third was written. The constraint is the value: every page looks and reads the same way, customers know what to expect, the marketing team can write the next one without engineering input.

→ All integrations · → Zapier · → Slack · → QuickBooks Online · → Samsara