Bespoke developments for internal use can fall into many traps. 

Technically, it is harder to justify refactoring or behind the scenes code improvements to your client or internal customer -- the completely reasonable arguments being "it works (albeit slowly); we cannot risk instability; we need new features". As a result, there is a temptation to write, or build upon poorly structured code to get things done.

From a user interface perspective, people are trained to use the system. They are a captive audience who cannot go off and use something else so often internal system UIs are fairly abysmal. The hideousness of the SAP web-front end proves this point. This is inexcusable - if people are being forced to use a system as part of their job for hours every day, extra effort should be made to ensure the system is user friendly and works with them in doing their job. A bit like having a comfy office chair that doesn't give you backache after half an hour.

Functionally, internal systems risk becoming blunt swiss army knives - they try hard be all things to all users yet end up doing nothing well. Even if you don't plan to commercialise or sell your software, I have learnt that it makes sense to consider every change request as if the system was being developed with real, paying customers in mind.

It sounds obvious but actually putting a price on tasks, considering the ROI and the number of users who would benefit makes it possible to plan changes more effectively. Competitive commercial edge, even if imaginary or indirect, is an important driver in ensuring a system moves forward.The early adopters of the system often get confused as to why their 'order' of a few feature is not implemented. An internal system with five users is a different prospect to one with several hundred. 

Users are the lifeblood of a system should be listened to, but it can be dangerous for them to be in charge. Did you see what happened when Homer Simpson's brother let him design his dream car?