Off The Shelf Isn’t as Great as You Think It Is.
Commercial-off-the-shelf software and its cousin modified-off-the-shelf software are popular solutions for many business needs, and it’s no surprise that it is a 400 billion-dollar industry (in 2023). For smaller businesses, a COTS solution might be the only viable solution for them. The risks related to hiring developers, paying them for a period of time before you can see a return on investment, and have no guarantees that what is produced will actually grow your business is beyond what anyone would consider acceptable.
So, they turn to a popular service and hope for the best. They might be paying through the piss-hole for it, but at least they are seeing some sort of improvement, right? Right?!?!
Things are Not Always What They Seem
Before investing in any sort of software solution, it’s important to have a set of expectations, and what you are going to compare those expectations to. Some call them key performance indicators, some call them baseline metrics, some call them the data from the before time, from the long, long ago. Doesn’t matter what you call them, you need to know what it is that you want.
When dealing with third-party vendors, it’s important to understand that they have ways of spinning bad performance into a positive thing.
Take, for example, a company that implemented a conversational AI to better direct incoming phone calls to the correct departments. The months after implementing it, the calls sent to the general queue didn’t go down at all. When this was brought up to the vendor, they responded with “imagine how many calls would be going to the general queue if we hadn’t had this software in place!” The executives on the call ate that shit up, and they still use the same shitty AI that everyone hates.
Without knowing what it is you are looking to get out of your COTS, you will easily be fooled by the old “nuh-uh, it’s working great” routine that vendors love to pull.
For some, they say “well, all I want out of it is a software that tracks my customers, their invoices, and contact information. What else do I need to know?”
Bitch, you still need to know a lot, damn.
When talking with small businesses (and in a few cases, home businesses) decision makers tend to gravitate to the recognizable name. It’s a name they can trust. Yeah, it’s $2,000 a year, but it’s worth it to have something in place that takes care of what I need.
Ask yourself, if you just need a client/invoice tracker, is $2,000 a year really worth it? No, you need to think about this shit more. Specifically, there are two things to consider before buying that name-brand off-the-shelf shit.
The Two Shitty Types of COTS
Imagine with me if you will, a bit of software that determines what you make for dinner. It breaks everything down into national cuisine, then, through several levels of refinement, spits out a dish you should make.
You’re testing it, and you notice that everything that is under Mexican food is listed as “Tacos –{food}.” You are confused why it’s suggesting Tacos-Chile Relleno but won’t ever suggest Tacos Al Pastor. You reach out to the development team handling your implementation to find out why, and they say, well, Tacos are the most recognizable of type of Mexican cuisine. You ask why it won’t ever suggest just a regular taco and they say, oh well, if you want tacos to show up, you’ll need a new national cuisine created.
So now you have Mexican and Mexican-Tacos as a choice for national cuisine. Now when you are testing, however, you notice that bulgogi tacos are no longer listed under Korean food. In fact, every single taco-style food is missing from every type of national cuisine. Well, you are informed, everything that is a taco-like food is now considered Mexican-Tacos… hot dogs, gyros, po-boys… even New York-style pizza is now considered a taco because you can fold it in half and eat it like a taco.
This sounds crazy, but it’s an exact argument that I had. The solution as they sold it was to create duplicate national cuisines so that everything would stay in their correct cultural origin, only now with the national origin and national origin – taco-like. The cost of implementation more than doubled because we now had Mexican, Mexican Tacos, Mexican Soups, Mexican Coastal, Mexican Vegetarian… etc…etc…etc…
What was the reason they couldn’t just have a structure that made sense?
The software isn’t built that way.
So, you ditch provider A and go with this other provider.
They build everything out, and you start to test and find that there’s no filtering beyond just nationality. Click on a national cuisine and you’ll get a random suggestion. Need dinner? You get flan, need a dessert? You make coq au vin. Have to be aware of allergies? Make a walnut and soy salad with hard-boiled eggs and anchovies. You bring this up with the devs at provider B and they inform you that they can add additional modules to further refine the search but… it’s going to cost you… it’ll cost you out the ass. Every additional level of filtering is going to run you an extra charge of $50 per user per month.
Again, pretty crazy right? Again, this is a conversation that I had recently. In order to achieve the base functionality that we were promised, the monthly fee would go from $45 per user per month to $488 per user per month, and that was making significant sacrifices to our requirements.
There is a third option, and that is the fuck you, you work within our software, figure it out or fuck off group. But we will get to that later.
They Don’t Care if it Doesn’t Work, as Long as It Goes Out on Time
The idea of a minimal viable product has seeped in and ruined software development. It’s now used as an excuse to push out shitty code, products that barely work, and software that pushes the limit of what acceptable risk is.
When I say it’s an excuse to do these shitty things, that is just what it is, an excuse.
You should know, however, that there are telltale signs that your delivered solution will not be what was promised. First, they start over-emphasizing prioritizing work. There are a lot of things that they hide behind when asking, but it’s always behind a veil of “you’ll get what we promised, we’re only thinking about your testing, we’re trying to help you. Then, when you least expect it, those things that you didn’t prioritize get left off the final deliverable.
The excuse? You should have prioritized it.
The second thing to watch out for is when work seems to slow down, and it appears that the project is behind schedule, but the project team swears that it’s on track. OR… suddenly a ton of work was magically completed in a very short period of time. These seem contradictory, but the effect is the same, it delays your ability to properly test.
Why, you ask, would a lot of tickets being completed at once be a cause to slow down testing? Two reasons, either the work being done is going to be buggy as fuck, or because you are now overwhelmed with tickets to test. Either way, you can not get the testing work done you need to, in the time allotted.
When working with a third party, it’s important to realize at the outset that they will only care about one thing, getting the work out on time, and no, it’s not because they want to provide you with the best possible experience, it’s because they lose money if they have schedule run-overs. So, if the project is running late, they will find a way to blame you for it.
They Will Find a Way to Blame You for Everything
Let me ask you, dear readers: who knows the third-party software the best? If you said the client, you’d be in line with how third-party software developers tend to think.
Stupid, right? I would be astonished if ever in the history of project work that the client knew more about the implementation than the developers/service providers did, but this is a mindset that so many teams have. The client knows best.
Let me provide you with an example of a recent argument I had with a vendor. Early on, we told them that we had this bit of logic that must be passed as X. We sent over an example, and they said no problem. Suddenly, with one week left to go live, they said they couldn’t deliver this one bit of logic (something that is blocking our progress. They claim that the data format isn’t X, it’s χ. What’s the difference, I asked. Our current vendor calls it X, the other vendors we considered called it X, you yourself called it X when we told you about it, why is it suddenly χ?
Well, I should have known better, according to the vendor. Their software doesn’t support χ, and we told them it’s X.
It left me baffled. When I asked how I was supposed to know that they didn’t support χ, they said it’s all in our documentation… documentation that I didn’t (up until that exact moment) know existed.
A separate vendor blamed us because their database didn’t use primary keys, making a request that seems so routine that it’s laughable, impossible to implement.
In a recent discussion with a friend who works for one of these asshole third-party teams, he argued that no one knows the business's processes as well as the client, so they need to dictate how things will work. I threw my Baja Blast in his face, flipped over the table at the Taco Bell, and told that fucker to never speak to me or my son again. I then walked out with a random child before realizing that I don’t have kids, and returned him to his bewildered mother.
End of the day, it’s not on the client to know the constraints of the software. They can tell the team what they need, and how they operate until they are blue in the face, but ultimately, it’s up to the provider to tell them if things can or can’t be done.
Why It’s Not Much Better with the Unmodifiable COTS
Software that is literally off the shelf, where nothing can be customized, you just figure it out seems like a great idea. It beats dealing with implementation specialists in the hotness du jour company. Buy the software, configure it yourself, update your processes to work within the new functionality, and off you go.
There is a downside, though. Scalability.
It’s something that is frequently glossed over when discussing software choice. Will you be able to grow with this software, or does it have a hard ceiling? These are questions that you must ask yourself before diving face-first into the world of commercial software.
May the FOSS Be with You… And also, with You
For those who don’t know, FOSS stands for free and open-source software.
There is always a concern that when we start talking about doing work internally, that you are going to have to hire a huge dev team and build your software from the ground up. It can start to feel like building a Maserati, using nothing more than chicken carcasses and left-over Christmas wrapping paper.
But there is a solution. Free and open-source software. There are a lot of examples out there of software that can be used to solve your problems. In fact, many of these paid SaaS companies are built on the back of FOSS.
However, for many executives, the idea of using open-source software is scary and opens them up to the dreaded hackerman.
We are here to put your mind at ease. Open-source software is very safe. Being open-source means more people are in there, making sure there isn’t malicious code or code that leaves you vulnerable. Further, most FOSS is going to come with libraries of documentation, that allow you to implement it with very little knowledge, or with a limited team of developers, thereby saving you money over other implementations. In fact, a client of ours paid a dev from Fiver to set up Akaunting and walked them through some of its basic functionality.
The paid services will brag about their white glove customer service, which you won’t get with FOSS, but ask yourself… is it worth it to pay through the nose for a program that won’t work for your needs, just because you have some kid you can call at all hours?
Even with the most stringent of due diligence processes, the sales teams at the SaaS organizations will lie to you, until they make a sale. Especially for small businesses, ask yourself, is it fucking worth it?
Comments