The moment you join two standard apps, the result is customisation.
Windows, SQL, IIS & SharePoint might be standard, but every one is different and will need some customisation to interact in the way that you want them. There's always going to be that extra service or log that will need checking.
Both Home-grown applications, as well as "Customized" pre-built applications would fall into the category of custom applications.
So the real question is, how do you get credit for voting and responding to this question? 😉
I believe it can be either. You can have a custom application created, either in house or hiring it out. An Off The Shelf Software/Application can also become customized, so much that it it can't be upgraded to a new version because of all of the customization. In this case it is probably like a customized car, you might have bought the framework and done your own work on it so others could see it has been customized, (not just a trim selection.)
To me the key word of custom is the defining element. Home grown is obviously custom, but when an application is purchased that has customer defined changes built in would be a custom application. The distinction would be something that is built specifically for the individual customer.
A custom application is anything which is either developed from scratch or changed from its default state. Example, SAP. if you get it and keep it vanilla it is not a custom application. But as soon as you make changes which affect its normal default process it becomes custom. There are special considerations for upgrading and patching. Like @rschroeder said, they become more challenging to support. I am not talking about making a Macro in Excel or a website per say, more along the lines of major applications, like and ERP or SolarWinds. If you were to change the Database behind SW to make it do something you wanted, it becomes custom.
A "Custom Application" means, to me, something that is challenging to support. There may be only one person who understands it because they wrote it. If/when they leave the organization, that custom app is a liability waiting to bite a team, either through its failure, or through the inability to further modify it to meet new requirements.
In short, "custom app" often means "trouble".
But that applies to apps built outside of standards, and to teams that aren't properly staffed and funded. There are many custom apps that have no problems, that are continually modified to meeting changing requirements, which we never hear about--because they were created according to standards, and their staff is properly numbered and funded for training and design. They have enough depth that some people can change departments or even leave the company, and the app still is fully supported and retains utility and reliability.
"Custom App" may not only apply to something completely unique that was never "in the box." It can be an application with a specific, targeted use case, and not be flexible enough to handle other needs. Once upon a time, Excel was probably considered a "custom app" that was targeted solely at accounting types. Then others realized it would be helpful for managing inventory, organizing people, planning changes--heck, I recently ran into a video about a fellow they call "The Michael Angelo of Microsoft Excel", who does Master quality art using Excel. It's immediately obvious Excel left the realm of being a "custom app" generations ago. But when it was new, I'm betting there were plenty of people who thought inside the box, and put unimaginative limitations on how they would be able to use Excel.
So there it is--"custom application" must have some flavor of "limited use" to it. It solves only one kind of problem, or it has limited support, limited ability to be modified (or "de-customized") to serve other needs. It's likely to have a narrow user base (if not, it would have been exposed to bright people who would have asked "why can't it do . . . ?", and then learned enough about it to make it serve other needs--or they'd drop it in favor of something more flexible).
There's nothing wrong with a custom app that fills a specific need well. But apps become bloated when asked to do many things, to serve many needs. (They might just even be hiding a version of Flight Simulator, making them far bigger and complex. The moral of THAT story is to give credit where credit is due, and treat your employees as you'd like to be treated.) For an app to remain "custom" in my mind, it has these kinds of limitations.
I actually think of custom app in two separate ways.
Customizable - Means its an app you take and make it look how you want. Much like Orion or SAP.
Custom built - An outside or inside team builds from the ground up, an app that suits pretty much just your organization.
I would call them differently as-named in the question
An application that is designed to work on your organisation, A specialist feature, an example would be a Airport boarding card printer. This printer is designed and only used to print boarding cards used at airports. It can NOT print a word document on a A4 size of paper. Therefore it 'custom'
Another example for custom application would be an airline app for boarding, this would hold your boarding pass, flight miles/points, frequent flyer ID. This application is custom and cannot be used for News, Sports, Games, keeping fit, etc etc
SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 150,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process.