Implementation Details
In our technical investor portal project, this development approach worked quite well. We set up the production environment and created some skeleton lists and collections. The project sponsors inserted data and documents and extended the content schema where needed. We were able to do some rapid application development, working together in real-time with the sponsors to get the application most of the way done as far as functionality goes. We then mapped out the remaining functionality that could not be done through configuration of SharePoint's native abilities, as well as look and feel changes. The plan was taken back to the development environment, and our team of developers and graphic designers went to work on the custom code. By minimizing the amount of custom coding, we achieved the following benefits:
•  Maximize SharePoint's abilities: You pay your license costs once so you should try to use SharePoint's abilities as much as possible. SharePoint is a powerful development platform, and you can custom code literally anything if you want to. Instead, try to think about how a SharePoint capability can address the requirement through configuration. Doing this wherever possible helps you achieve greater and greater ROI on license costs, as they reduce custom development time for each feature but you pay the license costs only once.
•  Increase supportability: The less you customize your solution, the easier it is to maintain and upgrade the solution in the future as new versions of SharePoint are released.
•  Decrease maintenance costs: Up to 50% of a project's total cost can be during the maintenance phase. You're guaranteed to want to change the application in some way after it goes live, especially if it is well received by users. They will have many suggestions and enhancement requests. Maximizing your use of SharePoint features will allow you to more easily change the application in subsequent releases.
•  Minimize testing: Fewer moving parts and fewer lines of code translates into fewer things that can go wrong. This helps reduce testing time and allows testers to concentrate on verifying that the application correctly meets the business needs, as opposed to chasing down bugs introduced in construction.
•  Make it manageable: SharePoint contains a rich user interface for application management. Users learn it once and can use it on any SharePoint application. It is easy for non-technical users to manage their applications if built from SharePoint entities like Lists, Libraries, Collections, and Custom Content Types.

As a side benefit, the production environment was set up and sanity checked early in the project timeline using this approach. We were able to work through some snags with user creation, permissions, and security early on in the project (as opposed to the final few days, during deployment). Deployments between the three environments were done early and often, allowing us to fine-tune the process well ahead of the go-live date.

Once we finished the custom code and changes to the look and feel (including master page creation, CSS, and graphics), we packaged up our changes and got ready to push them to staging. The business users had been working in parallel to continue to add content and refine the solution in production. We did a quick refresh of content from production back to staging, and then pushed our code to staging. Our code worked in staging, making us very confident that it would do the same in production. We were able to test everything fully in staging, knowing now that they only "delta" between staging and production now was our code

Conclusion
We completed the collaborative portal in seven weeks and soon deployed it the client site. Most of the work was able to be done off-site after an initial meeting and some scoping conversations. The project was well received by both internal and external users. Word spread about the success of the project at the client. We began work less than a month later on a project to develop another SharePoint portal for this client. We learned even more on that project, which I hope to share in another article.