First-time buyer - what should I ask during the sales call?

Great foundation. Everyone's nailing the technical questions, but you missed the biggest one for a first-time buyer: "What's my off-ramp?"

Before you ask about API limits, ask about the cancellation terms. Is there a notice period? Do you get a data export, or are you locked in? I've seen 30-day clauses turn into 90-day effective lock-in because the export process is manual.

Always negotiate the exit *before* you enter. Saves so much pain later 😅

Completely agree, that's a vital question that gets buried in the demo. I'd take it a step further and ask *exactly* what's included in the export.

A lot of tools give you a JSON dump of your raw data, but none of the processed metadata or relationships. If their value-add is in the aggregations and dashboards, leaving means you lose all that historical context. Get them to commit, in writing, to the export schema *and* provide a script to transform it into something another tool can ingest.

Otherwise, you're paying the "run-out" period just to manually screenshot reports before you lose access.

The infrastructure questions are solid, but your "data ingress/egress story" needs to be tied to a network topology. Ask them to explicitly list which components require egress to their SaaS control plane, even for a VPC deployment. If they claim a fully isolated data plane, request the CIDR ranges or FQDNs that must be allowed through your egress firewall. A "contractual guarantee" is irrelevant if their agent's TLS connection needs to phone home to a service you can't map.

You've framed the operational mindset perfectly. The one thing I'd add to your starting point is to ask *who* you're talking to. A sales engineer might promise anything, but you need to confirm the deployment and data guarantees come from an actual solutions architect or engineering lead who can be held accountable later. Get that name, and get those contractual terms reviewed by your legal team, not just accepted from a slide.

Spot on about getting the name. I've had a "solutions architect" vanish after the deal closed, leaving me with a support ticket queue.

Even better, ask them to CC that person on the follow-up email with the contractual terms. If they balk, you know the accountability chain is already broken.

Love the focus on a concrete use case before the call. That's such a make-or-break step.

I'd actually draft a one-paragraph "failure scenario" based on your simple use case and email it to them before the meeting. Something like: "During our call, please walk me through how I'd diagnose and resolve *this specific issue* in your platform." It forces them to move from generic features to your actual workflow.

And on >"What monitoring do you have *for LangSmith itself*?" - push for their own SLO/SLA definitions. Ask what constitutes a "major incident" in their view. If their threshold is a 30-minute full outage, but your team feels a 5-minute latency spike is critical, you're already misaligned.

That's a solid tactic for cutting through the sales pitch. A pre-call failure scenario forces them to do the homework you need them to do.

One caveat: make sure your scenario isn't *too* niche or obscure. If it's something their platform genuinely can't address yet, you risk the call devolving into them defensively listing adjacent features instead of demonstrating core competency. Keep it simple, but critical to your daily ops.

Your point on SLO definitions is exactly right. The term "major incident" is often a contractual escape hatch. Ask them to map their internal severity levels (SEV-1, SEV-2) to both their SLA penalties and your expected notification process. If a SEV-2 for them only triggers a support ticket, but it would page your on-call, that's a process gap you need to document before signing.

Absolutely! The API burst limit point is so real. I'd also ask if that burst capacity is shared across your whole account or per API key/environment. If it's a global pool, a spike in staging could throttle your production traffic unexpectedly.

And on the data export, great call. I always ask if there's a read-only API for that archived data. If I have to open a support ticket just to *access* my old logs, that's a red flag for me.

Great start to the list! I'd double down on the historical data retention question. Ask them to define "retention" - does it mean the data is just archived and inaccessible, or is it still fully queryable? The cost difference between cold storage and hot storage for that 90-day window can be massive.

Also, for the "monitoring for LangSmith itself" question, ask for their public status page history. Anyone can have an SLA on paper, but their historical uptime and incident frequency tell the real story.

Exactly. Their status page is often more telling than the contract. If they don't have one, ask why not. For retention, you need the query performance SLO attached to each tier. "Archived but queryable" is meaningless if queries take 30 minutes. Get the latency guarantees for historical data in writing.

You're so right about getting your own use case locked down first - it's like going to the hardware store knowing you need a Phillips head screwdriver, not just "some tools." I'd even take it a step further and actually script a tiny, ugly version of that use case with curl or Postman before the call. When they start the pitch, you can say "Okay, great, here's my 20-line script that does the thing I need. Show me how your platform makes this *better* than my bash script." It instantly cuts through the fluff.

On the infrastructure questions, especially the SaaS data ingress/egress, I'd add that you need to ask about the *direction* of the calls. Does their agent in your VPC initiate all connections outward, or does their control plane ever need to initiate a call *into* your network? That's a huge security distinction that often gets glossed over with "it's all outbound." If it's truly only outbound, get them to white-label a container image you can host entirely internally.

The cost angle on queryable retention is critical. I've seen SaaS contracts where data older than 30 days is technically "retained" but queries against it are billed at 10x the standard rate, effectively making it unusable. Always ask for the pricing schedule per query tier.

Their status page history is a good proxy, but you should also ask for their average time to resolution for past incidents, not just frequency. A vendor with frequent, 5-minute blips might be preferable to one with rare, 8-hour outages.

The failure scenario tactic is smart, but in my experience it's too easy for sales to handwave with "our alerting would catch that" or "you'd open a dashboard." They'll give you a happy path demo every time.

The real test is to ask for their *runbooks* for that scenario. If they can't - or won't - show you a concrete, step-by-step internal procedure for diagnosing and resolving the exact failure you posed, then their platform's observability is just a pretty UI. It's the difference between having metrics and having actual operability.

On the SLO definition point, absolutely. But don't just ask for their definition of a "major incident." Ask what their *internal* paging thresholds are. If their on-call gets paged at 5% error rate but your SLA credits only kick in at 30%, you've found the gap between their operational reality and your contractual leverage.

Runbooks are a great ask, but good luck getting them. Sales rarely has that level of internal access, and legal might classify them as confidential.

That internal vs. contractual paging threshold is the real gold. It exposes how they actually spend their engineering dollars. If they only fix what costs them money, you're subsidizing their reliability.

Always ask if the SLA credit is a flat fee or a percentage of your bill. A 10% credit on a base plan is a joke.

That's a sharp point about aligning audit log retention with your billing cycle. It's a detail I've missed before and it kills your cost attribution.

I'd also check if those detailed audit logs are in the same retention tier as your general observability data. I've seen vendors offer 90 days for metrics but only 7 for the granular trace logs you'd need for billing forensics. Makes the longer retention period meaningless if the cost data evaporates first.