Unless your system is overloaded, or you need to use a shared server for a specific feature, a dedicated server will probably serve you best. A dedicated server is simple to set up (in fact, there is no setup) and makes tuning easier.
Note With shared server connections, a session’s trace information
(SQL_TRACE=TRUE output) may be spread across many individual trace files; thus, reconstructing what that session has done is more difficult.
With the advent of the DBMS_MONITOR package, much of the difficulty has been removed, but it still complicates matters. Also, if you have multiple related trace files generated by a session, you can use the TRCSESS utility to combine the trace files.
If you have a very large user community and know that you will be deploying with a shared server, I would urge you to develop and test with a shared server. It will increase your likelihood of failure if you develop under just a dedicated server and never test on a shared server.
Stress the system, benchmark it, and make sure that your application is well behaved under a shared server.
That is, make sure it does not monopolize shared servers for too long. If you find that it does so during development, it is much easier to fix at that stage than during deployment.
You can use features such as the Advanced Queuing (AQ) to turn a long-running process into an apparently short one, but you have to design that into your application.
These sorts of things are best done when you are developing. Also, historically, there have been differences between the feature set available to shared server connections and dedicated server connections.
We already discussed the lack of automatic PGA memory management in Oracle 9i, for example, but also in the past, things as basic as a hash join between two tables were not available in shared server connections. (Hash joins are available in the current 9i and above releases with shared server!)