The buyer doesn't care about your model choice
I worked for a physical product company that got some real crowdfunding heat. The product was legit. The "genius dev" behind it rode that wave straight into a FAANG job and left a crater where the software team used to be.
So I walked into a business with a manufactured thing in boxes, customers emailing daily, and a codebase that had to behave like a grown-up. Nobody wanted to hear about clever architecture. They wanted the app to connect, the firmware to update, and the support inbox to stop looking like a crime scene.
Pragmatists think this way. They don't buy your clever tooling. They buy the whole result.
If you tell them, "We built it with Claude," they'll nod politely and then ask:
- Does it install without a 12-step ritual?
- Do the docs exist, and do they match the current version?
- Will the integration survive the next API change?
- Who answers the ticket when their CFO is blocked at 4:30pm?
They're not being mean. They're trying to not get fired.
Pragmatists buy the "whole product," not the core feature
Geoffrey Moore calls it the whole product in Crossing the Chasm. The core product is the thing you built. The whole product is everything a normal company needs to successfully adopt it.
Enthusiasts will tolerate sharp edges. They'll paste stack traces into Slack and help you debug your own system. Pragmatists won't. They want to buy something that already looks like it belongs in their stack.
A lot of AI startups ship a model demo and call it a product. Then the buyer asks for SSO, audit logs, a migration plan, and a security doc, and the team acts confused.
They'll ask for:
- SSO and roles
- audit logs
- a migration plan
- a sandbox environment
- a security doc that doesn't read like it was generated from vibes
I hired a programmer once who aced the technical interview. Aced the personality interview. Aced the culture-fit conversation. Every stage, clean. I gave him a week of easy tickets to get his feet under him, then went to review the code. Nothing there. I tried pairing with him to unblock whatever was going on, and he just locked up. Turned out he'd cheated the entire hiring process and didn't actually know how to code — the plan, as far as I can tell, was to learn on the job before anyone noticed. That's what a slick AI demo is doing to a lot of buyers right now. It aces the interview. It answers every question in the pitch deck. Then you hand it a real ticket, and there's nothing underneath. I stopped using coding quizzes to gauge a programmer after that and built my own conversational interview instead — ask enough real questions and you find out fast whether there's a person in there who can actually build. Pragmatists are running the same interview on your product. Don't fail it.
AI is good at the boring layer, if you have taste
I'm a fan of the Lean Startup approach, mostly because it lets my creative side sprint ahead while my pragmatic side throws rocks at it.
Early in my career I built a custom BI system in C++ for AT&T. I even wrote a custom encryption algorithm so database credentials could be passed between machines. Was it cool? Sure. Did the business need it? Not really. An enterprise BI tool would've done the job and made everyone's life easier.
Same thing happens when you use AI to build the whole product layer. Teams overbuild the core and underbuild the boring stuff that makes the purchase survivable.
The funny part is LLMs are actually great at generating that boring stuff:
Documentation
Give the model your API schema, a few real examples, and your product vocabulary. Have it draft:
- quickstarts for different buyer types ("data team", "IT admin", "analyst")
- troubleshooting pages based on your actual support tickets
- upgrade notes that explain breaking changes like a human wrote them
Then somebody who knows the product has to read it. Otherwise you'll ship docs that sound confident and quietly promise features you don't have.
Integration scaffolds
Pragmatists ask for integrations because it means less custom code. Then the integration breaks in production, the vendor API changed, and your team is stuck reading logs and guessing.
Use AI to crank out:
- sample apps in the top 2-3 languages your buyers use
- reference architectures (with real constraints, not fantasy diagrams)
- migration checklists ("from vendor X to us") that include failure modes
Then use normal software engineering to prove it keeps working.
Traditional software still has to do the proving
LLMs can draft. They can't maintain. They can't run your CI. They can't watch production.
You still need the unsexy machinery:
- Docs publishing: versioned docs, link checking, search, changelogs
- Integration testing: contract tests, sandbox envs, CI that runs examples
- Support operations: ticketing, SLAs you can actually meet, status pages
- Security: auth, roles, secrets handling, audit logs, access reviews
If you're selling to pragmatists, these aren't "nice to haves." They're the product.
Rackspace sold me a title once: Senior Database Administrator, office in Austin, "exactly what I was doing at AT&T but more startup." The interview alone should've told me something — one of the DBAs printed out the Wikipedia article on 6th Normal Form and grilled me on it, like the depth of the quiz was the pitch. I took the job. Orientation got "temporarily" moved to San Antonio, in a mall the company happened to lease from its own chairman. After orientation I had a permanent desk, a permanent parking pass, and a salary 20% lower than what was offered, because bonuses "aren't guaranteed" and there's a cost-of-living difference between Austin and San Antonio that nobody mentioned before I signed. The actual job, underneath the title, was working the support ticket queue for anything with the word "database" in it — small e-commerce shops self-hosting on Rackspace who probably shouldn't have been, every hour of downtime billed to me as "thousands of dollars of lost revenue." The title was the demo. The ticket queue was the whole product. Nobody showed me the ticket queue until I'd already moved.
That's the gap pragmatist buyers are trying to close before they sign anything. They've been sold a title before. They've been sold a demo before. They ask about SSO and audit logs and migration plans because they want to see the ticket queue before they're standing in it.
The bottleneck moves from output to judgment
I picked up a contract with a services company to build an AI system that would improve accuracy for their loan underwriting process. The core idea was straightforward. The hard part wasn't the model. The hard part was deciding what "accurate" meant for the business, how to measure it, and what we would do when the system was wrong.
Same situation with AI-assisted whole-product work.
You can generate ten onboarding guides in an afternoon. Great. Pragmatists want to know which one matches what you actually support, and what happens when something breaks. They also want to know which guide quietly promises a feature you don't have, because they're the one who gets yelled at when it doesn't exist.
Pragmatists don't buy your prompt output. They buy your commitments.
A simple whole-product checklist I wish more teams used
If you want to cross from enthusiasts to pragmatists, try this:
- Can a stranger install it in under 30 minutes?
- Is there a quickstart for their job, not yours?
- Is there a reference customer in their category?
- Do your integrations have tests and a sandbox?
- Do you have a support process that's written down and followed?
If the answers are fuzzy, your model choice doesn't matter.
If you want help, I'll do a whole-product audit for AI startups trying to sell to serious buyers. We'll walk through your docs, onboarding, integrations, and support surface area, and we'll leave with a list of what to fix first.
-Sethers
