> IME this part is completely wrong, unless it's defining "serious buyer" in such a way that most of your market isn't one.
I used to be such a "serious buyer". I represented a large government agency with over 2,000 sites and several hundred thousand employees.
Vendors would turn up with "cute" web apps that used drop downs to select objects like security groups or user accounts. This works great when you're developing in a toy environment in your dev lab.
In the real world, merely clicking something like that will make both the server and client use gigabytes of memory until either one or both crash.
Here's the thing though: if you can put just a modicum of engineering effort into making your software suitable for non-toy scenarios, then winning even just one enterprise customer like this could make your rich. Win two or three similar orgs in other states or countries and you can start subscribing to Superyacht Owners' Quarterly.
But there will be no yacht because you used a drop-down. A simple control that can be implemented in minutes instead of a search box that takes a few extra lines of code.
Sorry...
PS: On a more serious note, I had a checklist that wasn't long or all that difficult to implement, and 90% of vendors would fail outright on most/all points.
1. Search-for-select
2. A provisioning API of some sort (REST, PowerShell, whatever)
3. Hierarchical permissions & delegation
4. Hierarchical policy & preferences
5. Single-sign-on support
6. Central audit & error logging
7. Clone-to-deploy and/or highly automated setup.
8. Don't demand Domain Admin rights for setup.
9. No quadratic (or worse) scaling issues. (USE INDEXES in the DB!!)
For large organisations the amount of entries in the dropdown is probably very large. To fill the dropdown would then require significant work on the server, and to build up and show the dropdown would require significant work on the client.
Edit, of course a proper solution would be well-thought out and would not crash, but that solution would also not be using a single dropdown to show all possible values because that is not usable when it is more than 20 entries.
Modern backends and frontends can surely handle way more than 20 entries in a dropdown without sweating.
But in case you do have a LOT of entries that modern hardware cannot handle efficiently, just switch to a selector based on a search box (perhaps with autocomplete), instead of a dropdown.
Since it's an easy modification in the UI, perhaps these startups used a dropdown for simplicity, knowing they can change to a selector search box quickly, if it becomes an issue.
> Modern backends and frontends can surely handle way more than 20 entries in a dropdown without sweating.
I agree. I meant that I as a user will not find it usable enough if I often have to search the correct value in lists of 20 or more.
The discussion of the load on the frontend and backend was about amounts large enough to create problems if the developer wrote naive code, but we did not get in to a specific amount.
because toy apps that use dropdowns like the OP mentioned will do a "SELECT * FROM security_groups" at the backend (requiring RAM for the whole thing to format the response) and then send it down to the frontend which will then spend eternities formatting the list in the DOM as a complete UL/LI of objects that will blow up the front end.
Drop-downs for unconstrained lists are just flat wrong, they become unusable at a mere few hundred entries. Even with just a few thousand, you'll see only a tiny subset of accounts/groups/objects and it'll look like this:
AADEN
AADIT
AADVIK
AAIDEN
AARAV
AARIZ
AARON
AARUSH
AARYAN
AAYAN
AAYDEN
ABDEL
ABDIEL
ABDUL
ABDULLAH
...
The rest of the list will be cut off past the bottom of the screen, or have a tiny down-arrow that will scroll down... one... item... at... a... time.
I would do the "look at the server RAM disappear like a magic trick! ...and now the whole server is gone!" demo to really drive the point home, but that happens around the 200K-1M object level (depending on the software).
About 50% of the time there would be a senior developer there who would just slowly blink at me and suggest the "solution" of cutting down the directory to a more manageable size, like 50 users.
Like... yeah buddy. We'll just delete 99.975% of the user accounts in the directory system because you learned programming from a "4 Dummies" book.
Sure, you can roll the dice on a handful of big organisational buyers, and you may find that good engineering is what they're after. But there's a whole lot of politics (organisational and other), relationships, and other stuff in play; having a heavily engineered product is not remotely a guarantee of winning that kind of contract.
Well, 2 of them are hard, the others are the kind of thing you get if you let a developer take a week or two to solve them at the beginning, but almost impossible to create after the system is built.
So, 3 months of up-front work. It very likely won't break any project/company, but it's enough of a drag that most people will say "fuck it" and not target large enterprises. And, well, there are plenty of other reasons not to target enterprises that the GP isn't talking about, so it may be a good choice.
Having worked at a large enterprise I agree that there are many good reasons not to target 'us'. However far too many companies are rocking up to sales meetings with large enterprises and have no idea about their actual needs and the scale and problems of selling to large enterprises.
Having also sold to large enterprises, you have to be willing to sometimes spend 3-6 month developing a really obscure feature that will only be used by that one customer to get the sale.
I used to be such a "serious buyer". I represented a large government agency with over 2,000 sites and several hundred thousand employees.
Vendors would turn up with "cute" web apps that used drop downs to select objects like security groups or user accounts. This works great when you're developing in a toy environment in your dev lab.
In the real world, merely clicking something like that will make both the server and client use gigabytes of memory until either one or both crash.
Here's the thing though: if you can put just a modicum of engineering effort into making your software suitable for non-toy scenarios, then winning even just one enterprise customer like this could make your rich. Win two or three similar orgs in other states or countries and you can start subscribing to Superyacht Owners' Quarterly.
But there will be no yacht because you used a drop-down. A simple control that can be implemented in minutes instead of a search box that takes a few extra lines of code.
Sorry...
PS: On a more serious note, I had a checklist that wasn't long or all that difficult to implement, and 90% of vendors would fail outright on most/all points.