Silly Billing & Dysfunctional Cashflow

If you’ve ever been a freelance developer, or have operated a dev shop or web agency then you know this story.

You meet a new client, they want you to build them an app. Based on some kind of agreed spec, you give them a price, ask for a deposit, and agree to milestones and deliverables, tied to the percentages of the remainder. All goes well until some time around the latter third of the project. The client starts asking for changes to the agreed spec. They start small, and innocent enough, but soon start to add up, and become bigger changes.

“It’s just a quick change”, they say. But it never is.

Soon enough, you’re eating into whatever profit you might have made on this project, or even worse, you get to a situation where you’re effectively handing your client cash.

I’ve been building stuff, either on my own or in teams, since the late 1990's. A good decade of that time was spent in agency or devshop-land, where clients were billed by the hour, and usually under a fixed budget. After many years working for others who used this billing model, I set out as a freelancer in 2007. I had seen this model fail so many times, yet I knew no other way of billing. I somehow thought it’d be different this time, because I was in charge.

I was wrong.

I operated like this for a full year, before teaming up with a few other people to start our own devshop. I had been burned by this model while freelancing. But this time it would be different, because we were now a company, and we were “legitimate”.

Nope. Wrong again.

By early 2010, things were pretty fucked up. We had loads of work on, but we were effectively broke. We had no shortage of new projects, but couldn’t seem to shift existing ones. Ones that should have been finished weeks (or in one case, months) before. But we still had bills and six salaries to pay. So we said yes to new work, and took deposits, as a stop-gap in our dysfunctional cashflow.

As you can imagine, this became unsustainable. I spent many, many nights lying awake wondering how I was going to pay my team, never mind myself. Each passing month became a struggle. We were all literally living hand-to-mouth, digging a deeper and deeper hole for ourselves.

We had founded our devshop with a long term goal of building products, bootstrapped by consultancy, and eventually generating enough income to focus only on product. The 37signals dream. Yet we were nearly three years at this, we had a handful of half-started products, and a loads of completed-but-not-profitable client projects under our belt. And debt. Lots and lots of debt.

We were no where near realising our goal, and each project that we took on made matters worse.

Something had to change.

It sounds stupid, but we had never looked at the process by which we billed, and I never considered that this might be the root of the problem. I tended to put it down to the project, the client, our relationship… even me and the team. Was there something we could do better with how we developed software?

No. It was, and always had been the fact that we gave a fixed price, used waterfall methods, and tied payments to waterfall milestones.

The more I thought about this, the more I realised that how we billed affected everything we did. Writing software is a creative, complex process, and building software that solves a specific problem for our clients, based on what they said they wanted, is really the crux.

What our clients wanted, wasn’t what they needed. They would suddenly realise this in the latter stages of the project. This is what would cause them to start making changes to the agreed spec. This is what would cause them to withhold payment and break the terms of our engagement.

But I couldn’t blame them for that. We hadn’t helped them to understand the difference between what they wanted and what they needed. We hadn’t given them the tools to be able to work with that approach.

So, here’s what we did.

We educated each new client on around taking a Minimum Viable Product approach, and some of the basics of agile development. My sales meetings would consist of me giving them an A4 page and asking them to describe:

“the least amount of features, that can be built in the least amount of time, for the least amount of cash, that someone will pay you for”

We moved from giving fixed prices and fixed timelines and we adopted a better ticketing system. We would operate in two week sprints, and made the client the project owner. We allowed them to set priority, with some gentle guidance from us. We gave them direct access to each developer working on their project. Ultimately, we gave them insight and control, and with that came trust.

Most importantly, for us, we told them that we required payment in advance of each sprint. I’ll be honest, that bit took a bit of convincing. But getting them to agree to a trial sprint usually helped them get past it, once they were empowered to be more involved in the day-to-day.

In fact, in nearly all cases, we found that the projects ran longer than everyone expected. Not because we were slow to develop, but because the client could see the process was working. They could see where their money was going, and the new level of involvement meant they were more emotionally connected to the project than ever before.

It wasn’t uncommon for clients to come to me and say something like:

I was going to wait another six months before building these features, but based on the feedback I’ve gotten from some customers, I’ve gotten more budget and we’re going to go ahead and develop them now.

This was a win-win for everyone. The client got the software that their customers wanted and would pay them for, and our cashflow became predictable.

Within one or two months of working with this new model, we knew we were on to something. We were finally getting out of debt, and even better, we could afford to start to think about where we really wanted to be: developing our own products.

I’d like to think that the world of software development (of all types) has moved on somewhat since 2010. The thought of working in a team with no version control, no product management process, no continuous integration, no testing is alien to me.

But if the conversations I’ve had with regular attendees of the many conferences I’ve been to over the past few years is anything to go by, there are still plenty of devshops, consultancies, and agencies operating this way.

We work in a world where we are constantly up-skilling, working with new tools, and we are always learning how to code better / faster / more secure.

Yet the business side of the house is still stuck in the 1990's.

In late 2010, we started working on a product called Orchestra. We bootstrapped the development of it from consulting. Our cashflow had become so well tuned that we could afford to put me and one of my co-founders to work full time on releasing Orchestra.

Less than a year later, Orchestra was acquired. But that’s another story.