What are the Limits of a Contract?

[981eb40c]

Hi there,

I have been freelancing as a developer for about 2 weeks now, but have already spotted a problem with my current work system especially as it pertains to fixed-price contracts.

I usually find that the contracts I have signed thus far are quite vague e.g. "write a program for me that can search a property website and find listings that match my particular criteria and save them to a CSV file so I can look them up later". Okay, so I chat with the client and get a bit more information and then proceed to write a program that does what the contract asks for at least as I understand it.

I'll send the work to the client and they'll request a few changes. Fair enough, I am happy to do so. The problem begins when the client keeps on requesting more and more changes from me sometimes over the course of several days during which they have been using my program. Sometimes I am asked to set up the software on one computer and then later asked to set it up on another computer. Or the client suddenly changes the domain of their webserver a couple of days after I submit the code and the program I wrote breaks so I have to fix it... If it is a legitimate bug fix, I understand, but I find this is usually not the case. The requests are usually improvements or modifications. It seems like the client can keep me on indefinitely.

Where do I draw the line? How much work am I reasonably expected to do and how far beyond the contract should I go? Do I need to stipulate in the contract exactly how many revisions of the work I will allow? Or do I need to anticipate these kinds of scenarios and judge the pay of the job with this in mind? I do not want to rush into disputes, and of course, I want to allow for some leniency, but at the same time, I certainly do not want to be trapped doing work that I feel I did not agree to and feel that I am not being paid fairly for.

From a beginner, looking for advice from the wisdom of the community.

Best,

Jason

[87511b5f]

Although we belong to different fields but I hope this help. I'm a freelance artist, when I talk to clients about payment, I usually set up a number of changes I will make for them in my head. If I was asked for more changes than that number, I will tell the client "I reached the limit of revise I can make for you. If I keep doing this, the average hourly payment I received for this job will go under the minimum wage level, and I will be doing jobs at a loss. I am willing to keep make changes, but you will have to pay me extra." Usually clients are ok with that, either pay you extra or giveup.

[mtngigi]

You draw the line right at the very beginning, when you're putting your bid together. That is where you state how many revisions (if any) your bid includes. That any work over and above what was agreed upon will incur extra milestones, more hours approved, etc.

[richard_wein]

Generally the best option for software development is to work on an hourly contract. That's what I mostly do now. But I appreciate that it may be difficult to get clients to give you an hourly contract when you're new to Upwork. When I was getting started I felt I had to offer fixed price contracts. Now that I'm getting plenty of work I can afford to be more choosy, and I'll only do fixed price on very small and well defined jobs.

One advantage of doing hourly jobs is that it should help to weed out the cheapskate clients who try to take unfair advantage of a fixed price contact. But actually, I've been lucky and haven't had any of those. Almost all my clients have been great.

[kinector]

I do value-based fixed-price deals for all development work and guarantee satisfaction and 0 bugs from the start. It is very easy to get good contracts with good clients.

For keeping myself out of never-ending projects, I use very simple tricks:

1) I always leave some 20% margin for unspecified work and that is always a built-in part of every deal. So very often I get more cash than I was actually aiming for.

2) In all proposals, I don't only list the work to be done, I also list every big thing that is out-of-scope that comes with a mention that they need a separate quotation which could be discussed later.

So far this has worked really well the past 5 years on this platform.

Many times my contract gets extended with more well-paid milestones. 🙂

All we ever need is good expectation management and clear communication before the project starts. That keeps you covered.

That being said, there will be always some squeezer who appears decent but once the contract starts the tone switches to very demanding. This is the part I'm still working to figure out how to filter...

[wlyonsatl]

For the kind of work I do, Mikko's approach is spot on.

During contract negotiations, you have to clearly define what is and what is not included in your work on each project. In some ways and with some clients (the inexperienced, as well as the scope creep types), defining clearly upfront what is NOT going to be included in the work product is indispensable when you get the "oh, I need just one more thing" message from a client.

Avoiding unpaid scope creep is one reason I almost never do fixed price projects for new clients.

Good luck!

[kinector]

Will, may I ask, how do you do value-based pricing with an hourly-pair deal? Very curious to learn...

[981eb40c]

Hi all, 

Thank you so much for all the useful advice, I really appreciate it. Moving forward, I will definitely try to be clearer upfront about what is and what is not included in the contract. However, I think it will still take me a bit of time to learn how to do this properly especially since, at the moment, all my projects are quite small so that even a little bit of scope-creep feels large relative to the project as a whole and my clients do not always communicate very well with me. 

I am still curious to hear more opinions on the idea of "revisions". Scope-creep is one thing, but sometimes I feel that the additional work requested by a client is not necessarily a broadening of the scope of the project, but rather just a series of miscellaneous changes to the existing work, but it can still take up just as much of my time. I suppose, again, the key is communication and determining exactly what the client wants before the work is done in order to minimize the number of revisions further down the road. But this is sometimes easier said than done and the client could sill change their mind at a later point...

@Mikko, not sure I totally understand this 20% margin. Sounds like a good idea, but how do you practically implement that? Also, do you limit the number of revisions you will do for fixed-price contracts?

Best,

Jason

[kinector]

There's no way to quantify everything.

We do business with people. So all you need to know is what their real problem is and what it takes to solve it.

Then add some extra for unexpected things.

Anyway, if your projects are small and count in mere hours to complete, the amount of discussion needed for each project might exceed the amount of actual work.

No point in doing that kind of business. If your process is risky by nature, it will be risky business.

But I think you'll do fine, don't over-analyze it. 👍

All the best!

[richard_wein]

I'd be interested to hear from any software developers who specify a maximum number of "revisions". The people who suggest this tend to be writers, translators and artists. I'm not sure the idea makes as much sense for software development, though it might work. I think you'd have to make clear that a completely new feature does not qualify as a revision.

[kinector]

Yeah Richard, it's hard to go that way to limit iterations on software. I do until it is done. 0 bugs, all features promised... also I keep a healthy 20% for all kinds of unexpected small adjustments so I never put a price tag on a project for just those features requested.

Particularly if the client is a designer or otherwise I can expect that not all can be discussed upfront.

To me, it's about your own spec'ing, communication, and expectation management skills. Experience definitely helps.

A bit easier estimate and agree if you deliver software for other software guys.

[kinector]

Jason, let me add another perspective.

As we do business with people using a common language and language being always somewhat ambiguous by nature, there is no way to describe every single thing that needs to be done in any project. Even simple ones are ambiguous.

It's like coding. The only perfectly descriptive fully comprehensive spec of a coding job is the code itself. 😁

So, your core skill is always communication and expectation management. Of it is not that now, don't worry, it can be learned. Also, there are professionals who can teach you how to ace in this!

Everytime I realize I have a different opinion than my client about what should be done, I try to jump on a video call ASAP to understand and manage the expectations.

Also, I don't start projects without seeing my client eye to eye so I can "read" them properly.

This has saved me from countless troubles! 😉

[alexandernovikov]

1. Charge a lot, lot more to accomodate a reasonable amount of this (and probably also the increased time you will spend looking for jobs)

2. Become Top Rated so in few cases when the client is utterly unreasonable, you can tell them to GTFO and delete the contract from history

3. Charging a lot more will also have you work with different kind of clients - those who value people's time - so you will have a lot less of that.

[kinector]

Exactly, Alexander. 😉