Drive-Thru Programming

There’s a delightful phenomenon that happens with clients after the first contract is executed and fulfilled on, and that I call “Drive-Thru Programming”.

The way I am most often engaged professionally is like this: a client needs me to build a web application, we sketch out the relevant particulars, I write up the resultant scope of work contact (which details features, price, and payment schedule). It’s signed and we’re off to the races.

Once that contact has been fulfilled, all the money has been paid and everything outlined has been built and delivered to my client’s satisfaction (and I’m not done until they love it). By this point we’ve invariably established a really good rapport: we know how we work together, trust is there, quality, value and workability have been demonstrated.

This situation makes possible Drive-Thru Programming.

What is it? It’s a style of handling requests for development work on a rolling basis that is tuned for speed and ease.

It’s quite common for clients to want to evolve and expand upon the applications I have built them. After the first contract, the formalities of said contract are far less important. So I’m free to operate as a fluid, on-demand programmer for needs as they arise. So we get to have email volleys that look like this:

9:41am, Client: Hey John, can you add to the system this, that, and the other thing, and how much would it cost?9:48am, Me: Sure thing, can do this for $A, that for $B, and the other thing for $C, so $X total. Can have it done by then end of tomorrow if you want me to proceed.9:57am, Client: Sounds good, please proceed.9:59am, Me: On it, will drop you an email when it’s done. Please pull through!

The analogy is crude, but the feeling is dead on: I get the experience of being a drive-thru coding house, ready to take your order and deliver ultra-quick turnaround times. Of course I request a phone call to clarify in case this, that, or the other thing aren’t entirely clear, and I maintain my promise that I’m not done until they love it. These two practices ensure that with speed we are not sacrificing clarity and quality of the end result.

For clients with whom I’ve completed a major contract, I have no problem putting on-demand programming tasks and mini-projects on a tab, and billing whenever it makes sense to do so. My trust is their convenience. In return, my clients get ultra-responsive service which helps them mold and evolve the application that runs critical (or all) aspects of their business without the hassle of formalities.

“We’re launching tomorrow and our development team fell through. Can you get $CRAZYPROJECT done by 2pm tomorrow?” “No problem”.

The only issue with that is I’ve had client companies take *longer to process the paperwork to authorise the project* than it took to spec, develop, test and deliver.

Payment is often extremely slow in larger organisations too, which is disappointing when you’ve delivered an awesome project to an insane schedule. The trials and tribulations of the freelance developer :)