ERR... missed the point of your post @JZM, but the info below is at least a little useful regarding your question
Originally Posted by JZM
You ask a very general question, multipurpose could be heavily ajax driven with fancy front-end and not as heavy on the server side and still uses MVC and admin areas.
Generally speaking, you want to first decide where your application is going to live? On Amazon, your local server(s)... Are you going to use separate servers for your asset serving and another for your Database server(s). You also want to know if you will be load balancing the application so that you can decide how you want to handle session data - say for authentication users jumping between servers.
DNS (Domain Name Service) also plays into this equation. If our DNS is slow then the application will be slow, so we need to think about how our application will make use of DNS and plan accordingly.
You need to understand what type of team will be working on the project? Are you going to use contract people for the SQL, front-end design, or any other aspect of the application. It may be that it is going to be a single entity project - you.
This leads to planning the kind of application layer. There are many choices so what do you need for your project; A simple MVC structure, Service-Oriented Architecture (SOA) (which often dresses up MVC in different terminology), or any of the other (many) architectures that are currently in favour? pick one that fits your content and the functionality of what you need to do with it.
An application will take on an 'organic' good or bad architecture if you don't plan or make an active choice. I support the idea of choosing rather than letting it take its' own shape. This doesn't mean that I don't like iterative styles of development I just like to understand the architecture/engineering of the application I am building.
Once you have an idea of what you are going to do from your architecture standpoint you need to decide how you are going to test the application. If using a test suite like PHPUnit or SimpleTest then you should setup the scaffolding for this. I like writing my tests before the code is written and write in small chunks. I prefer behaviour driven development( http://behaviour-driven.org/)
Then you get to choose what type of Coding patterns you want to use in the development. Really once you gain experience you don't specifically think about 'what pattern' but you are basing a choice on an appropriate pattern that best suits and has the best trade-offs in your application.
For customers I like to do iterative releases and publish the test website from day one, so they can visit, try and watch it grow. The also get the chance to flag problems - typically logical or conceptional - earlier when it is 'less costly' to change course. At first customers are not used to this idea and say 'Just show it to me when it is done' but I get them checking regularly early on, they get used to it and like it after a while.
If a team then I often do more project management than code, managing risks, planning, preparing what developers and designers need, and working with the infrastructure people (where it will live). If I am doing something on my own then I generally start this part of the project by designing the database and also (for variety), I work to get the asset servers, load-balancers, and DNS working. I generally don't design the whole database I first look at the most complex relationships and figure out how to handle them, then I work on building just the parts of the database that I am currently working on. I build a 'Model' test first that will fail because there is not yet a table created for a sql query to succeed. To satisfy the test I create the table(s) and appropriate SQL. I keep this going until much of the model data is ready then I work on the controller level and finally the view.
I know that this description has been fairly general, but also hope that it helps with your question.