The Single Sign On

It's unfair to blame the consultants when it was entirely the client's project manager's fault. It's the PM's responsibility to figure out how many of her company's employees will use it and whether or not it's worth the cost. There's not a whole lot the consultants could have done, even if they had had the foresight to ask "By the way, is this only going to be for one user?" or "Are you really sure you want to do this?"

There really isn't anything in this story that would allow us to comment on the profitability or lack thereof

Couldn't they just let the browser remember the password?

Kolmogorov Complexity relates to the idea that you can use some kind of computer to encapsulate repeating patterns. When you do this, you have to store the data of your program somewhere and its size relates (sort of) to abstractly just how complex the problem was.

It's also equivalent to Minimum Message Length, so looking into that might help.

Roughly, the relevance remains the same if you just remove "Kolmogorov" from the op's statement. The manager doesn't understand that inventing a whole new solution is complex no matter how many or few people use it.

Which isn't strictly true, but it's definitely a good rule of thumb.

To someone who doesn't understand what's going on, it may seem simpler to make something work for one person than to make it work for lots of people; but in fact the version that works for lots of people may be no less simple. (It may even be simpler, if it's necessary to put in special-case testing to make sure that only one person can use it.)

From an implementer's perspective, the right measure of the complexity of a system is "how much code does it take to implement?" (which is more or less Kolmogorov complexity) rather than "how many things can it do?" or "how wide is its range of possible behaviours?".

A few other remarks on Kolmogorov complexity:

1. "Random" is often best understood as "of high Kolmogorov complexity": a sequence of numbers is random if there's no way to generate it that really saves anything over listing all the numbers; no pattern that makes it predictable. (In practice, what you usually care about is that certain restricted kinds of pattern don't occur, which is kinda like a version of Kolmogorov complexity where you're limited to using programs in a language that isn't Turing-complete.)

2. If you apply Ockham's razor in the form "prefer hypotheses with lower Kolmogorov complexity" together with Bayes' theorem, you get something that in a certain (rather artificial) sense is as effective a problem solver as anything mechanized can be. Unfortunately it's unimplementable in practice, because ...

3. It's more or less always impossible to determine for sure what the Kolmogorov complexity of anything is. (Because to be able to do that you'd need to be able to answer the question "do these two programs do the same thing or not?", and that's equivalent to the halting problem.)

4. (This is controversial, but it's my opinion and that of at least some other contributors here.) When assessing (e.g.) scientific hypotheses for "simplicity" or "parsimony", something like Kolmogorov complexity is the Right Way to understand (un)simplicity; failure to appreciate this is, e.g., what makes some people dislike the "many worlds" interpretation of quantum mechanics on the grounds of extravagance, or think that "God did it" is a useful explanation for otherwise-surprising features of the universe.