Daniel's been down a procurement rabbit hole again. Last time we looked at hardware — data sheets, vendor relationships, the whole ritual of finding the right physical thing. But he's been building evaluation matrices for software too, even hooked one up to an AI agent to do the market scanning for him. The question is whether there's a parallel career track for software evaluation — people who love deep-diving into SaaS options, forming vendor relationships, becoming the person everyone asks "which one should we buy?" He wants to know what these people are actually called, what backgrounds they come from, what the employment landscape looks like in twenty twenty-six, and how the whole build-versus-buy shift changes the value of the skill. And he's right that at a certain scale, building your own tool hits a compliance wall — most small to medium teams bolt on rather than build from scratch. So today we're mapping a career path that's surprisingly ill-defined for how much it matters, and why that's about to change.
The thing that jumps out at me right away is that this function exists everywhere and has no single name. Hardware procurement has certifications, established tracks, a whole profession with standards. Software evaluation is fragmented across at least four or five different job titles, and the people doing it often fell into it sideways. You'll see Technology Vendor Manager, Software Procurement Analyst, SaaS Selection Consultant, Technology Advisory Specialist — all describing essentially the same core competency, but nobody's organized them into a coherent ladder.
So the career exists, but you can't search for it on LinkedIn with one query and find all the jobs. That's... actually a pretty good litmus test for whether a field has matured.
And it hasn't. But the demand is real and growing. Let's start by figuring out what this function is actually called, because it turns out that's part of the problem.
I've seen "Software Procurement Analyst" most often on the in-house side. But that title undersells it — procurement makes it sound like you're ordering toner cartridges. The actual work is building evaluation matrices, running RFPs, negotiating contracts, and becoming the internal trusted source who knows which CRM has the best API documentation and which vendor's support team actually answers the phone.
The day-to-day is part investigative journalism, part technical architecture, part relationship management. You're not just comparing features on a spreadsheet — you're assessing vendor viability, integration compatibility, compliance certifications, and long-term roadmap alignment. The spreadsheet is the output, not the job.
That's the first misconception to kill, honestly. The idea that this is just feature-comparison busywork. A good evaluator is doing risk assessment on companies that might not exist in three years, and mapping their API ecosystems against a stack that hasn't been built yet. It's closer to intelligence analysis than shopping.
And the fragmentation in job titles means the career ladder is hidden. Someone who's great at this might spend five years as a "Business Analyst" or "IT Procurement Specialist" without realizing there's a whole adjacent world of external advisory roles that pay better and offer more variety. Hardware procurement has the Chartered Institute of Procurement and Supply — there's no equivalent certification body for software evaluation. Yet.
With the landscape set, let's dig into the specific roles — what people actually do day to day, what they get paid, and how you end up in this line of work.
So there are really three tiers. Tier one is in-house procurement teams at larger organizations — companies with five hundred plus employees typically have dedicated software procurement people embedded in IT or finance. Tier two is internal IT slash business systems roles where software evaluation is part of a broader job — you might be the Salesforce admin who also evaluates the next marketing automation tool. Tier three is external advisory — firms like Gartner, Forrester, and a growing number of boutique consultancies that do nothing but software selection engagements.
And the backgrounds are all over the place. I've seen people come in from IT procurement, sure, but also from business analysis, product management, even technical writing. The common thread is that they're the person who actually reads the documentation. Not skims it — reads it.
The salary data for twenty twenty-six is interesting. Mid-level Software Procurement Analyst roles are running eighty-five to a hundred and twenty thousand, depending on vertical and location. Senior roles — Technology Vendor Manager, Head of SaaS Procurement — are a hundred thirty to a hundred seventy thousand. And that's before you get into the advisory side, where independent consultants can bill substantially more on a per-engagement basis.
A hundred and seventy for someone who reads data sheets all day. Daniel's going to be very happy to hear that.
He's been training for this without knowing it. And here's the thing — those numbers have been climbing. The consolidation in enterprise software is actually driving demand up, not down. When Salesforce buys another dozen companies and Microsoft bundles harder, the integration landscape gets more complex. More complexity means more risk, and more risk means someone needs to be the person who can compare apples to slightly different apples and tell you which one won't rot in six months.
That's the counterintuitive piece. You'd think consolidation would reduce the need for evaluators — fewer vendors, simpler choices. But it actually makes the stakes higher on each decision, because you're betting on ecosystems now, not point solutions. Pick the wrong CRM and you're not just switching a tool, you're re-platforming half your sales stack.
Let me give you a concrete example. A mid-sized healthcare company in twenty twenty-six evaluating EHR systems. The in-house procurement analyst builds the evaluation matrix — weighted criteria, must-have versus nice-to-have, integration requirements with existing clinical systems. The external Gartner consultant provides the market landscape, vendor risk profiles, and comparative pricing benchmarks that the internal person can't get because they're not talking to twenty different vendors every quarter. Those two roles complement each other — internal brings deep organizational knowledge, external brings cross-market fluency.
How long do those external engagements typically run?
Four to twelve weeks is standard for a software selection engagement. Shorter if it's a point solution — picking an email marketing tool, say. Longer if it's an ERP or EHR where the implementation cost is in the millions and the switching cost is astronomical. The external advisor has to be vendor-agnostic — no kickbacks, no preferred partner arrangements that aren't disclosed. That's part of the value proposition. You're paying for objectivity.
And the internal person is building long-term relationships with a smaller set of vendors over years. They know the account managers by name, they know which vendors have good upgrade cycles and which ones break things on patch Tuesday. That institutional knowledge is genuinely valuable and hard to replace.
The career path into external advisory usually runs through the in-house side first. You spend five to eight years doing procurement or business systems at a couple of different companies, build up your vendor fluency across multiple categories, and then either join a Gartner or Forrester or hang out your own shingle as an independent Software Selection Consultant. The independents I've talked to say the hardest part isn't the evaluation work — it's the business development. You're selling trust to companies that have never heard of you.
That tracks. The skill set is portable, but the reputation isn't. Which is why the Gartner brand carries weight — they've already solved the trust problem for you, at the cost of taking a chunk of your billing rate.
And there's a fourth category emerging that Daniel's experiment touches on — the AI-augmented evaluator. Someone who builds the matrix and then deploys an agent to do the initial market scan and fill in the cells. That's not replacing the human, it's compressing the research phase from weeks to hours. But the judgment calls — weighting the criteria, reading between the lines of a vendor's SOC 2 report, sensing that a company's support team is about to be gutted by a layoff — those still require a person.
So those are the roles. But the bigger question Daniel raised is whether the whole build-versus-buy shift changes how valuable this skill set actually is. Let's unpack that.
The build-versus-buy tension in twenty twenty-six is different from five years ago. Building your own tool is more viable than ever — low-code platforms, AI-assisted development, open-source components that are actually production-ready. You can spin up a custom CRM on Airtable with a few AI integrations in a week. And for very small teams, that's attractive. But the research is pretty clear on where the line is.
Where's the line?
Under about fifty employees, building your own tool almost always costs more than buying. The total cost of ownership — development time, maintenance, onboarding, documentation, ongoing feature requests — runs three to five times what a SaaS subscription would cost for the same period. And that's before you factor in opportunity cost. Every engineering hour spent maintaining an internal tool is an hour not spent on the product.
Three to five times is a number that should make any founder under fifty people stop and think very hard. But I'm guessing that ratio flips at some point.
It doesn't so much flip as get complicated. Between fifty and two hundred employees, it depends heavily on the function. If it's a core differentiator — something that is actually your product or directly enables your competitive advantage — building can make sense. If it's a support function like CRM or HRIS, buying still wins on total cost almost every time. And then above about five hundred employees, or in any regulated industry, compliance becomes the dominant factor.
This is the part Daniel flagged — the compliance obstacle at scale. Once you're big enough that someone's going to audit you, building your own tool means your team owns the entire compliance burden. SOC 2, HIPAA, GDPR data residency, incident response plans, penetration testing, access controls, audit logging — the vendor absorbs all of that when you buy. When you build, it's on you.
Seventy-eight percent of organizations over five hundred employees prefer buying over building for core business functions specifically because of compliance overhead. That's not a small majority — that's a near-consensus. The exceptions are tech companies with dedicated security and compliance teams who can absorb that overhead, and even they tend to buy for non-core functions.
I want to pause on that number for a second. Seventy-eight percent. That means more than three out of four large organizations have looked at the build option and said no, not because the software would be worse, but because the paperwork would kill us. That's a structural advantage for SaaS vendors that isn't going away.
And it's actually getting stronger. The compliance landscape isn't getting simpler — GDPR enforcement is ramping up, state-level privacy laws in the US are proliferating, SOC 2 Type II is becoming table stakes for B2B. Every new regulation increases the compliance burden on custom-built tools disproportionately, because the vendor can amortize certification costs across thousands of customers while the builder pays it alone.
So the build trend is real but bounded. It's most viable for small teams building non-regulated tools, and for large tech companies building core differentiators. The vast middle — mid-sized companies, regulated industries, support functions — is still firmly in buy territory.
Let me give you a case study that illustrates the pitfall. A forty-person fintech startup in twenty twenty-six builds its own CRM on Airtable plus some AI integrations. Works beautifully for eighteen months — custom fields, custom workflows, exactly what the sales team needs. Then they go for SOC 2 Type II certification and realize their custom CRM has no audit log, no role-based access control, no data retention policies, and no way to generate the reports the auditor is asking for. They end up migrating to HubSpot at a cost of six engineering-weeks, plus the lost productivity during the migration, plus the embarrassment of explaining to the auditor why they need an extension.
Six engineering-weeks is an expensive lesson in why audit logs matter. And that's the thing — when you build, you don't think about audit logs on day one. You think about features. The compliance stuff is invisible until someone with a clipboard shows up.
Compare that to a three-hundred-person logistics company buying Salesforce. They spend three months configuring it — which is not nothing, Salesforce configuration is its own profession — but the vendor handles compliance. The internal team focuses on integration and workflow. When the auditor asks for access control documentation, Salesforce has a standard package they can download. That's the tradeoff. You trade configuration flexibility for compliance coverage.
And this is where vendor fluency becomes more important, not less. Daniel's right about this. Even if you're building, you're building on top of ecosystems — your custom tool talks to Salesforce APIs, or sits on AWS, or integrates with Microsoft. Knowing those vendors' pricing models, their upgrade cycles, their API deprecation policies — that's what prevents you from building a custom tool that becomes incompatible in eighteen months because someone changed an endpoint.
The integration tax is the hidden cost nobody budgets for. Every custom tool needs to talk to every other tool, and every one of those connections is a potential breaking point. A good software evaluator knows which vendors have stable APIs and which ones ship breaking changes in minor version bumps. That knowledge is worth its weight in engineering hours.
There's a knock-on effect here too. The rise of compliance-as-a-service layers — Vanta, Drata, Secureframe — has made building slightly more feasible for mid-sized companies. They automate a lot of the evidence collection and monitoring. But they don't solve the integration tax. Your custom CRM still needs to integrate with your marketing automation, your billing system, your customer success platform. Each of those integrations is a maintenance liability.
And the vendors are getting better at making their ecosystems sticky in ways that are useful. Salesforce isn't just a CRM anymore — it's an integration hub. Microsoft isn't just Office — it's an identity layer with Entra ID. The more value the ecosystem provides, the higher the switching cost, and the more important it is to have someone who understands the whole landscape before you commit.
So the build-versus-buy decision isn't really a binary. It's a spectrum, and the evaluator's job is to place the organization at the right point on that spectrum for each function. Build the core product, buy the support functions, and know enough about the vendors to make the integrations work.
And that's why the career path exists even as building gets easier. The evaluator isn't just comparing products — they're modeling total cost of ownership over a five-year horizon, factoring in compliance costs, integration maintenance, vendor viability risk, and the opportunity cost of engineering time. That's not a spreadsheet problem. That's a judgment problem.
It's also a communication problem. The evaluator has to translate all of that into terms that a CFO or a CTO can act on. "This vendor's API documentation is better" doesn't move a budget. "This vendor will cost us forty thousand more in year one but save us two hundred thousand in integration labor over three years" — that's the language that gets decisions made.
I'm thinking about the backgrounds again. The best evaluators I've seen have this unusual combination of technical depth and business fluency. They can read an API spec and a contract, and they know which one matters more in a given situation. They're not engineers, but they can talk to engineers. They're not lawyers, but they can spot a liability clause. It's a translator role.
Like a technical diplomat. You're negotiating between what the engineering team wants to build, what the finance team wants to spend, and what the vendor wants to sell. Three different incentive structures, and you're the person who has to align them.
The funny thing is, most people in this role didn't plan to end up there. They were a business analyst who got pulled into an RFP and discovered they loved it. Or a product manager who realized they were spending thirty percent of their time evaluating tools and decided to specialize. The career path is real but it's discovered, not prescribed.
That's the part I think Daniel will find both validating and frustrating. Validating because yes, this thing he loves doing is a real job that people get paid for. Frustrating because there's no clear on-ramp, no certification, no job board where all the listings live under one title.
The on-ramp is emerging though. Universities are starting to offer procurement and supply chain programs that include software evaluation modules. The big advisory firms have their own training pipelines. And the consolidation in enterprise software is creating a counter-current — companies that are worried about vendor lock-in are hiring evaluators specifically to maintain a competitive landscape map, even for tools they've already chosen.
That's a role I hadn't considered — the internal competitive intelligence person who doesn't evaluate to buy, but evaluates to know. Keeps a running map of alternatives so that if the primary vendor raises prices or degrades service, the company has a pre-built migration path.
That's the "de-consolidation consultant" niche. And I think it's going to grow. As more companies realize they've bet their entire stack on three vendors, the anxiety about lock-in increases. Someone who can say "here are the five best-of-breed alternatives to each of your core platforms, and here's what the migration would cost" — that's a valuable service.
That tension between building and buying — it turns out Hilbert has some personal experience with exactly this kind of evaluation, from a very different era.
Hilbert: GoldMine.
...Go on.
Hilbert: GoldMine CRM. Nineteen ninety-nine. I had a three-ring binder with printed data sheets for fourteen different CRMs. Carried it everywhere. SalesLogix, ACT, GoldMine, a few others nobody remembers. Salesforce was the new one — nobody trusted it because it was browser-only and half our sales team worked offline on laptops in hotel rooms.
GoldMine had offline sync. That was the killer feature at the time.
Hilbert: It was. And on paper, on the matrix — and I had a matrix, weighted criteria, the whole thing — GoldMine won. Best offline support, decent contact management, reasonable price. We signed the deal. Eighteen months later the dot-com bubble burst, the company went under, and GoldMine got acquired and effectively shelved. The vendor died. All that evaluation work, the binder, the matrix, the late nights comparing feature lists — it didn't matter because the company behind the product didn't survive.
You picked the right product and the wrong company.
Hilbert: That's the thing nobody talks about. Today you're evaluating not just the software but the company's survival odds. Funding runway, leadership turnover, acquisition history, support team morale if you can sniff it out. It's a different skill. In ninety-nine, I didn't even think to ask about the vendor's balance sheet. I was twenty-four and I thought the best product wins.
Did the CRM choice contribute to the company going under?
Hilbert: No. The bubble burst and took half the tech sector with it. We would've gone under no matter what CRM we picked. But I kept that binder until twenty fourteen. Moved it between four apartments. Never opened it after two thousand one, but I couldn't throw it out. It was... a relic of a simpler time. When you could fit the entire CRM market into fourteen printed data sheets and a three-ring binder.
What finally made you recycle it?
Hilbert: Moving to a smaller place. My brother-in-law helped with the boxes and said "you've been carrying this thing for thirteen years and you've never once needed it." He was right. But I think about it every time someone says "just build the matrix and the answer will be clear." The matrix tells you what's best today. It doesn't tell you what's going to be best in eighteen months.
That's the vendor viability piece. And it's harder now than it was in ninety-nine. Back then, most enterprise software companies were independent. Now half the market is owned by private equity, and the other half is getting rolled up by the big three. Evaluating a vendor means evaluating their owner's incentive structure.
Hilbert: The binder had a section for "company background." I'd write down the CEO's name from the press release. That was it. Today you'd need a section on funding history, acquihire risk, whether their engineering team is in a country that might have export controls imposed next quarter. The complexity scaled up but the job is still the same thing — someone has to read all of it and make a call.
The thing about the binder — you kept it because the evaluation itself had value to you, even after the decision was obsolete. That's the part Daniel was getting at. The satisfaction of the deep dive, of knowing you did the work.
Hilbert: Yeah. The binder was proof I'd done the work. Even if it didn't matter in the end.
It mattered. It just didn't save the company. Those aren't the same thing.
Hilbert: I suppose not.
With that historical perspective in mind, let's wrap up with where this might be heading.
The open question I keep coming back to is what happens when AI agents get good at the initial market scan and matrix-filling that Daniel was experimenting with. If an agent can survey the CRM landscape, populate eighty percent of the evaluation criteria, and flag the outliers for human review — what's left for the human evaluator?
Relationship management and risk assessment, I think. The things Hilbert just described — sniffing out whether a vendor's support team is about to be gutted, reading between the lines of a funding announcement, sensing that a company's culture has shifted in a way that's going to affect the product. AI can't do any of that, and won't be able to for a while.
The translation function we talked about — turning technical evaluation into business language that moves budgets. That's fundamentally a trust-based role. The CFO doesn't trust the AI's recommendation; she trusts the person who's been right three times in a row.
The twenty twenty-six trend toward vendor consolidation might actually create the niche I mentioned earlier — the de-consolidation consultant. Someone whose entire job is helping companies avoid lock-in by maintaining a live map of best-of-breed alternatives. It's the evaluator role inverted — instead of helping you pick a vendor, they help you stay ready to leave one.
That's a security blanket service, and I think companies would pay for it. Especially mid-sized companies that are big enough to feel the pain of lock-in but not big enough to have a dedicated procurement team. A quarterly competitive landscape report with migration cost estimates — that's a retainer business model.
If you take one thing from this, it's that the career path exists but you have to navigate it intentionally. The job titles are fragmented, the on-ramps are informal, and the people who thrive in this work often don't realize it's a specialty until they've been doing it for years.
The skill that matters most isn't the spreadsheet — it's the judgment. Knowing when to build and when to buy, which vendor's going to be around in five years, and how to translate all of that into a recommendation that actually gets followed. That's the thing you can't automate.
This has been My Weird Prompts. Thanks to our producer Hilbert Flumingtop for keeping the show running, and for the three-ring binder story that I suspect will stick with me longer than most of today's data points.
If you love data sheets, deep dives, and being the person everyone asks "which one should we buy?" — there's a career for you. It's just not well signposted yet. We'll be back soon.
Email the show at show at my weird prompts dot com. See you tomorrow.
