Safe Vendor Selection is Hard!

Every week another vendor is going bankrupt or calling it quits. Every week another vendor is getting acquired. Most of the startups, even the over-funded ones, are not going to make it. Even assuming you know what functionality you need, it’s very hard to select a vendor that is not only good for you but likely to be around for the length of the initial engagement, which is probably 3 to 5 years (mid-sized to large) because, any shorter, and you’re spending more time on vendor evaluation, selection, implementation, and integration than actually using the vendor’s product! (And even if you can get a year-to-year contract, you know you still want the solution to last for at least three years to get a return on the time you spent investigating, selecting, and implementing the solution … which might only hit majority adoption at the end of the first year!)

So how do you select a vendor that is not just “good” but “safe”?

Well, let’s go back to our process for vendor assessment and selection.

Stage 0: Find a reasonable candidate pool based on your needs based on quick high level assessments.

Stage 1: RFI Creation

This is where you focus on weeding out vendors that

  1. don’t have technology that might actually solve your problems (without getting into deep details and demos)
  2. don’t have the necessary (cyber) security and privacy protections (especially if you are processing payments or private data and have to comply with industry and governmental regulations)
  3. are just too risky from a viability perspective for you to deal with
  4. don’t give you a back-up plan if something goes wrong

If it’s a point-based best-of-breed solution designed to solve one problem that could be replaced with another solution through the API, you can probably take a bit of a risk. But if it’s a foundational sourcing execution or procure-to-pay platform that is going to power your sourcing events and category management or your procure-to-pay process, this is not a vendor you can afford to have shutdown or get acquired by a buyer who doesn’t want to support it (because they’re buying for the customer base or dev team).

So how do you figure this out? It’s not perfect, but as we pointed out before, you calculate the relative corporate debt. If it’s too high, the vendor is not financially viable, even if it is “well funded” because most investors, even PE, won’t wait more than 5 years for their return — which is hard to get in tight economies when they invested at a multiple that’s (way) too high — and typically any multiple above 5X to 7X IS if you want a return in 5 years. (That’s why you always need to ask who’s funding your ProcureTech Vendor. If it’s customers, you’re safe. If it’s PE, you have to investigate deeply. A few firms are willing to wait [more than 5 years] for their return if the long-term is very profitable. But a lot of firms are of the “strip-and-flip” mentality, and that’s not good for anyone. And those in between start losing patience around the 3-year mark if they don’t see the sales growth they want, even if their growth expectations are ridiculous!) Collect the key financials and run the equation.

As for security (and privacy), you ask for their SOC 1/2 and certifications and any other certifications that are mandatory or designated as essential by your risk management department. If they don’t have the minimum, you drop them (unless they are in process).

As for functionality, you ask them to describe (at a high level) how they support your key core requirements. The in-depth descriptions and demos come during the RFP process later. The key to selecting a “safe” vendor and not being pressured to select a possibly “unsafe” one because you didn’t do all the right checks until after you fully verified the tech (and you can’t start the process again) is to do the majority of key non-tech validations up front, not at the end.

Moreover, by doing this analysis up front, you ensure that you aren’t wasting time analyzing vendors you can’t risk from a business perspective! Capability assessments take time. If you wait until the end to look at viability, you’re wasting a lot of time whereas the RCD calculation, certification verification, and verifying key requirements of other stakeholders often takes a fraction of the time as the in-depth tech assessment.

As for the back-up plan, here’s all you need to ask up-front:
Can I export 100% of my data, in a standard format, anytime I want it?

Not 90%. Not 95%. Not 99%. 100%!

Not submit a request and ask them to export a database or wait for a weekly backup process to backup and shoot you a copy. Request on the fly, it zips up (possibly into a multi-part archive) on the fly, and you can download on the fly.

If you can always get all your data, then, even if you mess up on the risk or viability assessment or something unforeseen by both parties happens, you have the most critical thing — your data — and you can always go with the next best solution! (And then make sure the clause is in the contract because it’s the most important clause in the contract.)

Now, this isn’t a complete list of requirements, as it will depend upon the industry and geography you are in and what type of solution you are selecting, but it’s a good start!

How Does a Vendor Build a GOOD Solution?

Two posts ago on the top final procurement concern of today (and the last five and the next three years) we told you that Gen-AI, which is (still) the tech-du-jour, is not really any different than every other tech-du-jour that we’ve had over the last two decades and, like all these preceding technologies (that were all over-hyped), it is not the panacea that will solve all your problems (despite claims to the contrary) and is, in fact, simply the latest incarnation of silicon snake oil.

Then, in our last post, we asked, and answered, why most (new) vendors are building on it. There are a host of reasons — which include greed, low TQ, hype, and cluelessness — and none of them are good. That’s why, as we stated, most (AI-first) start-ups today SUCK, and, to be honest, why most start-ups in our space suck in general (and do for at least the first few years of their existence, even if they aren’t AI first).

But we also told you that we’d tell you how a vendor can build a good solution, starting with V1. Just like selecting a solution that actually works is possible 80%+ of the time (if you follow the right method that we outlined in our series on Successful Vendor Selection Series, because, otherwise, your chances of success are about 12%), there are best practices that will maximize your chances of success. But like solution selection, don’t expect any of the big analyst or consult firms (that depend on never ending hourly support contracts) to give you any real advice! (They are all instances of The Vendor in Black … Comes Back!)

1A. Get Relevant Procurement Experience and Insight
By this I mean that if you’ve only worked for one or two companies and only done things one or two ways, you don’t really understand what Procurement needs generally — you only understand what your companies needed and what very similar companies in your niche industries need. With limited experience at one or two companies, you’re not building the perfect solution for the industry, you’re building the perfect solution for YOU, and YOU may not represent the majority of the market!

You don’t have this in your late 20s, or even your 30s. You have this in your 40s. (And then to run a successful startup, you need management experience — that’s why they’re saying 50 is the new 30 for startups … by then you truly understand what is needed and likely have the management experience to pull it off.) Any earlier/younger than this, and you better engage some real independent Procurement experts to help you define what you really need to do to address entire verticals or wide swaths of the market.

1B. Get Relevant SaaS Development Experience
You also need real SaaS Development Experience. The ability to vibe code, the ability to use low-code / no-code solutions, and even the ability to write web script DOES NOT COUNT! Script kiddies don’t build enterprise apps — the dot com boom and bust (which some of us remember — and the rest of you need to study because the Gen-AI bust could be as bad) made this clear. You need real, educated, experienced developers and architects who have worked in real tech companies building, deploying, and actually delivering enterprise apps! These are the only resources who build enterprise apps.

Now, it’s very, very unlikely you have both. That’s okay. That’s why you get the perfect partner that compliments you so that you collectively possess CPO (Chief Product Officer) vision and CTO capability from day one. Then, if the Procurement Expert founder is not a CEO, the two founders seek a third founder who is a real CEO with relevant C-Suite domain experience, and if the Procurement Expert founder is a CEO, the two founders seek a real domain expert who has product management experience who can be the CPO.

2. Define the problem you want to solve in detail!
What is the real pain point? What does the solution look like? How do you measure it? How do you get there?

Once you’ve answered the key questions and fully defined the problem, define the process that solves it. Then define the variations to the process. I.E. What are the core, required, steps. What are additional optional steps. Where might approvals or sub-processes be required in specific situations.

Then define what can be automated, what needs to be done by a human, and where there are multiple options.

Only once you fully understand the process and variation across companies of different sizes, categories of different complexity, and departments of different maturity in the verticals you are going for can you attempt to build a platform that will support it.

3. Identify the minimally appropriate and best-match algorithms for each process step and the best tech for stringing the algorithms together.

Some steps will just be collecting information on a form, validating the response type with regular expressions, and validating the data with third party integrations … and possibly require a(nother) user to accept it. Other steps will just be running pre-defined analytics and suggesting or taking an action based on the result, possibly using a rules-based multi-select with adjustable parameters. Others will be RPA auto-execute based on previous steps. Others still will be machine learning based on collected inputs from previous steps. And so on. (Very rarely will you need advanced AI and rarer still will you need [anything close to] Gen-AI. This is another reason AI-first is so wrong!)

When you go through this process, you will find that not only do most steps not require any (Gen-)AI at all, but most are better served without AI. You’ll find it only fits in the few situations it is good at (natural language processing, large document search and summarization, potential pattern identification, etc. for Gen-AI), and that if you apply it, you should do so narrowly, with custom trained models with guardrails and, if possible, have users accept recommendations to modify rules to reduce dependence over time.

4. Remember that good enterprise solutions have MDM (Master Data Management), Workflow, and Orchestration at the core.

These are not after thoughts. In addition, if you plan to support global users or sell your solution globally, multi-language support and internationalization MUST be at the core as well.

5. Select a programming language and an enterprise stack that supports ALL of the requirements identified above.

Not the stack that is cool, the stack that makes it super simple to get MVPs out the door, the stack used by your favourite AI platform, the stack recommended by your favourite cloud provider, but the stack that will work for the enterprise application you want to build. Then select the cloud provider — most of them are pretty competitive, and most of them support the majority of enterprise stacks, especially if they are not Microsoft (which wants a .Net/C# Azure Friendly Stack).

6. Plan out three years of major features.
These major features will support additional process extensions and related processes as there’s no significant shelf life for a niche app that only does one thing unless that one thing is so complex that almost no other application does it and the cost of building such an app from scratch by a new startup is prohibitive (especially relative to the untapped market potential).

Too many startups define the MVP, race to build the MVP, and then try to figure out what comes next. This is equivalent to shooting yourself in both feet with your brand new shotgun.

1) While you’re trying to figure out what to do next, your competitors are already building it.

2) By failing to define where you are going, you’re taking shortcuts and building the foundations for a dinky niche SaaS app versus a full-fledged enterprise application. The way I like to explain this to non-technical folk is that if you’re designing to MVP, you’re building the foundation for a two-story house and that means all you can ever build on that foundation is a two-story house. When you’re thinking three years ahead, you’re building the foundation for a multi-story apartment complex, building the first floor, and just pausing before you build the second floor. (And so on.)

In the first case, once you figure out what comes next, you realize you don’t have the right architecture or infrastructure, and then have to stop and rebuild the core, slowing down your advancement and future releases even more unless you can miraculously define the minimal API to the core you will be rebuilding up front, simultaneously build the new features perfectly to that API while trying to re-architect the core, and somehow fully achieve that API and don’t have to change it significantly during implementation when you find out it just won’t support the required workflow or orchestration … which it inevitably won’t, and then you need to update the API, and then this necessitates a rewrite of the business logic layer (and even UX) on the fly, which not only results in wasted time but wasted development because you tried building multiple levels of a house of cards all at once. A few extra months of research and planning up front will save you years!

7. Get a couple of beta customers by the time you hit beta on the MVP.
You need to verify all the assumptions YOU made in the design and implementation with a real customer (that wasn’t one of the companies you came from), test the usability, and see how real Procurement departments work (that weren’t the one or two you had experience with). You might find you have a lot more work to do before release than you thought, but it’s better, and easier, to do this before you sell it to enterprise customers as a ready-to-use enterprise product than after!

In other words, it’s not just designing an MVP on a napkin, vibe coding your way to implementation, giving a flashy demo, and delivering on a major cloud platform. (Which is what a lot of startups are doing, and that’s why so many SUCK.) It’s deep thought from day one over months and months, if not a year or two (if you are trying to do something significantly complex). But then it’s a real solution that will be relevant for years (and years) if done right (and continuously improved, appropriately maintained, and always priced appropriately).

And yes, you can argue that more steps, or at least a deeper refinement of the above steps, are needed, but these are the absolutely critical steps and many of the ones that often skipped — which results in poor solutions and sometimes complete startup failure!

Why Do Most Vendor Solutions SUCK (For You) And Why Are Most Overpriced?

In our last post on the final top procurement concern of today (well, to be more exact, much of the last five and possibly the next three to five years), we told you Gen-AI, which is (still) the tech-du-jour, is in many ways no different than every other tech-du-jour we’ve had over the last two decades (Advanced Predictive Analytics, Fluffy Magic Cloud, SaaS, World Wide Web) in that, like all these technologies before, is being presented as a panacea that will solve all your woes while being nothing more than the latest instantiation of silicon snake oil, with the only exception being that its failure rate is higher and its much more dangerous (and even deadly) when wrongly applied.

Unless you’re in the top 10% of technologically proficient Procurement/Supply Chain departments, have, and have mastered, the last generation of tech, you shouldn’t even be looking at it. And even if you are, you should be identifying constrained use cases (where you have nothing else) where you can build, and train, your own custom models and install it with guardrails for the inevitable hallucinations (blackmail, and even murder threats).

So if it’s so bad, why are most (new) vendors building on it? A host of reasons, and none of them good.

GREED: they want to build something quick, sell quicker (on the hype), and exit within 3 to 7 years (through PE acquisition or public offering); they are NOT in it for the long haul and not a company you should be looking at

TQ: more specifically, lack of technical knowledge; they see the hype, they see the ability to rapidly build offerings, they see that the solution works okay in the very small set of hypothetical test cases they train and test it on, and see that if they focus on something specific, they can probably build something without a lot of effort or skill

HYPE: Open-AI, Meta, Microsoft, etc are spending so much hyping the tech, and without a lot of counter-hype (or studies showing the dismal success rates, with the first two significant studies from organizations with clout only appearing late 2025), they want to build on this hype and marketing to sell their solutions (often by integrating with or building on the flawed solutions from the big vendors)

CLUELESSNESS: As I have said before, many founders not only have limited technical competence, but limited market knowledge and even Procurement knowledge. They’ve only worked for two or three companies, which had outdated Source-to-Pay solutions (if any), and are only aware of a handful of solutions. I.E. they looked at the Gartner or Forrester Map (which, as we know, haven’t changed in a decade and only contain decades old suites), did a Google search, looked at the website of the first three results that came back, and decided that there was NOTHING at all that even partially solved the problem they identified at their two or three jobs and only they could build it … even though, as we have shown, there are dozens (to over a hundred) solution for every major function in Procurement and Source to Pay and if none solve the problem fully, quite a few likely come quite close! (Like orchestration.)

That’s why most (AI-first) start-ups today SUCK. There’s a right way to build a solution, and, as you can guess, it’s NONE OF THE ABOVE!

Joel is mostly right. Writing …

Writing is something you try to start and then …

“…you suddenly don’t know how to write”
But at least you’re one step ahead of today’s generation that can’t write at all!

“…that you’re [going to feel like] a fraud”
Whereas the influencers don’t care that they are, and that’s why they are more prolific than you.

“…that you actually maybe don’t know anything”
Which will be a great start if it happens! Great writers actually question what they know.

“…that you can’t possibly be this bad at writing”
But, at least for now, you can, because you haven’t actually written since College/University!

“…that your English teacher was right about you”
I hope not, because if you have this thought, you need to get professional help immediately! (As you
have some serious self esteem problems.)

“…that a caffeinated squirrel could produce better prose”
That will always be the case, but this shouldn’t worry you because they are all too busy with sabotage!

“…that you don’t know how sentences work”
It’s just the English language. The question you need to be asking, does anyone?
Nihongo wa kenmeida.
English is not. No structure! No hard and fast rules. Every time you finally comprehend one more thing about the language, even if it was your first language, you realize two more things just don’t make sense (and wonder what idiot decades, if not hundreds of years, ago decided the word, phrase, spelling, grammar, etc. should be part of it).
This is one of the primary reasons some people confuse Gen-AI output with intelligence as Gen-AI produces near perfect English from a spelling and grammatical viewpoint, even if the meaning is pure nonsense upon deeper inspection.

“…that autocorrect is silently judging you”
And this is why you write offline in an old-school text app (like TextEdit on the Mac if you’re out-of-the-box, or a customized Zed or BBEdit which can be configured to the level of help you want). Then you don’t have to worry about this phobia bothering you.

“…that the blinking cursor is mocking your very existence”
This is also a sign you might need professional help, so if this is what you think, please get it. (Your job is to mock the cursor!)

“…that you should have pursued interpretive dance after all”
Let me be blunt here. If you’re better at communicating without words, this is a good option!
Just remember that it doesn’t pay well unless you get into a top troupe, but still …

“…that cave paintings had better narrative structure”
Joel mixed up his tenses here. Compared to the majority of “content” on social media, cave paintings still HAVE better narrative structure! And are sometimes clearer than the weird constructs “modern” language makes us use.

“…that you’re one backspace away from goat farming”
I wish! That would be a great and noble pursuit! I’d go one step further and also provide a rental service and negate the need for gas guzzling or energy sucking lawn mowers! Plus, goat cheese is easier to digest than cow cheese and goats produce (less than) half (of) the CO2 of cows! It’s a win-win-win all around.

“…that your keyboard is conspiring against you”
Nahhh, it’s just wearing out fast because you are taking your frustrations with yourself out on it. Try not to, it’s not the keyboard.

“…that your draft is sentient and embarrassed by you”
Okay, now you’ve reached full delusional status — check yourself into that psyche ward immediately. Then, when you accept that you’re not, get back to it.

“…that the void is staring back at you while laughing”
Well, we all know this. Lovecraft told us it was so! And it is. But it stares back at us through everything we do, so just accept it. Nothing else you can do!

“…that maybe you were completely mad all this time”
Look, if you haven’t accepted you are completely mad by the point you start writing, why the heck are you trying to write? (We’ll get back to this one.)

“…that you should communicate with hand gestures now”
Well, learning ASL would be a fantastic option! Instead of just another language, it’s a whole new way to communicate. And would allow you to communicate more silently and focus more on your thoughts that will help you with your writing.

“…that maybe society peaked with smoke signals”
Any society that is able to function self-sufficiently and harmoniously with nature is a peak society, even if it uses smoke signals for communication. Many of these societies invented some form of writing, so it shouldn’t stop you.

“Writing is masochism but with better branding.”
No, it’s just pain. There’s no pleasure. And you have to be stark raving mad to want to do it. You do it for the greater good. Not just because it forces you to crystallize, cement, and confirm your thoughts (as some people can learn to do that through mediation), but because it helps you simplify them in a way you can convey to others (willing to read and think) so that they too can consume and conceive of the benefits!

“Realize 3 months later that the writing got a bit easier …”

Nope! Because there’s a 99%+ chance that you won’t make it that long! I chronicled the rise and fall of the blogs for over a decade (and while the resource site is now offline, I still have the database backup that contains hundreds of dead blogs and sites).

The rise (and fall, and rise again) of blogging, newsletters, and podcasting all follow(ed) the same pattern:

  • 90% didn’t survive beyond the 3rd entry/3rd day
  • a significant number essentially died by the 32 entry/3rd week
    (as frequency became sparse)
  • 90% of those that remained after the 3rd entry/day didn’t survive beyond the 33 entry / 3rd month

And since social media posting is just Web 3.0 Blogging … odds are 99 to 1 you’re not going to make it 3 months. Sad, but true.

If You Think You’re Ready for AI, You’re Not Ready for AI!

All of the Big Analyst Firms, Consultancies, and Vendors are telling you that you need AI, that it’s the only technology that’s going to allow you to get with the digital times, and that everyone else is using it, so you should too.

But the reality is that you probably don’t need AI, it’s not the only technology that can bring you up to date in the digital age, and while many people are using it, 94%/95% are FAILING.

The only hope you have to succeed is to be brutally honest, to ADMIT what you don’t know, that you’re only chasing AI because of FOMO and FUD, and that real progress has always been methodical and one step at a time.

More specifically, from where you are starting, not from where the market pretends you are.

The only organizations that have been successful at AI are those that:

  • honestly assess where they are today
  • determines their readiness for change
  • identifies the most time consuming processes they are willing to change
  • identifies the appropriate automation one process at a time, which is often just simple workflows/RPAs/built-in automations in existing platforms and other times ML/ARPA
  • monitors and tweaks them until they run smoothly and reliably
  • uses modern meta-workfows/ARPA/AI to connect the individual automations together where, and only where, it makes sense
  • only slaps guard-railed semantic tech / focussed SLMs on top to provide a natural language interface that processes inputs and outputs fixed action requests where appropriate

Successful companies don’t go all in an unproven tech, don’t try to do big bang projects (as that only results in big failures and sometimes the greatest supply chain disasters of all time), and definitely didn’t take the advice of the BIG X that promoted multi-year modernization mega-projects with no successes that they can point to.

In other words, the only companies that have succeeded with AI (the 5% to 6% depending on if you would rather go with McKinsey or MIT) are those that learned from the mega-ERP disasters of yesteryear and did a sequence of successive mini-projects that each built on the lass and slowly ramped to mega success.

In other words, they understand that you have to crawl before you can walk and walk before you can run. And if you can’t even crawl, you’re not ready to try and run at the Olympics, which is the level of tech maturity you have to be at to HOPE to succeed with AI.