Category Archives: Technology

Building a Good Solution ABSOLUTELY Requires a Good RoadMap

A few weeks ago we tackled the subject of How Does a Vendor Build a GOOD Solution? and outlined seven key steps. SI received some feedback, and most of it revolved around the roadmap and how it should only look three months out!

So we have to address this insanity!

First of all, name ONE great or revolutionary technological invention that was invented with three months effort. You can’t, because there isn’t one.

Now name ONE great piece of software that solves a significant business problem that no other system that came before solved that was invented with three months effort. You can’t, because there isn’t one.

Now name ONE Billion dollar enterprise software platform that went to market with an MVP in 3 months that became a powerhouse that a large swath of businesses are using. You can’t, because there isn’t one.

All you can do in three months is a crap an app that is a piece of crap. Now, you might be able to make a big splash on the app store or in the consumer shareware market, but enterprise software is a complex piece of enterprise technology that requires years of development … and years of planning!

Secondly, remember what a roadmap actually is. It’s a graphical document that shows all of the roads you have available to you, how fast you can travel down them, and where they will take you. It’s not a detailed travel plan!

Similarly, in technology, a roadmap lists out all the things you would like to do, what it might take to get there, and what options could take you there. It is NOT a detailed functional specification or a development plan for the next three to five years (which should be the length of time you should be thinking through). (Also remember that, historically, great inventions came from research labs where the researchers were thinking three, five, and even ten years out and had years to develop groundbreaking developments!)

There are a number of reasons you need to be thinking three years out (even if your plans completely change nine months in), but the most critical reason is this:

If you plan for three months, or go for speed over quality (assuming you can always fix it later) your teams take shortcuts, build crap infrastructure, and add technical debt faster than you can ever eliminate it! (It’s almost as bad as vibe coding your way to an MVP, and then realizing you can never support an enterprise stack on it and have to go back and rebuild it from the bottom up after you’ve wasted months of effort and tens of thousands (or more) on AI credits. (Alex Turnbull gives a good summary in this LinkedIn post.)

When you start thinking about where your enterprise application might need to go, even if you choose not to go in that direction, you understand what processes you will eventually need to support and how you will need to build the foundational data model, workflow and orchestration engine, integration capabilities, internationalization support, and other core foundational features to either build that out or integrate that capability in the future. You’ll have a better idea of what you’ll need in the stack, what you’ll need for the platform, and what the best development environments for your team will be. (Having to change out any of these is very time consuming and expensive should you make a mistake early on.)

For (an easily understood) example, if you think invoice processing sucks (because you only looked at three vendors as you are too clueless to do market research, like many vendors that started during COVID because they all of a sudden realized that the business back-office should be capable of running 100% online, distributed, and remote), what else are you likely going to do after that. (Unless you’re a world leader in invoice processing technology, no one is going to buy just that!) In other words, are you going to support invoice analysis and predictive payment analytics, payment platform integration, contract and PO data extraction and matching, enhanced procurement (platform) support, etc. All of these capabilities will dictate data model, orchestration, and stack requirements.

Again, the point is not to plan out a detailed release schedule, but understand where your customers might ask you to go, where you want to go, where you want to hire a guide (to provide you with the expertise you need), and where you might want to hire a service to take your customers there (because a certain capability is best done by a specialist). This, along with constant monitoring of customer functionality uptake, customer feedback, and user forums will give you the complete picture you need to create the high level development plan for the year and the detailed functional specification for the final release of the next quarter (which might be built incrementally using agile methodology).

To put this in terms non-technical people will understand, you can’t build a twenty-story high-rise on a foundation for a two-story house. By thinking ahead, you’re building a solid foundation, and when you start building, you’re building the frame for the twenty-story high-rise that you can then build out and complete floor-by-floor once you know what the tenants you are signing on want on their floor.

By thinking at a high level years into the future, you are visualizing how you are going to fit into and evolve with the organizational ecosystem you want to sell into, and you are making good architectural decisions as you will be able to build that understanding of what you’ll need to support!

Moreover, as one commenter pointed out, and we noted above, watching how users work with the system is key! That not only helps you understand the depth and configurability of workflow process management required, the breadth of the data models that will be needed, and what systems they will want interfaces to (based on what they use before and after), but how to design a good UX based on now they work and what they are adopting! (It should be noted that designing a good UX, including a good UI, can be harder than the model and controller algorithms — which, if you need advanced analytics, optimization, and higher performance, might take a PhD to get right — because it doesn’t matter how good the application core is if no one uses it!)

Roadmaps are key. That’s how your Chief Software Architect and Chief Technology Officer build great applications. It ensures that once you select a destination, they know the route they have to navigate to get there!

AI vs No AI – Let’s Make This Clear!

There are valid uses for AI, and valid AI models you should use. (LLMs are rarely one of them, having only a handful of reliable applications, but, when you push them aside, there are lots of other AI technologies that actually work if you don’t get blinded by the hype.) But there are invalid cases, and AI models you shouldn’t use. So to make it easy-peasy for you, here’s a simple guide!

USE AI WHEN DON’T USE AI
It’s a well constrained use-case where AI has been successfully deployed in industry, where the confidence is proven, and where you have access to the right technology. It’s a poorly defined use case, AI has not yet been successful for the use case, the confidence is unproven, and/or the tech you have access to is still in alpha!
It works as well as previous gen tech but with significantly shorter training cycles and easier integration and utilization. Previous gen tech still works better, costs less, and/or has no impediments to integration or UX.
It can bring value beyond what last generation tech can bring. All of the value can be achieved using traditional rules-based (A)RPA, (decision) optimization, analytics, or (classical) machine learning.
It’s a cost effective solution that can be run predictably based on a predictable cost model. It’s based (primarily) on LLM(-based) models that have unpredictable compute costs and, with the wrong request, can eat up thousands of dollars on a single request.
You have a valid use case for agentic tech! You think you have a valid usre case for agentic tech. (If you think you’re ready for AI, you’re NOT ready for AI.)
You’ve mastered current generation tech. You’re still a generation (or three) behind on tech.
You have in-house expertise on what AI is, and isn’t; where it can, and can’t be successfully deployed; and what “AI” is typically appropriate in a given situation. You’re relying entirely on (junior) consultants from the Big X promising it’s gonna “change your life“.
It’s designed to augment human performance and make your employees more productive and more effective super humans (able to do the work of 3, 5, 7, and even 10 regular humans). It’s designed to replace humans. (This doesn’t mean it can’t reduce the number required to do a task, just that at least one is still maintained to handle exceptions and make decisions.)
The firm is selling augmented intelligence! The firm is selling AI Employees. (There are none! And any firm that makes this claim is dehumanizing your employees! But hey, it’s your choice if you want to lose all your money.)

Get it yet?

C-Suite Only Has Budget for AI? Then Lie its AI and Buy Solutions That Work!

You need modern tech more than ever, but with unemployment on the rise (and people buying less), recessionary fears, tariff wars, etc., the C-Suite doesn’t want to give you the increased budget you need to buy the tech you desperately need to be more productive.

On the flip-side, they are finding millions of dollars for “AI” (in the hopes the lies are true and they can replace you, even though any attempts to do so will result in massive negative repercussions) despite the fact you’re not ready for AI and most AI-first vendor solutions SUCK, and trying to bring in in big consultancies (who will propose multi-year big-bang projects that, like all big bang projects that came before, will result in big busts and possibly create some of the biggest supply chain disasters of all time). You know the tech doesn’t work. You saw the 6% success rate from the recent McKinsey study and the 5% from the recent MIT study (both in late 2025). That’s a 94% failure rate, which is even worse than the general tech failure rate of 88% (as per a Bain 2024 study)!

You know you need modern tech, and you know, for the vast majority of those needs, AI ain’t it. Especially since you know that there is no such thing as Artificial Intelligence. (Artificial Idiocy for sure — it’s called Gen-AI — but not Artificial Intelligence. The best you can get is Augmented Intelligence, but that’s always narrowly focussed and quite rare due to too much research, and promotion, of Gen-AI LLMs that will never work [as the models are foundationaly flawed and there is no more data to train them on].)

So what you do?

Frankly, you lie and say its AI!

The fact of the matter is, if the C-Suite is insisting on AI, it’s because they don’t actually know what AI is. (This should be abundantly clear by the fact we have a lot of vendors, and consultancies, claiming AI Employees, and we all know that’s pure bullcr@p!) And the reason they are insisting on it is because everyone else is lying to their face. The Big (and small) “AI” Tech Vendors. (Big) Analyst firms. Big Consultancies. The Media publishing the fake claims and fake stories (and presenting what are bullcr@p-filled advertorials as vetted and verified case studies). Influencers spreading the hype for their own profit.

And since this C-Suite has a lower TQ (Technological Quotient) than an average elementary school child (who can probably use your phone and tablet better than you can), it’s not like they have any real clue what AI is.

And if the C-Suite wants “proof” that the vendor you select has AI, ask the C-Suite what that means to them. Nine times out of ten it is a chatbot interface. If the vendor you select hasn’t done so already, just have them hook in Chat-GPT through an API, let the execs play for 5 minutes, get the C-Suite approval, and then have the vendor disable the interface before delivery (in platforms where it truly is useless, or limit the chatbot interface to help queries where there is very little downside to it screwing up).

When Chat-GPT first became the rage in Procurement, C-Suites insisted on “AI Guided Buying” even though, with a well designed federated catalog (that support standard service forms) — that supported contracts, preferred vendors, (learned) business rules, and budgets — it was five to ten times faster to use the integrated search bar and filters (as per our twelfth entry of our 2025 Myth-busting series where we illustrated just how dumb the Gormless AI could be). After losing out on a few deals due to this lack of functionality (even though they were the buyer’s choice), a fed-up vendor built a chat-bot led guided buying offering on standard LLM libraries. They can turn it on, demo it for the pointy-haired bosses, and turn it off again.

This is critical when the real value of

  • analytics is exploration
  • sourcing is optimization (not error-prone calculations by an LLM that might erroneously multiply a number by -1 because it’s interpretation of the request is to satisfy an arbitrary savings number anyway it can)
  • supplier management is potential issue detection and human review and remediation
  • procurement is honouring contracts, using vetted suppliers, and following rules designed to prevent risk
  • etc.

So take advantage of the fact that they don’t have a clue what (real) AI is and tell them whatever tech you need to solve your problem, regardless of how much AI it does, or doesn’t, have is the latest and greatest AI if that’s what it takes to get the tech you need to solve your problem.

I know you don’t want to lie, but the reality is that is now what you have to do to keep your job, because if you don’t get the tech you need, you’ll fail and be made redundant. And since everyone else is lying too, chances are someone is already saying the tech is AI and you can just point to them (and blame them for the lie).

End of the day, it’s whatever makes you the most productive. That might be a new AI solution, might be a classic ML or NN solution, or it might be two-decades old rule-based automation where you can encode a few rules and have the solution do 95% of your work on auto-pilot without any worry of it ever screwing up (and costing someone their job).

Remember, you’re hired to get things done, not listen to bullsh!t that comes straight from the A.S.S.H.O.L.E.. Don’t get blinded by the hype!

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!