Integrations that build and maintain themselves.
Your own integration factory builds a custom integration for each customer, serves it inside your product, and keeps it maintained. Every change comes to you as a pull request. You decide what ships.
“What happens after launch” is the right frame. The version of it we see: the app works, then customer 2 connects their Salesforce and a field they renamed in 2023 breaks the sync. Fake users won’t find that one. Only a real customer org does. 2 years of production is mostly 2 years of other people’s setups.
@vasuman Good luck to him. One thing worth asking any team he talks to: how many customer integrations does the FDE own after month 3? At Palantir the platform does the heavy lifting. At a 50 person SaaS the FDE is the platform. Very different job with the same title.
@mardehaym Step 4 is the one that saves you a year later. “Where it runs and who owns it.” Every workflow with a number attached is reading from a CRM or an ERP, and the sync is the part that breaks when nobody owns it. Put the integration owner on that page too.
@humphreybc “Uses the systems of record” is the bet that matters for everyone selling to enterprise. Our experience: the agent is only as good as its door into Salesforce or NetSuite. Someone still sets up the auth, scopes and field map per customer. That part hasn’t got cheaper yet.
@jeromedruss yes, the login history pull is the right first move. the thing we add to it: filter by integration user, not just API. half the scripts we find are running under a real person’s login who left in 2023.
100 days from today, Salesforce stops username and password logins for API access.
20 Feb 2027. Every org, same day.
If your product talks to a customer’s Salesforce, check how it signs in. JWT bearer or client credentials on an External Client App is the way through.
Source: Salesforce’s Winter ‘27 release update, “Retirement of OAuth 2.0 Username-Password Flow for Connected Apps”. Enforcement is 20 Feb 2027. Move to JWT bearer or client credentials on an External Client App before then.
https://t.co/aoZUy2RxnW
Point 4 is the one I’d underline. “You can’t just turn an agent on” is true for every integration we’ve shipped too. The agent is ready in a day. Getting it to read this customer’s pipeline stages and custom objects correctly is the 2 weeks. Hands on help isn’t a cost, it’s the product.
@swerikcodes The 23 days to $30K is the fun part. Curious what the B2B pivot taught you about the un-fun part. For us it was the first enterprise customer asking for a Salesforce sync, and the vibe coded version lasting exactly until customer 2 had different fields.
@RampCapitalLLC Agree, and the weekend is real. The 18 months didn’t go away though, it moved. It now starts when the first paying customer says “we’ll sign if it syncs with our NetSuite”. That’s the part no one builds in a weekend, and it’s where most of the money is.
@a16z “Know their particular domain” is the part that holds up. The model is the same for everyone. What a SaaS company has that a lab doesn’t is 200 customers’ HubSpot and Salesforce data already mapped and flowing. That’s the moat. The agent on top is a feature.
“The data is accessible” is the one that quietly fails. Orders into the ERP with the CRM kept in sync reads like one line item. In practice it’s each company’s custom fields and a sync that breaks when someone renames one. Worth asking who owns that sync before picking the first one.
The second station for most SaaS is the customer’s other systems. First integration ships in 2 weeks and the demo sings. Then their NetSuite has 3 subsidiaries and a close process nobody wrote down. “Outcomes owner” is right. Half the job is reading their data before promising the number.
The last bullet is the whole decision. Per seat vs usage is maths. The forward deployed team is insurance. From the vendor side we see the same: the contract that survives a bad weekend is the one where a named engineer already knows your org’s setup. Do they give you a name, or a queue?
@yurshevv Clicks is a smart way to show it. The place this breaks for us is integrations. The agent builds the HubSpot sync in an hour. Then customer 4 has a custom object and the hour turns into 3 days. The agency bill goes away, the maintenance bill doesn’t.
@guilleflorvs “Load-bearing” is the right word. For SaaS the load-bearing part is almost always the integration. Once your sync is what feeds their Salesforce reports, you don’t get churned, you get budget. We’ve seen 1 integration do more for retention than a year of features.
@ChrisStathis5 Good role to hire for. One thing from doing it on the integration side: the FDE’s first job is rarely the model. It’s getting data out of the customer’s ERP or CRM in a shape the model can use. Worth putting that in the job description so the right people apply.
@HououinTyouma The first meeting with reality is usually a customer’s Salesforce org. 400 custom fields, a validation rule from 2017, an integration user nobody remembers creating. The FDEs who last are the ones who read that before writing a line. Takes a week, saves a quarter.
in your last 5 deals, how many had a specific integration on the must-have list?
not “do you integrate”. a named system.
most teams we talk to have never counted.