Our church software project, Church Radius, has gone live! We’re pretty excited about it here. It is a web-based solution that we are offering with a software-as-a-service model. We are taking the SaaS approach to an area that can really reap the benefits of low upfront costs, pay for what you use, on-demand, access from anywhere, etc.
We’re just getting off the ground so if you think this is interesting, we’d really appreciate links, reviews, comments, etc.
Just to give a bit of history, I have been connected to a church software product since 2000. I have been patiently waiting for the opportunity to really overhaul it. Originally I was thinking of a .NET-based P2P smart client but the P2P framework I envisioned was a bit too ambitious. And frankly the church software market for Mac and Linux is really underserved so a web-based solution seemed like a really good idea. The software-as-a-service approach lets us help churches avoid spending money on servers, new workstations, etc. in order to run Church Radius.
Since this is a tech-oriented blog, here are some implementation details: The site runs on ASP.NET 2.0. We built everything using Visual Studio 2005. We use ASP.NET Membership, which was a real boon because it was almost plug-and-play. We did a little bit to integrate our account management with the membership database but otherwise it was just so simple. And of course we are using master pages. You have to love master pages!
The backend is SQL Server 2005. The login account from the web site to database only has permission to execute stored procedures to remove the risk of SQL injection vulnerability slips. Because our church software is a hosted SaaS solution, we have multiple customers on the same servers. Every stored proc has to accept an OrgId and use it for every query (we monitor that part manually). Of course that lets you create a clustered index on OrgId for all tables to allow for efficient queries since each church represents only a small subset of the data in a table (so the execution plan is likely to use the clustered index).
We use NUnit for developer testing and NAnt for nightly builds on a dedicated build server. I also created a little web page that any developer can hit anytime to initiate a new build. I really should publish that to this blog one of these days. The NAnt script was a port from another project and is almost completely redundant now since basically all the build work is shelled out to MSBuild.
Right now I am working with Watir to do automated UI testing. Watir is a Ruby testing framework that automates IE. I highly recommend it.
Anyway, that’s what we’ve been working on at Ardent lately: church software-as-a-service. Check it out and please spread the word!