Maybe you've never contracted for custom software before, and thus don't know what to expect. Or maybe you've had the unfortunate experience of working with someone who, well, didn't have it all together, and so ended up with a less-than-satisfactory result. In either case, it's good to know that there is a well-defined, managable process for designing, building and delivering custom software. Here's how I've been building apps for the last 20 years.

In my experience, building custom software is a lot like building a new house. There's an initial "sales call" where I determine the size and scope of the project to make sure it's within my capabilities, where you sound me out to see if you're going to be comfortable working with me, and and where we mutually set expectations for the development process, costs, deliveries, and responsibilities of each party.

These expectations are laid out in writing in what professionals in other lines of work, such as accounting and law, call an "engagement letter". Since software development - particularly the beginning phases - can be a rather ethereal process, the purpose of this letter is to document how the process works and what each party's expectations and responsibilities are. For example, the final acceptance meeting is no time to start asking about ownership of source code, although I've seen it done by other developers on other projects!

Hopefully the sales call leads into the design process. If you've done any sizable house construction or remodeling, you know this is the fun part, where you get to go through your 'wish list' and see it come to life through blueprints and floor plans. In the software world, it's even better, as I often prototype screens and reports and you can see very much what the finished application will look like.

More than one customer in the past has wondered "What's left?" after seeing a demonstration of a detailed prototype. (The answer is "just about everything - data, business rules, connection to the Internet, testing, and so on.") Viewing a prototype is like walking down the main street of a town in the old Wild West, where the buildings have grand facades, but when you peek behind, you realize there's nothing there.

The end result of the design process is a detailed specification that describes the application as well as itemizes the schedule, milestones, pricing, and covers how testing, change orders, development process in more detail.

Once construction starts, there are often changes to the specification/blueprint. With a house, it's not uncommon to hear a homeowner say, "You know, now that I see what this looks like, I'm thinking we could...." Even more so, software development lends itself to iteration, as the customer discovers new possibilities (as they see what the software is capable of in the hands of the developer) as well as making changes in their company processes. It's a rare application that ends up the way it was initially designed.

Maintenance of an existing application has many similarities to doing remodeling of an existing house. In addition to budgetary constraints (it usually doesn't make sense to put a $200,000 addition on a $70,000 house), there's always a process of discovery when construction starts: "Why did they put a pipe in the middle of THAT wall?"

So it goes with making modifications of an existing application, which is often undocumented and usually contains hidden algorithms and unconventional ways of performing standard tasks. Some folks use formal change orders while others are comfortable with verbal requests. I prefer the written documentation route, as it serves to alleviate misunderstandings and provides an up-to-date description of the system. As with blueprints for a building, the only thing worse than no documentation on a software application is out-of-date documentation.

With house building, the inspector comes by at regular intervals to inspect the various subsystems, such as plumbing, electrical wiring, mechanicals, and so on. With software, a well-managed project has frequent milestones where pieces of the project are delivered for testing and acceptance.

Depending on the type and structure of the application, delivery can be made in one of two ways.

The first is in pieces, where segments of an application are delivered and installed, ready for use while other parts of the system are still being built (much like being able to use the new den even though the kitchen isn't finished).

The other way is all at once. Even though parts of the application are delivered for acceptance testing, the nature of the application is such that it can't be installed and used until the entire system is ready - again, much like not being able to move into a new house despite the framing, electrical, mechanical and plumbing being installed - it's drafty without windows and awkward without kitchen applicances or sinks and bathtubs.

The design phase of a project is done on a time and materials basis. Some customers pay in advance with a retainer, thus ensuring that they get first dibs on my time, which can be advantageous for a critical project. Others prefer to be invoiced on a regular basis for work completed to that point.

The development of the system, including programming, testing and delivery, is done via invoicing per milestone as per the schedule in the specification. Charges for change orders for all parts of an application are included with the invoicing for the current milestone.

This has been a brief outline of how I do software development just to give you the big picture of what you can expect. You'll more than likely have more questions, either about the process in general or about a specific application. Please feel free to contact me - email is best! - here.