Category Archives: SaaS

Phil’s new HfS Services-as-Software FlyWheel Is Right On the Mark From a Customer-Centric Viewpoint

… but hides the full support required on the back-end!

This is important to point out for two reasons:

  • Gen-AI Hype-mongers will use this as another excuse to claim most white-collar functions will be entirely eliminated when, in fact, it strengthens the need for true back-office white-collar workers and real software engineers
  • Expert human support becomes more critical at each stage of the process (while bit pushers became less and less useful)

But let’s backup. In his most recent piece where he (re-)introduced the SaS Flywheel, Phil made one critical statement which is constantly overlooked by the industry: Stop treating FDE as optional: Your AI Flywheel will not spin without it.

As Phil astutely points out: the hard question nobody is answering is this: who actually wires AI into your live systems, governs it in production, and makes it keep working when the AI software vendors leave the room. The answer is, of course, your Forward Deployed Engineer (FDE) — and if your transformation strategy does not have it, you are building an AI theatre, not an AI operating model. (Which, FYI, is what most companies are building — and, as Stephen Klein astutely points out, putting on puppet shows. Great for entertainment, but not so great for getting anything done. Especially since they all overlook what AI can actually do.)

Now, a forward deployed engineer alone will not get you out of pilot purgatory, but it is an essential condition — just like you can’t climb out of a deep wide hole with smooth 90° vertical surfaces on all sides without a rope or a ladder, you can’t fly your way out of a pilot without a working plane, which you don’t have without an engineer to keep it running.

As Phil continues, FDE is not implementation – it is the engineering layer that makes AI governable this is because FDE teams build ontologies that reflect how the enterprise actually operates, wire models into real data with real permissions, and design the governance architecture that keeps autonomous systems accountable, which will, and for quite some time into the future, wire in non-overridable human oversight, approval, and review.

Phil goes on to list a few key things that LLMs cannot do on their own. (It’s in no way a complete list, but hopefully enough to get executives questioning all the AI-BS form the AI-Hype-mongers presenting grandiose claims that likely won’t be a reality within most of our professional life-times. Even better, Phil points out that Agentic AI without FDE governance is not transformation. It is risk accumulation!, and points out five key requirements of workable AI that can’t be achieved without an FDE. (There are more, but again, these should be enough key points to help executives realize that not only are LLMs sorely insufficient for almost every task they are being promoted for, but they aren’t even usable at all without the help of a FDE team.)

Phil also does us a great service by pointing out that while vibe coding creates velocity, FDE prevents it from becoming chaos — which is what happens every single time you employe vibe coding without FDEs (and a real engineering team — but we’ll get to that).

Vibe coding is simultaneously one of the biggest boons to software development and the greatest destructors, especially since it is almost universally misunderstood and misapplied. For example, while Phil’s statement that business analysts can express intent and receive working agent code in return is technically correct, it’s not practically correct. That’s because vibe coding produces code that is insecure, inefficient, and not appropriate for enterprise software. In fact, just about every startup that tried to launch an enterprise app on vibe-coding alone have lost hundreds of thousands (or more) attempting to do so — see this great post from Alex Turnbull.

Vibe Coding is super useful because, with the help of an FDE team with a good business analyst, the end user organization can quickly create functional prototypes that demonstrate precisely what they are looking for, which are much more powerful functional specifications than traditional functional specification documents with text descriptions of required functionality and powerpoint mockups. Plus, these prototype specifications can be created in a fraction of the time. But that’s all they are, prototypes. Real applications still need to be built by real software engineering teams who can build optimized, bug-free, secure code — vs. unoptimized, buggy (especially at the boundaries), and insecure code regularly generated by AI-based vibe coding tools (where, depending on what source you access, 53% to 78% of code generated has serious security issues).

In other words, it’s a great article, from a customer-centric viewpoint and written for customer executives. From a back-end, provider perspective, it’s missing one key step — the development step that takes vibe coding prototypes and produces real (AI-backed) enterprise applications.

Moreover, it centralizes the FDE activities when, in reality, they are ongoing throughout the entire cycle.

  1. they activate, and put the foundation in place
  2. they train the users on how to properly use the LLMs for accelerated research and are always on call for help
  3. they maintain the orchestration layer, and improve (and correct) it as necessary
  4. they work with the end users to vibe code prototypes
  5. they work with the development team to build the next generation (or iteration) of the enterprise apps in the SaS model

In other words, AI can enhance SaS, but it cannot replace the need for skilled humans on the provider side (for development, implementation, maintenance, and improvement) or the buyer side (for process definition, improvement, decision criteria, etc.).

At the end of the day, AI can only replace bit-pushers who do tactical data processing tasks which should have been automated by machines 30 years ago (when it was promised), but it can’t replace anyone who needs to make a (strategic) decision. This is true regardless of the model, and the right model, like Phil’s SaS flywheel, actually exemplify the need for the right, skilled, talent.

If A SaaS Provider Offers You a 95% Discount …

Slam the door, lock it; close the shutters, bolt them; don’t answer the phones, and rip the cables out of the wall; turn on the frequency jamming, and throw the cell phones in the Faraday cage; close the gates to the parking lot, and man security 24 hours.

No matter what they tell you, a 95% discount from a vendor always means a combination of EXACTLY two things.

  1. the provider was trying to rip you off (because they thought they could due to their customer portfolio, surging popularity, or your lack of market SaaS pricing intelligence) and
  2. the provider is in financial difficulty

That’s it. The only unknown is the weighting between those two realities (and just how severe the financial difficulty is).

They’re NOT giving you a huge discount because they want your logo or case study.
They might want your logo and case study, but a solid provider with a solid solution who creates a good relationship can certainly get it without 95% discounts — most customers who get real ROI from a solution offered at a fair market price are happy to give you a case study for the free publicity.

They’re NOT giving you a huge discount to prove value in exchange for future purchases.
Everyone knows there’s no guarantee those will happen, even if you get the full promised value of the solution. You might have no use for their other solutions. You might never need any additional seats.

And any other reason they can come up with is also a lie.

Unless the company is run by a bunch of cons where their entire business ethos is charge as much as you can for as long as you can until the market realizes how much they are being ripped off (and then the cons skip town), the only reason a company will offer that level of discount is because they are desperate to get a sale on the books because, if they don’t, someone is losing their job in the best case or the company is going bankrupt in the worst case. Either way, that’s not a vendor you want to be putting your faith in. You want honest companies who price based on actual costs with a fair markup and who are financially stable — not dishonest companies who price based on how much they think they can scam you while being on the verge of bankruptcy.

And never kid yourself that it’s worth the risk because all the company needs is a few deals and a right-size on its pricing because a company losing money can’t stay in business — and any piece of enterprise software fairly priced at 1M will cost the company offering it at least half of that sale price to adequately support. You need to keep two things in mind

  1. cloud compute costs are real and significant and, thanks to Gen-AI that is over-straining global compute infrastructure, rising year-over-year
  2. the development talent needed to maintain and secure your solution (and despite claims, Gen-AI can’t do either, especially since it typically makes your solution less secure) is not cheap either

So if you intend to have 10,000 users hitting the app daily and doing at least one compute-intensive task (and LLM queries are compute-intensive, at least 20X as compute intensive as a classic Google or Lucene search, and possibly 200X depending on what’s being asked), your provider’s cloud costs will be in the six figures — which means the 95% discount isn’t even covering their hosting costs and they are digging themselves into a deeper grave just by signing you!

Your SaaS Vendor Should be TRUSTworthy … But They Shouldn’t Have to Tell You!

In fact, I’d argue it’s a red flag if they do. But let’s backup.

A trustworthy vendor is one that

1) Clients Trust

2) Clients’ Third Parties Trust

3) Suppliers and Partners Trust

4) Third Party Analysts and Consultancies Trust

… and all of these will imply trust in their recommendations and reviews, even if they don’t explicitly say it.

Digging in.

1) They treat you like a client from the first interaction.

The first interaction asks about your needs, not just what you are looking for.

They tailor the demo to your business and categories.

They answer your questions openly and honestly, don’t deflect from features they don’t have today, give you real timelines, and offer workarounds until they deliver.

Once you sign, they guide you through implementation and change management, work beside you to train you, and always respond beyond SLA requirements.

They don’t just focus on immediate results, but on ensuring you level up and could continue to get results without them. They act like a partner.

2) They treat your suppliers and partners like clients too.

They’re always there to help, they make it easier for the supplier than their competitors, and prove their value to the point the suppliers want to use them too.

3) They’re fair to their suppliers and partners. They pay on time. They work with them. They take blame when it’s their fault and not the supplier’s or partner’s … who like working with them more than other companies.

4) Analysts and consultancies happily recommend them even when they’re not (paying to be) on the Map or a preferred partner. Sometimes when they aren’t even the most appropriate solution just because their customers are so much happier.

It becomes so obvious that you don’t even have to ask the question (and you know that if you did, almost every client, supplier, and partner would say they trusted them).

Remember this because
1) if you start seeing too many posts on how a certain company is one you can trust or
2) you have to ask if you can trust the company
you probably can’t!

Companies generally start pushing “trust” when a major competitor does something particularly untrustworthy that becomes public, third party surveys paint them as trustworthy, or they need a new angle to boost sales.

Plus, f you need to ask, something is setting off your internal alarms and you won’t trust them until you figure out what that is (and they’re not going to tell you).

Either way, play it safe and look elsewhere.

You may still get burned (and I have the scars to prove it), because sh!t happens, boards make changes, investors get ruthless, and world class pathological liars could still slip through the cracks and fool everyone for years, but you decrease your chances of being burned significantly by just looking for vendors who continually do the right thing (instead of just saying they do).

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!

Despite what they say, Size Matters! Part II

In Part I, we noted that size really does matter … when you are selecting a ProcureTech or Source to Pay solution, and, in particular, it’s the size of YOUR spend that matters (and not the size of the vendor or even the vendor offering).

We noted that there is no one-size fits all, that the three main tiers of organizations (small, mid-sized, large) have three different needs (which are nuanced, especially in the mid-market as going from small-mid to big-mid can require leaps in complexity), and that you should be paying based upon the tier you need.

But with 3 tiers of solutions out there, the reality is that if you select a bigger solution than you need, you’re going to pay a lot more for a much smaller return. And that’s just NOT good Procurement.

So what should you pay?

It’s all based on your size, maturity, and need. Well, we answered this a bit in the past when we did our series on how much should you outlay for source to pay. (Part 1, Part 2, and Part 3.)

In the series we did in 2023, our answer was 120K to 500K+ (a year), and we were mainly focussed on the mid-mid-market upward. The answer today is similar.

Small Enterprise, < 20M in external spend, 12K to 24K a year. All you need is basic e-Procurement and basic process support. Many shareware suites and low coding platforms will allow you to configure a lot of what you need. At 20M, your full savings potential is 2M or less, and you’re likely to only realize a quarter of that in the first year, or 500K. So spending more than 24K on a license (when you’ll also have implementation and support costs) does not guarantee a worthwhile return.

Medium Enterprise < 500 M in external spend, 60K to 240K a year. You need basic sourcing execution and e-Procurement. A baseline solution does enough at the lower end, and an enhanced solution with deep supplier management, deep P2P+, and some compliance and risk capabilities. Here, the potential savings could be as high as 50M at the high end, or as low as 3M on the low end, with a potential opportunity ranging from 1M to 10M in the first year. At the low end, especially considering the personnel costs, you probably don’t want to pay more than 100K to guarantee a return. At the higher end, you could pay a Million for a small suite and get a return, but considering there’d only be a couple of categories where it would deliver any incremental value, why pay a Million when there are solutions for 250K that deliver the same value for 90%+ of activity. (For the few categories where it’s worth it, just hire a consultant with access to specialized tools!)

Large Enterprise >= 500M in external spend, 480K to 1M+, depending on the particular deep capabilities you need and any specialized modules and support you need. There’ll be more than enough categories to justify the additional spend, and saving an extra 2% on a 50M category will pay for the increased platform cost!

That’s the rule of thumb. Higher or lower depends upon the expected return. This means that before you spend more, you should work out a realistic ROI. If the return isn’t realistically there, you don’t spend more than you need.

Now I know plenty of vendors will disagree with me, but when solutions exist at all tiers that do everything an appropriately sized buying organization will need at the price points above, why pay more? (Even though the ABC suites will tell you that you should!)

Also, please note, these are license costs with basic support only. If you want or need more support or services, expect to pay more. (And do the ROI on the services before you contract them.)