I use a variety of technologies to produce the appropriate solution depending on the non-profit’s needs, requirements, and infrastructure.  I strive to always create a solution which will have the lowest maintenance cost for the non-profit, by being easily administrable by the non-profit staff, and also by writing the smallest amount of custom code, so that other software consultants can easily comprehend and extend the solution, if needed.

Since 2009, I’ve focused exclusively on using Salesforce.com for building solutions.  Prior to that, I used a mixture of Microsoft platform technologies described below.

Frontend Choices

I typically build my solutions with either a Microsoft Access frontend database, or a Microsoft ASP.NET web application.  Both solutions work against Access or SQL Server databases.  The advantage of Access is that it is a very productive tool, thus allowing the creation of complex solutions in a reasonable timeframe.  It has a very powerful reporting tool, which frequently is needed to create the types of aggregate summary reporting that many non-profits need for their funders and themselves.  Also, there are many consultants who know Access, and thus it is easy to support an Access solution long term.

On the other hand, if the solution needs to be available to the public on the internet, then an Access frontend won’t work.  In this case, I will typically create a Microsoft ASP.NET solution, written with a mixture of Visual Basic on the server, and Javascript on the client.  I use AJAX (Asynchronous Javascript and XML) methodologies in my solutions in key areas where roundtrip performance would be too slow.

Backend Choices I typically build my solutions with either a Microsoft Access database (ie., a Jet database), or a SQL Server database.  As always, there are pro’s and con’s of each.  Access is easy to deploy, requires no server software to be licensed, works well in small workgroups, and works well with an Access frontend solution. On the other hand, SQL Server works better is some scenarios.  SQL Server can handle many concurrent users, is very robust to corruption issues (such as network packets being dropped), and is the recommended solution when the database will be hosted at an ISP.

Remote Support

When deciding on the appropriate technology for the solution, we must also consider requirements for remote access to the application.  If it must be on the internet and exposed to the public, ASP.NET is used.  If it must be accessible to multiple offices, but not the public, then a solution I have used successfully is to have staff use Terminal Server (called Remote Desktop Connections in Windows XP) to run the application.  This means the application is still running locally at their main office, and just screen images are going over the internet to their computer.

Mix and Match

The final solution is then some combination of these options.  Combinations I have used include:

• Access frontend with a Jet backend (with or without usage of Terminal Server to support remote users).
• Access frontend going through linked tables and SQL pass through queries to SQL Server (with or without Terminal Server to support remote users).
• Access database project frontend going directly to SQL Server (Jet not involved).
• ASP.NET web frontend with a Jet backend
• ASP.NET web frontend with a SQL Server backend