How to make freelance clients understand the costs of developing and maintaining mature products?

Question

I have a freelance web application project where the client requests new features every two weeks or so. I am unable to anticipate the requirements of upcoming features. So when the client requests a new feature, one of several things may happen:

1. I implement the feature with ease because it is compatible with the existing platform

2. I implement the feature with difficulty because I have to rewrite a significant portion of the platform's foundation

3. Client withdraws request because it costs too much to implement against existing platform

At the beginning of the project, for about six months, all feature requests fell under category 1) because the system was small and agile. But for the past six months, most feature implementation fell under category 2). The system is mature, forcing me to refactor and test everytime I want to add new modules. Additionally, I find myself breaking things that use to work, and fixing it (I don't get paid for this).

The client is starting to express frustration at the time and cost for me to implement new features. To them, many of the feature requests are of the same scale as the features they requested six months ago. For example, a client would ask, "If it took you 1 week to build a ticketing system last year, why does it take you 1 month to build an event registration system today? An event registration system is much simpler than a ticketing system. It should only take you 1 week!" Because of this scenario, I fear feature requests will soon land in category 3). In fact, I'm already eating a lot of the cost myself because I volunteer many hours to support the project.

The client is often shocked when I tell him honestly the time it takes to do something. The client always compares my estimates against the early months of a project. I don't think they're prepared for what it really costs to develop, maintain and support a mature web application.

When working on a salary for a full time company, managers were more receptive of my estimates and even encouraged me to pad my numbers to prepare for the unexpected. Is there a way to condition my clients to think the same way?

Can anyone offer advice on how I can continue to work on this web project without eating too much of the cost myself?

Additional info - I've only been freelancing full time for 1 year. I don't yet have the high end clients, but I'm slowly getting there. I'm getting better quality clients as time goes by.

Answer 1

Been doing the freelancing thing myself recently (different field tho), and I built into the contract two things; a) If any major (in my opinion) additions / changes were to be made to the framework, each was counted as a separate project with separate delivery requirements and costings, b) that I would provide a suitable level of documentation so that if they wern't happy with my 'estimate', they could try someone else.

I had one client try option b once; they came back fairly quickly.

Answer 2

It sounds to me like you've got some technical debt in your architecture; it's brittle with respect to change. In addition, it's not clear that you're testing at the right time. The best time to write your tests is before you write your code, letting your tests function as an executable specification for your code.

A robust architecture should facilitate change by encouraging decoupling between classes. This should limit the propagation of change as new features are added. It sounds as if you have more coupling than is healthy, but that's nearly impossible to tell without looking at the code. I'm just going by your description of the symptoms.

If this is the case, it might be worth investing some time in improving the underlying architecture. Be up front with your client that the underlying system no longer fits their requirements and that you need to take some time now so that future changes can be done faster and cheaper. It's possible that some of this is your fault -- if so, be honest about that, too. I don't think that it's unreasonable to expect the client to pick up the tab for changes to the architecture required to support their new features. If it's partially a result of inexperience, though, you may want to eat some of the cost yourself and chalk it up to a learning experience. You may want to do this anyway if you might otherwise lose the customer.

Answer 3

Take a look at these two articles.

Answer 4

Can anyone offer advice on how I can continue to work on this web project without eating too much of the cost myself?

Transparency and communication are your best tools. If your clients can't understand why something that once took a week now takes three weeks, you need to be able to explain better. Depending on the client's area of expertise, you may be able to find a metaphor that resonates with them - trying to build a Prius on a Model T frame, say, or trying to write War and Peace with a typewriter with no vowels. Don't be ashamed of your honest estimates, and don't be bullied. And share with your customer as much as they can bear about your process and the obstacles you face - you may even find that they have some worthy suggestions.

With respect to the issue of technical debt - and I agree that this is the underlying problem - TDD will take you far, as will the frequent refactoring that broad test coverage permits. Think about what design would have permitted all your changes easily - and work toward that design, incrementally, with tests and refactoring. Maybe you have to eat the costs of that, because the functionality is all already paid for. But, looking forward, include costs for refactoring in your estimates - and don't think of it as padding. Padding is (arguably) dishonest; maintaining the design of your code to accommodate future changes is an honest requirement of your work.