I'm assembling a team to work with me on a green field ASP.NET MVC project.  We will be using ASP.NET MVC 3, an ORM (NHibernate or EF Code First), SQL Server 2008, dependency injection (Ninject or Castle Windsor), and ATDD and TDD (Specflow, Watin, NUnit, and Moq).  If you've done some but not all of these things, I'll teach you the rest to fill in the gaps.

This project will be run using lean methods, so we'll pull in work only when the current task is completely done, meaning the product owner has accepted it and it's ready to go live.  We'll spend a lot of time getting the acceptance criteria just right before we build anything, so there will be lots of small, just-in-time conversations with the product owner.

We'll have flexible hours and do a lot of remote work, but we'll get together for designing and pair programming several days a week, also.  This will be done face-to-face, ideally, but remote web-cam/desktop-sharing pairing is an option, too.  We'll have to tweak this as we go to be sure communication isn't slipping and the work is getting done to the customer's expectations.

For more details or to apply, please check out the careers section.

You need to open up a new market, cut costs, or automate a process. New software can help solve this problem, but which software meets your needs?

There are three main categories of software: 1) packaged software, 2) software as a service (SaaS), and 3) custom software. This article covers the pros and cons of each type of software and can help you make the right purchase decision for your business.

When is packaged software or SaaS the right choice?

If you want a word processor, email client, or accounting package, it's been done. The products are numerous, mature, and range from free to very reasonably-priced.

More and more business software is falling into this commodity space, such as enterprise content management solutions, document management programs, and customer relationship management (CRM) software. These tools have a single purpose and usually very good at what they do.

Cost wise, buying software is usually cheaper than building custom software. As we'll see later on, there are some caveats to this, but this conventional wisdom is often correct.

This is where most software evaluations end. It meets your requirements and it's cheaper. Make the purchase and move on, right? Well hold on a sec.

There are some risks to packaged software and SaaS that are often overlooked:

• They often include modules you don't want and may not be an exact fit for your business. Adding the modules you do want is extra. So is implementing the software and customizing it to fit your business.
• They work in functional silos and are usually from multiple vendors. You've got to be sure it will integrate with your other systems.
• They may not let you get the data out the way you want it.
• Your users may not be as excited about your choice as you are.

Let's take a closer look at these problems and when they may ultimately push your decision to the custom software side.

Get just what you want, no more, no less

Buying software "off the rack" is the way to go if the package meets all your business requirements. But most of the time, you're buying functionality you don't need and missing functionality you do need. You shouldn't have to change your business to match the software you've just purchased.

The common answer is to have consultants implement a solution and customize it to your business. If the packaged software is a good fit with your requirements, this can be a good choice, too. You just want the consultants to come in and round out the corners, though. They shouldn't need to rewrite anything; just configure it for your organization and maybe integrate your new software with some of your existing systems.

But at some point (and it should be pretty soon after the install), the consultants should finish and go home. If they need to stick around for lots of customizations or integrations, you may have lost the justification for buying instead of building it. And don't forget that all those customizations can't just be thrown out when the vendor rolls out the next version of the product you've bought. Too many companies make this mistake and fall into a cycle of perpetually customizing packaged software.

With custom software, the program meets all the requirements of the business and doesn't include any modules you don't want. It usually costs more initially, but because you buy only what you need, nothing more, you won't need to perpetually customize.

Get deep integration with your existing systems

With packaged software, integration with your other systems ranges from simple to a painful implementation project. For example, if you purchase CRM software and want to load all your existing customers into it, the tool should provide this. Most consultants can do this work quickly. Painful integrations are when you can't get the data out, or you can get it out, but you have to use the vendor's very strange API to pull just one record at a time.

If the new system is one piece of a larger process, or if it will be the system of record for your enterprise data, you will have many integration points for data coming into and out of the new system.

With custom software applications, those integration points are built in because they are part of the original requirements. The software integrates deeply with your current enterprise systems.  If done right, the new integration APIs are written in standard ways that are discoverable by any new applications that may come online in the future.

How stable is that vendor? What is your exit plan?

The main value proposition of packaged software is the functionality you get for the price you pay. But that value can go out the window if the vendor goes out of business or is purchased and no longer supports your software. And what happens if you get their software deeply embedded in your business and the vendor goes up on price next time you're negotiating their contract. Vendor lock-in is a real business risk.

In a struggling economy, it's not unusual to see smaller software vendors bought out by larger ones. It's also common to see start-up SaaS companies offering low introductory prices to get customers on board, then gouging them once the cost of leaving that vendor gets high enough. When purchasing software, consider the long term costs and how you would get your data out.

And don't just make a plan. You need to test that your plan really works and you can get the data out when you need it and in a format that is useful to you. This is like a building evacuation plan. Usually no one reads the plan until the emergency happens, and then it's too late. You have to actually test pulling your data out in a non-emergency situation to see if the plan will really work.

With custom software, your business owns all the code and all the data from the start. Most systems are turned over to IT departments after the construction phase, so there is no risk of your data being held hostage.

Although unlikely, it's certainly possible to have your custom software development vendor go out of business or be purchased by a competitor during the development phase. However, if the system is written using your IT department's standards and your application development vendor is releasing working versions of code every few weeks, you minimize vendor lock-in or vendor going-out-of-business risk.

Where is the data stored?

With packaged software, the data is often stored in a proprietary database. Even if it's in a more common database format, many vendors will not support direct queries or reports against the data store.

If you're using SaaS and the data is in the cloud, you can't be sure where it is. That works great for some organizations that really want the redundancy and availability, but for sensitive data or for businesses that are heavily regulated, data security will be a deciding factor in your purchase.

Custom software puts the data where the organization wants it because access to and location of the data are part of the requirements. It's as secure, redundant, and available to queries and reports as the requirements dictate.

Get user buy in

The typical IT buying process is to identify the requirements and find the packaged software that best fits. This evaluation is often handed over to a technical person to be sure the software is a fit for the organization from an IT perspective.

The problem comes when a package is selected and the users are told that starting next Monday, they will be in training, and starting the Monday after that, they will be using the new system. If the users haven't helped choose the software, they may reject it or sabotage the implementation.

With custom software and custom integration projects, users are involved in the requirements early on, and the new system should be tailored to their specifications. They are the most critical stake holders and can set the tone for a successful adoption throughout your organization.

Summary

Software purchase decisions can be as complex as the problems they attempt to solve. Decision makers need to consider short and long term costs and risks of buying packaged or SaaS software as is, buying it and customizing it to integrate into the business, or going with custom application software the whole way. The easy answer is not always the best answer when all the risks are considered.

I used QuickBooks for several years at my last two companies.  It's perfectly adequate for general ledger, basic reporting, running payroll, etc. 

Out with the old...

My gripe with QuickBooks has always two-fold: 1) I don't want to have to deal with their crummy API to integrate with my other apps, and 2) they MAKE you upgrade their product.  One day, online banking and payroll just don't work in QuickBooks.  They cut you off.  Don't like it?  Here's the URL for upgrading.  Argh!

So my feelings on QuickBooks have ranged from shrugging acceptance to hostile anger.  But looky here in the MSDN subscription!  Microsoft has a small business accounting tool!  We're a Microsoft Partner; we should be using Microsoft tools, right?  I installed Microsoft Accounting 2009 to see how it compared to QuickBooks.

In with the new...

On the plus side, the interface is a little nicer in Microsoft Accounting 2009, especially if you're used to Microsoft Office.  It just feels familiar.  The database is a normal SQL Server database and you can do whatever you need to with it.  The table names are pretty obvious, so with a little guessing and a little investigation, you can integrate other apps straight from there.  You can also customize all the reports, invoices, etc. since they are Word and Excel templates.

On the minus side, the online banking is atrocious.  Major banks and credit cards don't work with Microsoft Accounting.  I guess Microsoft is waiting for the financial institutions to support it, and the banks are waiting for users to fall in love with Microsoft Accounting?  Either way, for most financial institutions, you have to go to their web site, log on, download your transactions to your machine, upload them into Microsoft Accounting, then import/match them into Microsoft Accounting.  This would have been fine 15 years ago, but to have a modern accounting tool just open up a browser for you? Microsoft Accounting's "online banking" is just storing some bookmarks for you.  Uhhhh.no thanks.

I have also read other reviews that the payroll side, which you pay a subscription to ADP to use, has the same kind of non-integration.  It apparently just opens a browser for you to run payroll on ADP's web site and then turn around and re-enter that same data into the accounting tool when you're done.  I didn't test this out, I just read someone else complaining about this online.  I didn't want to pay for a subscription to verify.

And back to the old?

This is lame.  You have to be pretty terrible for me to go crawling back to QuickBooks.  Microsoft Accounting is prettier to look at, but way less useful.  And for me and accounting software, it's just about getting my work done as quickly as possible so I can move on to the real work.