Anatomy of Software Frauds

This is an article about ethics in the tech industry.

Others in this series include, but are not limited to:

Estimated reading time is 40-50 minutes.

epub version for travel or easier reading in multiple sittings.

Here we go.

Forbes recently outlined The Ugly Unethical Underside of Silicon Valley describing the rise of objectively fraudulent tech companies. Numerous marketing-over-substance bubbles have shattered in the past few years, and there are more companies collapsing soon.

Tech frauds are built on top of three layers:

You can protect yourself from tech frauds easily. Even though it can be difficult discerning numerous bad-faith behaviors from the endless “blameless mistakes” of software development, objectively recording how your vendors lie can quickly reveal patterns of fraud in plain sight.

Build Software with Unlimited Scapegoats

Say you want to make money without the responsibility of creating working products. A good way to start is by founding a software company. Software frauds give you deniability. Software is generally considered so complex it’s basically treated as an “unknowable” quantity. You can’t be blamed for your failures because everything is just so gosh darn hard.

So, you’ve decided you can make money from software and your products don’t even have to work—great job so far! How do you end up trading your imaginary products for customer cash?

Simplest way: sell into companies where executives have big egos and big budgets . Never sell to technical users, they’ll see through your lies .

Avoid letting technical users get involved in sales processes too early because they may see through your product fraud before you can ingratiate yourself to those with purchase authority .

After you convince a big company CTO they will be a literal savior of their organization by believing your product vision, you’ve tied their personal self-image to the outcome of using your product. In industry parlance, big company CTO will become your INTERNAL CHAMPION making it more difficult for them to even consider you sold them a seven figure fraud. They won’t want to entertain the fact they purchased non-working products based on schmoozing, slide shows, and ego games. They’ll never admit they got grifted.

If customers begin discovering your fraud, if they start asking why they paid seven figures for a system with daily failures and outages and data loss, just point out one or more of your built-in professional scapegoats:

“software is hard” Even though your company claims to be the best at software and the best at development and the best at testing, you can always repeat sleaze of well, it is software after all, so you should expect routine failures.

“we have a lot of components” Also see: Insuring Yourself Against Responsibly by Blaming Overly Complex Dependencies

“the system isn’t widely tested yet” Also see: Using Paying Customers As Involuntary Outsourced QA



It’s all okay though. You’re selling into corporate silos, so your customers will hopefully never talk to each other. Customer A, with 30 days of downtime, thinks they are just unlucky. Just try to make sure they never talk to Customer B, who also had 30 days of downtime. Multiple customers with multiple outages establishes a pattern of incompetence, not the story of blameless unforeseeable mistakes you keep pushing as explanations for errors .

Remember: you’re selling something you know doesn’t work and will never work .

You are selling a unified vision of productivity perfection so fragmented, if customers tried, they could prove your ideas are physically not possible. But, nobody wants to see the lies at first. Nobody wants to believe they are intentionally being defrauded, so you’re pretty safe for a few years.

If customers begin to suspect you’re lying and fraudulent, just apply some CEO-on-CEO action. Talk them down from canceling contracts early and wave away any concerns about suing you for fraud. Throw in some platitudes or even a 6 month free contract extension.

Why do Software Fraud

Why engage in direct fraud when there are real problems with real solutions you could be creating?

Creating working products is hard, let’s go sell the work of hack frauds.

You find yourself constrained by:

You have leadership authority, but aren’t overtly technically competent.

Your company’s guiding focus is a single product idea, but your single product is provably broken.

Your product is 5-10 years old and can’t be fixed, repaired, or made reliable in any sense.

You must keep your company treading water until a greater fool bails you out for billions.

We’ve seen this pattern a few times at different stages

MongoDB has been pretty fraudulent since the beginning. MongoDB’s model was lying about technical product features to non-technical users. “You need database? Use database! Don’t worry about our criminal negligence or inability to do anything we promise. You can always buy consulting and support to make up for broken features, sorry (not sorry) for the data loss though.”

An easy way to detect software fraud is loudness-vs-substance: when marketing always has priority over product, delusions get priority over creating better products.

Anatomy of a Software Fraud

Running a fraudulent software company is easy on one hand: hire 22 year olds and tell them to build complex systems without talking to each other. There. Now you have a giant mess of software that’ll never work, can’t be fixed, yet you’ll still have 30 independent non-integrating software packages you can put on bundled price sheets and sell to customers as “solutions.”

If you worry customers may discover your lack of expertise (or your custom made-up terminology and non-standard tech stacks) as attempts at platform lock-in, just spend a year in legal fees spinning up an independent “open source foundation” to house all your code scraps. See? There’s no lock in here because it’s all owned by a Foundation™.

Tell your customers it’s a benefit your software is “open core” with the rest being a hybrid of proprietary add-ons and hosted services.

Investors love businesses exploiting “open core” models because they give an illusion of customer freedom (and an illusion of no proprietary lock-in) while practically approximating market mechanics of addictive drugs. Sure, here’s a free sample, build your company around it. Oh, you need something fixed? You need security updates? We don’t support the “open core” of our software, but we’ll be happy to sell you our full product on a yearly recurring license. Please, step into this webinar…

Customers wanting to convert from your paid version back to the free “open core” version because you claim theres no lock-in get a rude awakening. Your customers can certainly only use the “open core” instead. After all, you don’t have any lock-in. Nope, no lock-in at all. Except, your customers will lose: security updates, user interfaces, quarterly feature updates (sorry, the “open core” version only updates features every 2 years), and access to support if anything breaks. Good luck running the “open core” version of our proprietary platform, most valued customer!

In the case of MongoDB, they simulate the appearance of open by using what is lovingly known as “the coward’s license.” Sure, you can look at the source, but anything interacting with the source in public or private, regardless of whether you distribute it or not, must also be released to the public. Business with a properly functioning legal team won’t touch AGPL code at all under punishment of having all internal trade secrets released to the public under terms of an unwanted toxic license.

It’s all okay though. Nothing else matters as long as VCs remain enamored with your marketing, vanity metrics , and illegitimate market behavior.

Let’s break down a few more details of giant software frauds.

Minimum Requirements

Every software has minimum requirements. But, you can’t make money shipping one piece of software—you need to ship an interconnected spaghetti architecture platform.

Instead of having one set of requirements (say, 4 cores, 4 GB RAM) for one piece of software, you are a platform. You require 20 underlying bloated services, each needing 3 VMs and 32 GB RAM per VM. You are Enterprise Scale. Who cares about wasting 2 TB RAM to run an idle platform? Spending money is a sign of progress .

Hidden Money Costs

Using a real world example, running an idle Enterprise-Ready Pivotal Cloud Foundry platform requires burning upwards of $50,000 to $200,000 per year in pay-per-instance hosting costs for an idle system with no user applications even running on it. Your platform is important because it wastes so many resources.

Those dollar figures are on top of the cost of actual system licenses, contracts, and consulting arrangements required to access the software. An idle Cloud Foundry requires over 20 VMs holding on to over 40 IP addresses just to deploy the empty management interface of your new “cloud .”

That’s not all though: if you want to run applications, you’ll need more licenses. Please call sales and schedule a webinar. They’ll quote you yearly recurring price for “AIs” (“Application Instances”) (or “Tiles” or “Cells” or “BBS” or “Cell Rep” or “Service Brokers” or “Floating Stem Cells” or two dozen other made up terms nobody understands). You’ll have the immense privilege of paying additional fees to run your own applications on top of something you already purchased yet can’t even get running.

It’s aways easier to sell aspiration of growth over baseline reality. You’re going to need the Super Deluxe Gym Membership for $399/month, right? Not a more realistic 3 hour a week membership for $4.99 instead.

As a sales person, always push customers into believing you are their sole path towards revolutionizing digital transformation into an agile multi-cloud native future-proof company.

As luck would have it, your platform is built on top of recurring subscription per-instance licenses, and, also as luck would have it, your platform believes “microservices” are the future, which conveniently bloats the number of instances (read: licenses) required to perform even the most trivial of tasks. Such synergy! Your vision for the future of computing is extremely monetizable by your preferred business model. What were the chances?

Clearly each service your customer wants to create will need 100 individual “microservices” underneath, and each microservice will need its own instance license. Your only task now is convincing customers their entire company will run on top of your platform. Convince customers they’ll be iterating so rapidly they’ll deploy 2,000 business-value services (each with 100 microservice dependencies) before the end of next quarter thanks to their new, billed per-usage and recurringly licensed, Silicon Valley state of mind.

Just hearing an idle system can cost $200,000 per year in hosting before considering the six seven or eight figure licensing fees you’re already paying should make your head asplode. Any reasonably intelligent customer would kick sales people out of the conference room and blacklist said company forever. If the efficiency of an idle system is so bad, there’s no way to, even with the most generous image you could conjure, think the system deployed to production-level traffic would be efficient, reliable, or stable in any real world sense . The product is an evolutionary dead-end .

As someone building a software fraud, your only remaining approach is to double down on your own confusopoly. If customers can’t understand what they’re buying, they just have to trust you. Trust is how money gets made. Trust is how you get to take advantage of customers and investors.

You can see pricing examples yourself using their PCF Sizing Tool. Enabling high availability is optional (what?!), but if you do want redundancy you’ll have to run three or more copies of everything, so just go ahead and triple all the instance numbers and their associated per-hour rates.

As a bonus, enabling high availability in poorly thought-through systems decreases overall reliability. You are adding redundancy, but each component has different untested failure scenarios in its failover/redundancy/HA system . Cloud Foundry is made from 16+ underlying services, and each component has its own independent HA mechanism .

We can actually prove menagerie architectures built around mindsets of “just add another dependency” are unfit for any purpose.

Every component has unique:

failover modes

failover initiation times

failover recovery times

distribution models

state maintenance models

persistence requirements

reliability guarantees

Each interconnected component having unique requirements means customers must retain experts in each dependency of their production platform . Dependencies aren’t independent of each other, so adding them all together decreases reliability due to their interconnectedness and propensity to catastrophically co-fail during any innocuous network blip.

Running so many different failover models as dependencies of your system makes the system provably unreliable and mentally incomprehensible. It is impossible to reason about the current state of the system (much less any of its future states), so when a problem happens, you just have to reboot everything .

Enjoy your downtime. It’s a one time error. Won’t happen again (until tomorrow).

Congratulations: you have created a system to sell you provably can’t understand, but this also means your customers can’t understand it. Your customers will assume you’ve got it all under control, when in reality you are just as lost as your end users. Don’t worry though, you can ride this confusion for a few years and continue raking in big contracts until customers figure out your fraud. Somebody will acquire you before it all collapses, right? You’ve got rich friends in high places. Though, you can forget any IPO—you’d have to expose too many of your unsustainable financials to make a go of public markets.

Hidden Time Costs

When creating a software fraud, you want to offload a lot of hidden costs onto the customer, but don’t let them realize it until later.

With MongoDB, a random company’s summer intern may deploy a new internal app, install random packages, and end up using MongoDB in an in-company production capacity out of inexperience. Intern leaves, but service remains. The service is unreliable because MongoDB is an illusion, the company lost the intern who babysat the service as it was created, so now you get to hire MongoDB consulting/support to maintain an internal app nobody has time to rewrite. The system works!

With the Cloud Foundry platform, the entire system is sold as one turn-key “it just works!” platform , but you’ve got to spend six months training your staff how to use the thing. Plus, since nobody in the real world actually uses the thing, you’ll never be able to hire people with real world experience. If, defying the logic of experiencing daily errors and infinitely recurring downtime, you continue using the broken system, you’ll have to send every employee through six months of trail-and-error training before they are caught up with how to not break your magically unlimitedly scalable platform that can’t handle more than four requests per second.

Then, at the end of your employee’s six months of training (which were kindly added on top of your original contract at a pair-programming double-the-money hourly rate), your employees discover nothing works — the system (and the sales people and the entire organization you bought it from) claims it will do X, Y, Z, but when you engage those features, the system buckles. Nothing works. Nothing was ever going to work, but your company just burnt 6 to 18 months of employee time on a platform dead-end .

Just hope companies aren’t smart enough to dump broken products when they prove to be broken. Companies are bad at admitting they got duped into buying software and services from vendors with absurdly high amounts of self-interest. It would be a personal hit to the ego of the CTO who thought they were the one true savior of digital transformation if they had to admit they picked a shady vendor.

Companies would rather ignore negative ROI from burning a couple million dollars on licenses, training, employee time, and all the server costs it took to discover the existence of a sales-driven software platform fraud than admit they have poor executive decision making ability.

Components

To continue your software fraud, you want to build a platform as incomprehensible as possible. Make it difficult for your company to be held liable for failures because the failures are always “just a one time problem” in some dependency. You’re going to need lots of components, including many operating at direct cross-purposes.

Using Cloud Foundry as an example, look at all the components and their required instance count (each in its own VM ) required to even start: Cloud Foundry “High” Availability.

Duplicate Components

You may also ask, why are both consul and etcd requirements? Well, in true “how to build software to never work properly” fashion, you don’t want internal teams to coordinate. Make them work in teams of two, force teams to learn and re-discover everything from scratch, then never let them work on the same task for more than a day or two.

So, Team A decided to use consul for a feature and Team B decided to use etcd for a feature, and now you have two consensus systems (each with 3+ independent VMs and failure scenarios) you need to babysit to keep your system reliable.

Requiring similar, but not the same, dependencies is a great strategy for building out your software-fraud-as-a-service company. Each new dependency increases customer confusion and increases the number of things you can blame for one-off failures to mask your intrinsically broken architecture.

Sad Components

In addition to duplicate components, you also want to re-use existing software in ways it was never meant to be used.

You want to monitor services? Use monit ! Except, monit has its own failure conditions and isn’t a hands-off drop in replacement for process supervision hierarchies. That’s okay though—when monit loses touch with a process, we can just reboot the entire platform again. After all, nobody runs any of this in production and, as a customer, you’re just paying for the privilege of being a free distributed QA team for other customers with similar issues.

Just Add Layers of Abstraction (JALA)

The coup de grâce of building fraudulent software is requiring everything to provide an interface according to your own misfit abstractions. Now you get to blame failures not on your platform, not on the software running on your platform, but on the mismatched abstraction between client software and the host platform.

In Cloud Foundry land, the magic error inducing, yet blame-free, abstraction comes from Tiles.

Why “Tiles?” No popular software would rewrite itself to be “Cloud Foundry Compliant,” so Tiles are the bridge between Software and The Platform. Tiles inform how to setup instances of software (including multiple instances if software is HA), automate backups, monitor software, failover software, etc.

Creating a viable Tile interface often needs just as much complexity as the underlying software itself, which breaks the central tenant of hands-off, zero-knowledge-required platform promises .

Creating a viable Tile requires intimate domain knowledge of the software, systems, distribution, failover, backup, and disk patterns being Tile’d. Except, you, as a fraudulent software provider, don’t believe in “experience” or anything more detailed than a part time one-off, pair-programming , sprint-the-backlog, chill-with-beach-bros, copy-answers-from-google task, so your complex abstraction interfaces end up with extremely low levels of reliability .

Would you trust those results ? Hecks no.

Customers buy your fraudulent platform to enable high reliability of complex operations, but instead they get low reliability of everything. It’s okay though—customers already paid and signed multi-year recurring contracts, so your company can just coast on actually implementing working features for years.

You want to deploy an HA database cluster? Sorry, the Tile for that database only supports one deployment on one server as a singleton across your entire platform.

You want automatic backups for your database? Great! Just ignore when the Tile runs mysqldump over unencrypted netcat and pipes the result somewhere into the network. You didn’t care about your data or PCI or HIPPA anyway, did you? Adversaries have never installed themselves inside a network before. Nope, never. Don’t need to even consider encrypting network connections because all our networks are perfectly safe.

As with multiple conflicting dependencies, Tiles are great for one reason: each abstracted Tile interface increases platform complexity and decreases your ability to reason about the state of your running systems. The platform provider can just wave away “oops, another one time error” each time their abstractions failover and over again. After all, things are so complicated, how can anybody possibly have predicted those errors you experienced?

You’re not going to throw away this seven figure system your CTO bought, are you? The next bug fix will be the last one for sure .

Education, Lacking

As in all good companies, you want to hire and promote based on personal relationships and by measuring n-degrees-of-friendship from the CEO’s social network.

Filling your company with 80% low-information programmers also helps you hide behind shields of “we didn’t see these failures as possibilities! We are blameless for our incompetence!”

As an employee, when you hear the people in charge discuss distributed engineering, you’ll think you’ve landed in bizarro land. You’ll hear things like “We’re highly available as long as network partitions don’t happen” or “We only support single datacenter deployments because you can’t have network partitions in one data center” or “We don’t need encryption because we only support one datacenter.”

When employees in charge of your product make unstable or outright nonsensical architecture decisions, what hope does your product have?

If you look through the Cloud Foundry HA docs you’ll notice signs of architecture-by-ego. The entire system is predicated on the existence of your network always being low latency and never failing or even degrading. The design constraint for your platform is: the network must never fail . They say multi-AZ is okay, but don’t you dare try to deploy this mess in more than one datacenter or region. If any part of your network fails, you’ll have to reboot the entire platform so all the underlying components re-sync to a consistent state .

You can build provably unstable systems while retaining plausible deniability over failures by letting agile pair-programming-above-all-else cultists who specialize in low value/high markup Rails CRUD consulting build your critical systems. You’ll end up with exactly the level of stability you’d expect from merging a couple dozen stackoverflow copy/paste answers together.

Overall

The simplest way to sell fraudulent software: establish a historical timeline of your software just existing.

Customers tend to think software gets more stable the longer it exists, so if you can’t sell your software as fast as you’d like in the first year, just hold off a little. Over the next few years, continue pushing “proof of just existing” as a proxy for product quality and customer value. Customers will naturally think since your company still exists, you must be trustworthy.

For example, Cloud Foundry is 6 to 10 years old , originally created at VMware then handed off to a new company, yet has the reliability you’d expect from a 6 month old system still in beta testing. This hasn’t seemed to deter global-scale clients from being duped into buying a non-working platform overlay and derailing internal system architectures for quarters at a time.

Just keep your customers happy playing “forward-deployed QA in production ” against a platform they already expected to be working. If you’re lucky, they won’t have the gall to suspect you’re an outright software fraud.

S.C.R.E.A.M. (Sales and Consulting Rule Everything Around Me)

How to Sell Broken Software: A Primer

How do you make money off creating provably broken highly complex systems?

Lie Cheat Sell

Here’s a quick guide to selling high margin unreliable software for millions of dollars over a short time frame. It’s what drove a lot of over-valuations in the 90s and it has resurfaced as a popular business model leaving nothing of value behind after executives and investors cash out .

The secret to selling broken software is: sell your broken software. Customers aren’t as sophisticated as you think. Sales teams can sell anything if they are persistent enough. High-value (multi-million dollar) sales is a game of relationships and grit with little to no concern for product quality.

You can basically run a pump-n-dump scam on your entire company. You drive the sales figures as high as possible by playing a numbers game: sales “success” or “wins” are directly related to how much you try to sell. You can sell anything if you hire sales people and set them lose on the world with plenty of incentives and no scruples.

Hire aggressive sales people and incentivize them on unbelievably generous commissions. They will beg, cheat, and lie to customers about anything to close a sale. Platform doesn’t have feature X? It does during a sale! Platform can’t work under conditions Y and Z? It does during a sale!

Sales behavior is aligned to personal incentives, all in service of a sales person hitting their million dollar take home commission targets. Never you mind your product creators aren’t similarly incentivized. Just ignore how your product quality has no reason to improve in the face of sales people making 10x more than product people. Enjoy your fixed salary, dumb programmers. If you were able to lie on command, you’d be invited to the executive retreats and be making real money up in sales.

Remember: your company-wide financial vanity metrics are only sales based. Financially it makes sense to ignore product quality as long as selling least common denominator features churned out by fungible labor continues to ride. You can cheat on product quality for years. Just keep pushing sales as much as possible. Nobody will notice your fraud as long as sales continue. If somebody is buying it, it must be good, right?

If anybody questions you, reaffirm you have big clients and big clients are never wrong. Big clients could never be tricked into buying architectures just from a slideshow and lies. Big clients know they need web scale and durability is a historical relic from the old days. Don’t let your customers notice most of your big clients are also your big investors and have conflicts of interest with being associated with you at all.

Sell, sell, sell. Only sell matters.

The 90s dot-com era had many companies organized around pushing sales as hard as they could then cashing out at the top, even though no working products really existed. The exact same fake-it-and-never-make-it game still works.

As your sales people contact 10,000 companies and end up with 500 sales, your product gets sold. Only sales matter. There’s a sucker born every minute. Your company value goes up, your sales continue (even if it takes 1,000 attempts for one sale—just keep calling) until you saturate every phone number you can call.

Until, one day, your fraud breaks .

Until You Can’t No More

Report the health of your fraud-based company using expected sales flow first, actual sales second, marketing third, thoughts from your thought leaders fourth, paid customer testimonials (who may also be your investors) fifth, and then any residual product updates sixth or tenth.

You need to maintain illusions of stability as customers and media question your viability.

Remember: your customers are scared and looking for answers. Your job is to be confident and pretend to have all the answers. Build up corporate trust and high-level understanding over what goals to accomplish. At no point will customers extensively evaluate your product until after they’ve gotten so brainwashed the blindly agree your product is salvation of digital transformation in a modern era of having a Silicon Valley state of mind.

Eventually though, your fraud will be discovered. It will start slowly, then collapse all at once. Customers will see what they bought doesn’t work . They won’t renew their renewable contracts. They won’t consume their consumable licenses. They will kick you out in the middle of your six month on-site training seminar. Word gets out. Your fraud starts to crack .

Your company needs to enter a protective phase. Sales-driven company values are only disconnected from product value in the beginning. After about 3-5 years, the jig is up and fraud-driven software firms begin to falter. Customers notice you’re bilking them without anything working, their ROI has flopped triple digit percentage negative, and they rip you out of their infrastructure. At least your sales people got their million dollar sales commissions along the way though, so that’s good. They did their jobs. They followed orders.

The protective phase of your fraudulent startup is a shake-up phase: move some executives around , try to impress customers by having your CEO participate on sales calls, get your CEO involved in support issues to give the appearance of “serious attention this time,” and rotate some other CxOs around to give the appearance of moving in a better direction.

Goose your numbers by blurring the line between your investors and clients. Brag about having big clients, even though your big clients are investors financially bound to you .

Don’t let your customers realize big clients with big front-of-site testimonials are also investors protecting their investment. Build up paper thin credibility then shout it from the rooftops.

Embrace poor typographical choices and meaningless platitudes.

Forget how commas work. Re-establish your buzzword-heavy position in industry as the only gateway to the future. You are the only company enabling cloud native transformation after all. Nobody else dares compete with you.

As the fraud surfaces, your priorities become:

Increase Sales At Any Cost implement seven figure take-home commissions for dozens of sales employees! sell sell sell even if you have to lie lie lie your way to the bank. what about the lies? don’t worry, post-sales consulting will eventually get feature requests back to product developers 3-9 months after customer is acquired. then it’ll only take another 18-72 months for the features to make it into a release. customer won’t fight back too strongly, they already paid after all. release PR only using non-standard accounting you can manipulate in your favor “annualized recurring revenue” “annual bookings run-rate”

CEO happiness gotta work your way up to that 5th $10 million house with even more horse farms

Executive happiness give up, go live in Hawaii, remain on org chart as a valued member of the executive team

Manager happiness exclusive bonus programs for all managers! (employees not eligible)

something about employees who do actual product work

As far as sales go, double down on a triple pronged approach:

sell the product where sell means “convince companies to rent limited-term recurring licenses”

sell on-site consulting/training for product mandatory, since product doesn’t make sense and uses wacko made up terminology

sell subscription support for product mandatory, since product doesn’t work and requires routine platform developer intervention



Let your product become just one part of an entire synergy garden of other recurring high-value consulting “solutions” leveraging your provably broken platform.

Every priority will become a mix of Sales and Consulting with actual Product being a distant 5th in any decision making (until the customer is screaming in your face to fix their 10th downtime in a month). If you play your cards right, you can make your platform so complicated it’ll requires a seven figure consulting agreement in addition to a seven figure licensing agreement.

You never want to sell simple, easy to understand, self-contained, and working software because then customers won’t need you anymore. You want to sell 60% working software then spackle over broken corners with co-bundled 6 to 24 month consulting “solutions engineering” packages.

You want the MongoDB model: simple to deploy, but intimately broken software needing recurring support and consulting from the developing company itself to maintain any sort of business value SLA.

Why sell just once when you can sell three times at 300% the price?

Throw your ethics out the window. You are now a company intentionally deciding it’s perfectly legal and ethical to sell broken software requiring months of consulting before customers can even figure out if what they bought works for them. It’s a Silicon Valley state of mind.

Found Your Way to Foundering

Now you’ve decided you want easy money without needing to put in professional effort behind creating working products. How do you get started?

The quickest shortcuts for easy sales while also misdirecting customers are:

start from an established brand exploiting a pre-existing brand will solve some social proof catch-22s

get big name investors everybody trusts decisions of big companies and/or rich people

consult in areas not related to your product have your consultants build “solutions” using your in-house products the customer will also end up needing to buy/purchase/acquire/license as added costs on top of the consulting hourly rates .

have investors act as customers (product) investors acting as customers can also help fudge revenue numbers if your numbers are weak, just ask your investors to buy more products and services—bingo bango—increased revenue and they helped protect their investment!

have investors act as customers (consulting / service / bizdev) accept investment in return for your company customizing products/services to suit the investor’s needs. these arrangements can also be pre-acquisition trial runs — you become an outsourced division for your big customers and if they want services to continue, they may have to acquire you. this can easily backfire if your services are too weak/fraudulent though, since your new bizdev partners will gain first hand knowledge of your inability to provide any value whatsoever. this results in negative signaling when even investors-qua-potential-acquirers refuse to be associated with your fraud anymore.



Let’s look at how the progenitor of the nonviable Cloud Foundry platform managed to establish a founded-to-fail system.

What was Pivotal?

The company name of “Pivotal” is basically meaningless now. Three incarnations of “Pivotal” have existed and nobody seems to notice the differences.

In the 90s/00s, there was “Pivotal Labs,” which failed to be a standalone success and got bought out by EMC. EMC combined unwanted parts of itself, VMware, and the remaining Pivotal assets into GoPivotal. Then GoPivotal re-branded itself back to Pivotal, which still, confusingly, had “Pivotal Labs” as a division inside of itself.

What was Pivotal Labs?

Pivotal Labs was a software consultancy which grew around a gimmick of “agile pair programming.”

You wanted to hire them to consult? Great! But, they only worked in Pairs, so you would have to buy twice the people for twice the price to do half the work. It’s a great scam if you can swing it.

Their model of programming was fairly basic. They’d consult in areas requiring the experience of self-taught teenage Ruby developers. Yet, they found a profitable (for the CEO) niche selling extremely low effort Rails customizations to clients with deep pockets.

Pivotal Labs went on to quite mediocre success. They could sell lightly customized Rails Scaffolding better than anybody else. Have a problem? Slap some Rails on it, never mind how to maintain it. Never mind it can’t scale past 4 requests per second, just come back and pay for more consulting again real soon now .

You can see how Pivotal Labs was a basic low effort/high margin software bodyshop: you only generate revenue when you’re billing directly worked hours. In no sense was Pivotal Labs a software company with a scalable revenue stream .

What was GoPivotal?

In 2012, somehow , EMC acquired Pivotal Labs, the “we only work in pairs, so you’ve gotta pay us twice as much,” Ruby on Rails consulting company. Welcome to a declining corporate hierarchy already in progress.

EMC called all their acquired companies “the federation,” which included EMC itself, VMware, RSA, then Pivotal Labs.

In 2013, EMC created a new company “inspired” by Pivotal Labs. They named it GoPivotal.

Why “GoPivotal?” Well, they couldn’t seem to afford a flat “pivotal” domain name, so they decided gopivotal.com was the next best thing instead.

GoPivotal became a proud owner of the dregs of EMC, VMWare, and Pivotal Labs. The launch PR for GoPivotal was typical trite corporate platitudes:

Note the (weak) social/authority proof already in play: “spun out of … two tech companies each with billions in revenue.” We’re big, you can trust us!

GoPivotal was positioning itself as “a competitor to AWS” except, it had no hardware, no viable platform, and seemingly nobody who had ever run thousands of servers in data centers before, but sure, go ahead and ‘compete’ with AWS .

Pivotal marketing and executives ran full speed ahead into delusional promotional behavior. They claimed Pivotal would out-compete AWS, while simultaneously claiming they didn’t compete with AWS, and in fact, their company was so unique there were no other companies to even compete with—they had the entire market to themselves!

Customers can’t compare your fraud to other solutions if you claim to be unique and incomparable across the entire trillion dollar tech industry.

GoPivotal’s launch PR continually repeated claims of “startup,” but on day 1, GoPivotal had over 1,000 employees across a dozen countries. We don’t call that a startup, it’s just an unmanageable cluster of communication overhead, pre-established political rivalries, personal fiefdoms, and unruly multinational corporate procedures—all from day 1.

Remember to carefully manage your news-speak when spinning up a company under questionable founding conditions.

Founded on grounds of investor-investee synergy: “clouds rich in EMC and VMware products,” GoPivotal’s founding software gambit, this “Cloud Foundry” thing, was primarily built to consume hundreds of cores of giant VMware installs.

Except, it turned out nobody was running the multi-hundred core, multi-hundred GB RAM, VMware clusters required for a minimum Cloud Foundry install. Nobody wanted to buy into VMware lock-in either. Ooops. Sometimes your original attempts at enterprise money extraction fail and you’ve gotta move down market.

After 4-6 years Cloud Foundry attempted to change architecture from “something on top of VMware” to a generic abstraction layer for every other platform host in existence: aws, azure, google cloud, custom hardware, anything and everything (multi-cloud).

Except properly supporting each of those targets would be just about an entire company’s worth of work itself. Ain’t nobody got time for that, so just slap some pair programming here and there then try to fake it til’ you make it.

Overall, the claims of a working general abstraction layer were greatly exaggerated in functionality, reliability, and performance .

But, GoPivotal was never going to buy hardware or datacenters, so the equivalence of GoPivotal to AWS never made sense outside of marketing and CEO bravado delusions. Since original founding, [Go]Pivotal went fully into wanting to be a component on top of AWS and other platforms. You can’t possibly be cheaper than an entire platform if you’re built on top of the underlying more expensive platform.

It would be equivalent to saying you’re going to compete with Tesla by making after-market steering wheels, then bragging your company will one day be worth more than Tesla. After all, a.) everybody has to drive and b.) people use steering wheels, q.e.d. When somebody tries to inform you self-driving cars are the future and won’t need steering wheels at all, you refuse to acknowledge medium and long-term growth as being impossible. You’re having too much fun burning investor cash and wasting the lives of employee’s in attempts to buy your 4th house and 5th horse stable.

Delusions aside, a year after founding, GoPivotal renamed itself Pivotal [dawt io] and their internal IT department rejoiced at spending months converting internal accounts to a new global domain just because.

What was Pivotal?

GoPivotal’s first CEO was from The Industry , but after a year, he saw GoPivotal clearly didn’t have the fundamentals. The platform didn’t work, the original founding premise of the company was already invalid (“Big data! Platform! Open source! Consulting!”), so he noped the heck out .

Two and a half years in, Pivotal found itself needing a new CEO. Executive turnover is the always sign of a healthy company.

The new Pivotal CEO was the ex-CEO of a consulting company. Similarly, placing a consulting company CEO in charge of building out product-driven, high-growth recurring outcomes also a sign of a healthy company.

The first order of business for New CEO was demanding everybody in New Pivotal adopt behaviors of the Old Pivotal Labs cult—the reviled pair-programming agile-backlog-the-poker-24/7-video-chat delusions. Everybody in 2015 was partying like it was 1989 .

Now working 9am to 6pm became mandatory (after all, when your CEO’s only experience is profiting off billing-per-hour, all lemmings employees gotta work the hours to bill the hours). Employees can’t be trusted. Employees must be controlled .

The second order of business for any incoming CEO is to double promote their personal friends inside the company. If you’re a long time friend of New CEO, congrats, now you’re uniquely eligible to sell your private shares and cash out all this failure. Offer not available company-wide. Little front line employee, please ignore the fact your manager got two promotions last year, but as a policy, the company says it doesn’t “do promotions,” so you, weak little front line employees, can’t advance. Enjoy your 1% statutory raise. Sorry, policy.

After the originally declared mission of Pivotal failed , it fell back on a reliable, but heavily non-scalable, consulting model. Full speed ahead to growing a new bodyshop consulting firm.

As a bonus, make sure your fully Internet-based and cloud-powered company requires hundred person meetings and uncompromising 0900-1800 in-office hours. No exceptions. If you work remote, you’re now required to be on video chat all day. Don’t like it? Sorry, you’re not a culture fit, please leave. Remember: employees can’t be trusted. Employees must be controlled. After all, we’re billing by the hour. We’re not paying you to not be standing in the office 9 hours a day.

At least they became halfway decent at placing OMG so quirky lol! marketing press hits.

Pivotal got stuck in a tricky position: their founding mission failed a year in and they had no backup plan. The original plan was to make a resource hog cloud system to run on top of VMware, but no customers wanted that kind of system. So, they initiated layoffs at the end of 2014 and dropped entire product lines customers had previously expected to be long-lived. Whoops, where’d your big data platform go?

With an ability to ignore countless failures of product, vision, and executive decision making piling up, Pivotal doubled down in an unrelenting belief of “market opportunity.” Even though nobody wanted your products, never give up prattling on about endless big opportunities just around the corner. Always next year IPO. Always next quarter big deals close. Always next.

From initial founding, Pivotal bragged “IPO soon! We were founded to be IPO-ready! IPO-ready from day 1! We’re from EMC and VMware—we are definitely IPO ready—from day 1!” with an unspoken promise of unreasonably quick payouts. Given all the mentions of IPO IPO IPO, management was obscurely timid explaining the entire employee option pool was a minuscule percentage of the company . After a couple years of delusions, reality stuck its foot in the door.

The flagship product didn’t work, no scalable business model existed , and it turned out selling temporary consumable hourly consulting was easier than selling higher value (overpriced and under-performing) renewable software licenses. Ooops. Sweep all that under the rug and hope a new CFO can untangle years of male ego mistakes before she’s driven away by overt unethical toxic off-gassing from The Male Management Menagerie.

If you can’t sell your products because a.) they don’t work and b.) nobody wants them (see ‘a’), what do you do? Well, you notice your very shiny double-the-price-half-the-work consulting division still exists.

New Pivotal decided to be more like Old Pivotal and go full speed ahead into consulting above all else. New boss same as the old boss, literally. Pivotal commenced opening dozens of physical offices around the world enabling closer direct access to clients .

How does the product get improved if everybody is consulting and nobody is product-working? Just have your consultants with downtime take a few random hours per week to “work” on the software platform in a zero-knowledge piecemeal fashion .

Protip: If you hire a software company who says they must open a new office near you to be effective, you’re falling down a money pit. You may never see the light of day again. Also, that’s no software company.

In addition to consulting, Pivotal’s secondary mission became a front for hiring out programmers as long-term temps in other companies—or, in modern parlance—“staff augmentation.” Enjoy working in Idaho from Monday to Thursday on internal CRUD apps for 8 months. Also a sign of not-a-software-company.

The split between “Pivotal is a software company” vs. “No, Pivotal is a consulting company” was seemingly never settled. Factions fought between which should rule. Eventually the balance turned towards a split consulting-driven and product sales model.

A product existed, so incentivize your sales people to sell it, with commissions of 5x to 10x the yearly salary of an average employee. Stupid programmer, Mr. Sales just made your entire yearly salary in six weeks. Get back to making things Mr. Sales can sell to get richer off your labor.

Though a product existed, the product didn’t work. Even though the product didn’t work, you could make it appear like it worked by saying: No, customer, you don’t understand, the product is fine, you just need six months of training. Now your sales had an easy path for attaching consulting to all product sales.

Remember: Your company value is based on sales and consulting, not product quality. In fact, you’re practically incentivized to keep products broken products and backfill functionality gaps with consulting to custom patch fixes per-customer.

Why the overt ramping up of remote consulting offices everywhere though? Was it purely to run field interference for broken software? How would having two dozen physical offices contribute to a high-growth—nay, hypergrowth—single-platform software startup at scale? Nobody really knew why and it never made much sense.

Maybe it was all just a hedge? A hedge anticipating when New Pivotal failed, Dell/EMC/VMware would let original Consulting Company CEO personally “re-acquire” the consulting division (which had expanded globally on EMC/VMware/Dell/GE/Microsoft/Ford investor money) at a discount so the perversions of software development could continue well into the future without every having to suffer but glancing blows with our shared ground truth reality.

Assemble your own golden parachute as you destroy a company’s valuation and waste the lives of employees for years at a time—Now that’s a Silicon Valley state of mind.

Pivodendum

As for the whole EMC/VMware/Pivotal/RSA Federation, Dell ended up buying The Federation and now all those lovely products are products of Dell, Inc. Dell, the world-renowned provider of low margin plastic hardware and yet another large organization where acquired startups go to die.

The new Dell+EMC Leadership is an amazing sight to behold as well, but please don sunglasses before viewing:

All possible thanks to Michael Dell’s $60 million Hawaiian vacation estate located next to multiple other $60 million investment banker Hawaiian vacation estates on Hawaii’s Big Island known as a “billionaire getaway.”

Conclusion

It only takes three steps to protect your company from being duped by software frauds:

Pre-Sales: Product First

When interacting with sales people, get to live product demos as soon as possible. Sales will often attempt to push demos off until much later . Maybe they argue live demos are difficult because the product is too big/complicated/involved. If you can’t get a demo up front, there’s a good chance you’re being sold something so complex even the creators don’t even understand it. You’re being led into a money trap of professional services, support contracts, and custom add-ons .

If sales provides a live demo, request your own changes during the demo to verify they aren’t showing you a pre-recoded demo. You may laugh at a prospect of selling multi-million dollar software by cheating at demos, but it happens. Don’t get duped.

If the product claims to have HA/DR/Failover, require live demos of the failover working, then recovering, then continuing as normal. Then have them fail the system again. Then again. Many systems can failover once, but get stuck the second or third time. Point at a node and have them terminate it then wait for other nodes to recover. If failover never happens, their software is broken and you’re being taken for a ride.

If they claim a product is easy to install, require a demo of them installing it in front of you, from initial download to full service availability. If the product is too complex to install or requires “post-sales solutions consultants” to get the software running, you’re being led into a money trap.

Overall, verify you aren’t being sold high markup Bullshit-as-a-Service. Don’t let your executives buy software based on recommendations from other executive friends .

Involve your technical teams in sales discussions as early as possible.

If you encounter errors during pre-sales demos, run away. Don’t assume anything is just a “one time bug” or “a demo mistake.” Always assume you are being led into a money trap. Incentives for sales people lying to customers and cheating their way into signed contracts are too big. Sales people are adversarial, so don’t benevolence.

Post-Sales: Errors are Errors

After you’ve purchased a system , log all errors, log all failures, and record any unexpected behavior.

Don’t believe it’s okay for routine errors to require a system restart.

Don’t believe it’s okay when you’re told advertised features don’t work as advertised.

Don’t believe four requests per second is acceptable. Don’t believe “scale out” solves all problems when your system has 80% unused overhead.

If you get told “you’re not using it correctly,” inquire as to why the system is confusing to such an extent professionals can’t figure out how it should be operating.

Have every team member record each time your purchased system/platform/software fails or doesn’t perform as expected across any and all interactions.

Compile all your error reports into support requests. Require deadlines for fixes. See what comes back. If the errors you filed are truly simple mistakes and your vendor is reputable, you’ll get fixes and follow-ups promptly. If your vendor is irresponsible, your requests will be sidelined, ignored, or delayed for weeks or months or years at a time.

Complaint Procedures: Require Fixes on Deadline

When you file a support request , demand a deadline.

On initial support requests, copy your primary sales rep and any pre-sales and post-sales technical reps you’ve interacted with during your purchase.

Define the required time frame in support requests:

We need these problems fixed within 7 days.

If your vendor fails to actually fix your problems (not just “address your concerns”) within your time frame, you’ll need to bring out the big guns. Have your upper level management and/or CEO follow up as to why software you paid for doesn’t work. The fraudulent company needs to be held accountable.

Have your management send an unequivocal notice of unsatisfactory performance along with an outline of next steps if your vendor fails to fix the software you purchased:

Concerning ticket [X], we have not received a satisfactory resolution to the issue and have escalated this issue to our management. Continued failure to sufficiently fix the errors we encounter will result in withholding of future payments, potential termination of our current contract, and a our legal department will investigate recovering previously paid funds which, in the absence of a provably working system, we must assume were obtained fraudulently. xoxo,

Your Deceived Customer

With vendors, only financial pressure matters. If you have a recurring license, you still hold the strings. If you have a non-recurring (“perpetual”) license, your recourse may be more limited, but you can still make plenty of noise.

If your vendor is competent, you’ll get fixes.

If your vendor is incompetent, you’ll be given the runaround. The vendor’s CEO will call your CEO asking you to just calm down and back off. You’ll be able to sniff out the fraud by that point.

The strongest position you can be in as a customer is having your company’s internal team on your side. You’ll need the support of management, executives, and legal to ferret out previously purchased frauds. If your company wants the poor software to continue existing, you don’t have many choices. Maybe the software was a tit-for-tat, maybe it was a co-venture of investors, or maybe everybody else is so checked out they’re just “doing their jobs” and don’t care enough to investigate systemic failures. You have options, but you may have to fight for them.

Only You Can Prevent Software Fraud

Software fraud only happens at scale.

Nobody buys a $5 million software package from a fly-by-night company with no history and no social proof , but companies are good at faking social proof.

It’s up to you to rely on product proof.

Notice if products don’t have any real world usage . Don’t trust a company’s own whitepapers or self-reporting “we’re the global industry leading standard” — look for non-compensated people who believe in the product you’re about to buy. If you can’t test the system 100% yourself before purchase or if you can’t find proof of real world system deployments, run away .

Ideally, you can find public posts from people praising software. Something more involved and personal about helping them through difficult problems and not a handful of rote copy/paste examples or yet another slog through word count examples.

It’s easy to buy into what sales people say. You’ll feel good about being an instrument of digital transformation in your company. You’ll be a hero if it works! But, without your own independent product due diligence, you’ll get duped, fail for the next four years until you finally realize nothing can be salvaged, then wonder why your skills are 4-6 years behind everybody else on the market. Everybody else didn’t waste their time running dying software—they built the future.

Don’t outsource your trust. Don’t believe vague marketing platitudes without personal verifications.

Remember to live a Silicon Valley state of mind: everybody wants your money the fastest way possible in exchange for as little as possible. Recognize the lies as soon as they drop. Kick toxic sales people and broken technical brands to the curb before they get embedded in your platforms and stifle your company for years to come.

Only you can prevent software fraud.