I been doing occasional product due diligence this year for a few PE/VC firms, helping them vet potential investments in B2B/enterprise software companies. That gives me a better view into how investors size up prospects. One thing that I’ve noticed a few times – and therefore are looking at more carefully – is companies moving professional services/consulting work into the ARR column based on multi-year services agreements appended to SaaS licensing deals. Let’s break that down:

Investors typically value software product companies at 6x revenue or more. (With bigger multiples for faster license growth.) That’s because a software product company with a well-executed multi-tenant architecture and ruthlessly efficient onboarding can add new corporate customers (logos) with very little incremental effort or cost. Once the company passes break-even, each additional customer is nearly pure profit. [See All of the profits are in the nth copy.] Customers don’t care how hard we work, or how big our development is, but whether the application already does what they need. And they will renew (over and over again) as long as they’re happy.

Software services companies (aka consultancies aka outsourced development aka staff augmentation aka nearshoring aka custom application builders) are typically valued at 1x annual revenue. Ultimately, clients pay them for hours/days/weeks worked: for effort expended rather than value delivered. Clients are always evaluating whether their uniquely bespoke software needs can be built elsewhere (internally or externally) faster for less money. Services firms have to keep their technical staff busy to stay profitable.

So a hypothetical $30M software company with $20M in SaaS license fees and $10M in post-sale implementation consulting might be valued at $130M at its next funding round. This creates an incentive to ‘move’ services revenue into the licensing column. Reclassifying $2M of services as ARR would boost valuation by $10M.

What does that look like? We could attach an annual block of custom development work to our largest contracts, say 1000 hours/year for 3 years — where the customer gets to spec out integrations, product extensions, special projects. In the dictionary sense, this is ‘recurring’ since we invoice for it each year. So it would fit into a purely literal definition of ‘Annual Recurrent Revenue.’ But it doesn’t change the economics of delivering custom development services versus nearly frictionless reselling of existing software bits.

Here’s where we get into trouble:

Many (likely most) of our biggest clients’ special requests or custom work is of little use to the rest of our customer base. We tell ourselves endless ~~lies~~ stories about market leadership and early adopters and how “everyone will eventually need that,” but it’s mostly not true. I like to ask this retrospectively: “Of the 7 things that we built for HugeCorp last year, how many are being used in production by 3 or more other customers?”
This plays havoc with product planning and roadmaps. Inevitably, some of what MassiveCo wants will need changes deep in our application architecture. Or creation of new permissions. Or adding new APIs. Or white-labeling interfaces. Or retuning our query optimizer.
When we signed the contract, we imagined setting aside some generic development resources or field engineering time, but these requests need specific people on specific teams who are our experts in those specific technical areas. And we can’t reserve 20% of every architect or designer just in case Behemoth Inc might need them in Q3. Instead, we assign our best people to work on our most strategic problems… and are (inevitably) surprised when we pull them off innovation for one-off contractually obligated projects.
Big customers learn to view us as a services firm, not a software product company. They increasingly want their own version, codeline, dedicated development team. They expect us to jump on command (since they’ve prepaid for our attention). Their shopping lists have items quite far from our core application or competence.
Since custom development and staff augmentation are mostly about cost, we’re always in competition with pure services firms who are hungry for business or willing to charge less. The pressure is on deadlines, delivery dates, more accurate work estimates. Customer specs may be unclear, or incomplete, or non-sensical, or flat out fail to fix the problem they have. But there’s intense pressure to deliver exactly what the customer wants, on their schedule, even if we take quality shortcuts or subvert our core product or build what we know is worthless. “We have to hit these dates, or they may cancel the rest of our services work.” Success generates even more exotic projects; failure costs us service renewals.
Product strategy slowly erodes. As more of the development calendar is allocated to delivering what Colossal Ltd and Mammoth Inc want, the remainder goes toward ‘keeping the lights on’ and quality escalations and chasing the competition. Why put together a great strategy that we won’t execute? Disenchantment leads to learned helplessness leads to engineering/product staff turnover.

This seems part of a broader trend where terms of art lose their meaning. I haven’t met a team in years that isn’t ‘agile’ – regardless of how they build software. (“We do standups.”) And the excuse for every half-baked product is that it’s an MVP. (Even though it’s in full release, at full price, for all interested customers or use cases.) And everyone is doing ‘product-led growth’ this year. (Under the hood, it might just be SEO and content marketing.) Giving something a new name doesn’t change its underlying reality.

Sound Byte

ARR is one of the many ways that software product companies are starkly different from software services companies. Smart investors should be inspecting for diluted ARR alongside other due diligence work, and fund-raising companies should avoid doing it.