Apart from performance concerns, should web-based applications be built differently according to the number of (concurrent) users? If so, what are the main differences for (say) 4, 40, 400 and 4000 users?
I'm particularly interested in how logging, error handling, design patterns etc. would be be used according to the number of concurrent users.
I am no expert in this..but here is what I think.
Using design patterns extensively, building extensive logging capability etc. may not be very necessary if the application is going to be used by 4 known users - in the sense that every extra unit of effort you put in brings in lesser rewards.
However, if the application is going to be used by more people, you have concerns such as scalability, security etc. Using design patterns etc may make more sense. Of course I am making the assumption that if its just 4 people using an app - it is probably not very mission critical.
So I believe you should start simple, and make changes as needed. However following good design patterns is always good - ideally your design allows you to change parts as needed.
The answer given by aip.cd.aish has given me this idea:
I think that the answer is to estimate the cost vs. relative benefit of engineering effort in a given situation.
It is not uncommon for apps with fewer users will add less value to the business, but you need to look carefully at individual cases.
Indeed, there are instances where fewer users justify more engineering effort. For example, if your app is used by a few key customers who will go elsewhere unless your offering offers a better service then your competitors, then you may be justified in spending time on solid engineering.
Specific ideas:
Logging: For "small" apps, you may be better off actually talking to users (...I know...) rather than logging everything. For "large" apps, indescriminate logging can mean that logs grow too quickly to be of much use.