Lessons Learned by Being the Client

I ran a web development consultancy from mid-2001 through to early 2013. By 2006, the company I had started alone was busy enough for my husband, Drew McLellan, to join the business full time. The vast majority of our work was as an outsourced team, developing projects for design agencies. But now, in 2014, we find ourselves on the other side of the client/developer relationship.

We launched our first product, Perch, as a side project of that business. It’s now the whole of what we do, yet we have managed to remain a team of two by making use of freelancers and other agencies. At first we only outsourced design, but increasingly we are also using outside help for development.

Here are some of the things I have learned by being the client.

Give regular progress updates#section2

I always felt we were good at communicating with our clients. We asked questions and updated the staging version of the project regularly. And so, when clients would ask for an update, I would feel irritated and pestered. We felt as if we were constantly communicating with them and we were rarely late delivering something, so I assumed that the client would understand that if we didn’t mention there was a problem, everything was running on time.

As the client, I now know that even if I can see code being committed and the developer is talking to us, I don’t always get a sense of whether they are on track or not. I’ve seen how other business milestones may depend on the completion of an outsourced project. For example, you might buy advertising to go live at the same time that a planned feature launches. If the ad buy has to be booked in advance, but the project runs late, that advertising spend will have been wasted. Due to the stress of the unknown and fear of losing out financially, it is easy to end up being that client who seems to be constantly asking if the work is completed.

Of course when you are providing a service it is important that you do what you say you will do, in the time you said it could be done in. However, in addition to that basic requirement, building in regular status updates helps your client to plan things that rely on the work you are doing to be completed. It stops the constant is-it-done-yet? type emails and phone calls.

Explain what to review#section3

We often used to grumble that clients never looked over or tested any of the work we had done, although we deployed work to staging servers and made it available for review as often as possible. Looking back, I think we made an assumption that not only would the client have the time to immediately look at everything we had deployed, but would understand for themselves the progress.

We’re working with a developer currently who uses Trello not just to organize tasks but as a way for us, his client, to see what he is working on and where he is at. I can take a look at Trello at any point and see that a certain feature is being worked on, or has been moved to done. I can then go take a look on the staging version and I know what I’m looking for.

Even if your client is able to see your commits or updates to a system, give them a way to know which bits they should be looking at at any one time. This will save your client wasting their time pointing out things that you haven’t addressed yet, and also help them feel part of your progress.

In addition to gaining a new insight into what really makes for great client and developer communication, I’ve discovered other ways in which freelancers can really contribute to the businesses they do work for.

Make costs foreseeable#section4

As a business owner with a product, there are many things that I would love to find help with. But hiring a consultant at an hourly rate when I don’t fully understand the scope of the task at hand is a bit scary. What if it costs far more than I imagined, or what if what I really need is ongoing support?

If you can make your consultancy services more product-like in terms of how you market them, you can make life a lot simpler for business owners who aren’t sure what work needs doing and whether it is in their budget. This approach has been termed “productized consulting” and involves packaging up services that typically would be completed on an hourly rate into fixed-price—one-off or monthly—purchases.

For examples of how some companies have turned their freelance services into products, see Brennan Dunn’s post 3 Great Examples of Productized Consulting Services.

Put business aims before perfection#section5

Possibly the biggest thing I have learned from being the client is that often “good enough” is enough. As a developer, I wanted the time to do a really amazing job, yet often felt that we were being asked to cut corners and to not develop the perfect solution we knew we could come up with. As the client, though, I know I have to make the decision to ship. I need to be the person who says, this will do for now.

I’d still love everything to be perfect. Sometimes, however, it is more important to get something out there, even if that means accepting slightly rough edges. As an example, we recently rebuilt the internal system that allows people to pay for our product and be issued with a license. We moved away from a legacy PSP to Stripe and made other changes that are going to enable things we have planned for the future. We shipped this with the most rudimentary reporting dashboard, and with a number of tasks that could be automated via various APIs not yet finished. For the business and our customers, the important thing was the parts they interact with; the rough edges were only a problem to us, and we can tidy up as we go along.

To be able to work in this way with freelancers requires a change in mindset and in approach to defining and quoting for jobs. One of the reasons we hated feeling that we were shipping things with rough edges was because we were often contracted just to build a particular product. Our job ended when the project launched; we knew that whatever state the project launched in would often be the state in which it stayed. Now that we hire developers, we try to find people who are interested in an ongoing relationship. We hope this relationship helps them feel confident that when we say we need to ship something they have worked on, it’s not the end of their work on it.

If I were writing code for other people now, I think I would foster these types of relationships far more than we did then. Instead of railing against the client who wanted to ship something I felt was not ready, I would try to help them to get to a shipping point that didn’t also mean we hand over the work.

Invoicing: the relationship killer#section6

Many of the issues outlined above were exacerbated by the agency model of building, shipping, and invoicing for projects. Since our final invoice couldn’t be sent in until the work was complete, clients often saw that invoice as a way to hold us over a barrel until some element (that perhaps wasn’t initially quoted for) was done. It’s a pretty toxic way to work if you want to create great ongoing relationships.

Many of our freelancers now bill weekly or every two weeks when they are working on things for us. I really like that as a model. If the scope creeps and the work takes longer, we simply pay for more days of work—potentially with a delay if our contractor has booked some other work in—but the entire job doesn’t need renegotiating. There are no awkward discussions about whether they are allowed to submit an invoice.

There is a huge imbalance in many client/developer relationships. The client often wields power in the shape of owing the developer money that won’t be paid until hoops have been jumped through. The developer may be privy to, and often may be the only person who fully understands, a large part of the client’s business. The developer can feel as if their work is not being valued, while the client feels that the developer is spending far too much time on unimportant things.

Of course there are people who will treat developers badly no matter how hard they work and how well they communicate. However, I think that many relationships become strained because of the lack of balance created by the agency billing model.

Better together#section7

Ultimately the best client/developer relationships should be mutually beneficial; two businesses working together for the benefit of both, understanding each others’ communication needs and business aims. It sounds like perfect sense, and it is—but it’s only by being the client that I have really come to appreciate that.