Purchasing Custom Software

About half of our clients at Black Chair had purchased custom software from other vendors before coming to us. None of them were satisfied with their experience, which I suppose makes sense (our competitors’ satisfied customers would have no reason to jump ship). When they come to us we inevitably hear the horror stories, and I live in constant fear of becoming the subject of such a story in the future. As far as I know, it hasn’t happened yet, but I’m not deluded enough to take credit for that—our processes need work, but even if they didn’t statistics dictate that we will eventually be spurned by an angry client. Nevertheless, the study of ways in which I can delay that eventuality has become a bit of an obsession.

As in all relationships, the crux of the “distraught client problem” (excluding what I will call “pathological clients” in honour of Mr. Patrick Mckenzie) can almost always be traced to a problem in communication: the client didn’t get what they thought they were getting. Now, as I’ve mentioned before, an important aspect of client satisfaction has to do with communicating value. The other part of it (the part which, I must admit, we haven’t done as well as we should have until now) has to do with communicating process so that clients understand exactly how the development process will work and at which points their feedback is required. This process starts long before any contracts are signed, and it can take a few different forms depending on the project and the wishes of the client—I will attempt to outline all of them here.

1. Initial Contact

A prospective client (A) is exposed to someone involved with Black Chair (B). That either comes in the form of an inbound request or a referral or the two parties meet serendipitously (or slightly less than serendipitously, at a conference or networking event; you get the picture). If party A is immediately interested in what B says Black Chair has to offer, they might go directly to step 3. (A and B might also introduce each other to different members of their respective organizations over time—we’ll consider them as a “collective” A and B for illustrative purposes.)

2. Courting (optional)

You know what I mean. Business people getting to know each other over time. It’s fun, and when I do it it’s legitimately not only for the purpose of selling software—I’m very interested in other peoples’ businesses because I’m a naturally curious person and because it makes me much better at my job.

3. The Spark

A and B begin discussing the possibility of a project together. An informal cost-benefit analysis happens (on the back of a napkin or otherwise) to see if it makes sense for all parties. If not, no problem—they go back to step 2. If the project has potential but the feasibility is unclear, they might move on to step 4. If the feasibility is clear and the benefits outweigh the cost, they can jump directly to step 5.

4. The Assessment (optional)

This is a paid engagement where someone from Black Chair assesses the feasibility of a project more closely, often involving job shadowing and interviews with members of the client organization. The goal is to ascertain whether or not the project is viable.

5. The Proposal

Black Chair produces a written document specifically outlining the work to be done, together with an estimated timeline and cost. We often provide options at different price points, and all items are subject to further discussion or clarification at this point. It is very rare for us to go beyond the estimated cost of a project unless the scope of a project changes, and it is never done without giving advance notice to the client.

6. The Contract

Both parties sign a contract using the proposal as a Statement of Work (or, in certain cases, using a separate document for that). The contract is typically built around our Master Services Agreement, but we are flexible for clients with different needs. One of the main considerations of the contract has to do with the licensing arrangement—we typically retain copyright of our work while granting our clients unrestricted use; different arrangements are always possible but may be more expensive. All projects require a down payment at this point; typically 50% although larger projects may be suited to a smaller down payment with milestone payments arranged throughout.

7. Development

There are two main methodologies for managing software development projects (a particularly weird brand of business school grad might argue with me on the details here, but it doesn’t matter): “waterfall” and “agile” development. The latter may be a bit more conducive toward developing excellent software, but the former is more comfortable for new clients by leaps and bounds. Therefore, we practice our own particular brand of each, but we almost always begin projects with new clients using the waterfall approach and occasionally move towards a more agile approach once the appropriate levels of trust and rapport have been established. (We generally eschew the terminology altogether internally, for what it’s worth—the main difference is the idea of a sequential approach vs. an iterative one, as outlined below.)

Waterfall development

Waterfall development is a sequential approach, where each phase of a project is outlined and placed into a timeline. The phases include requirements analysis (mostly performed before the proposal is complete), design, implementation, testing, integration (which could include training our clients in how to use the software) and maintenance. In our case, the design and integration phases both require client feedback. This approach is comfortable for clients because it matches the traditional mental model for how things (especially physical things, like a house) should be built. It’s a completely valid approach, and since it is conceptually more comfortable for new clients this is almost always the approach we offer them.

Agile development

Agile development is an iterative process, in which small blocks of a project are designed, implemented, tested, and integrated before moving on to the next block. This actually matches the mental model programmers have (breaking a project into modules and feature sets) very well, but in our experience it is often unsettling for clients unfamiliar with the process (especially because it often takes several iterations before there is a remotely polished product, whereas the design phase of a waterfall project gives clients something nice to look at right away). We usually introduce the concept to clients with whom we already have a close working relationship, although occasionally new clients prefer this approach because it lets them pay in smaller chunks and reach a functional, if not necessarily pretty or feature-complete, product sooner.

7a. Wireframes

With either the sequential or the iterative method, wireframes are sent to the client for approval. Wireframes describe the layout of the user interface without getting distracted by visual style such as colours and fonts.

7b. Visual style

In the design phase of the sequential method, or in the multiple phases of the iterative method, a visual style showing all design elements related to the project is sent to the client for approval.

7c. Testing and Quality Assurance

This is performed by the developers themselves as well as third parties to avoid the “blind spots” that can appear after working on the same project for hours on end.

8. Delivery

The project is delivered to the client. Final invoices (including the first year of maintenance) are issued at this point.

9. Maintenance & Support

We require the annual purchase of maintenance and support with all of our services; it would be unethical to sell custom software without it, and our clients definitely get their money’s worth: critical bugs (outlined in the contract) are fixed using overtime if necessary, non-critical bugs are fixed within one week, phone and email support are available during business hours, and we monitor server uptime for all of our software 24/7 (with a designated administrator on-call to resolve critical issues immediately).


Software developer, book writer, beer brewer :)

No Comments

Leave a Comment

Please be polite. We appreciate that.
Your email address will not be published and required fields are marked