In general, developers are a lot more flexible on price for projects they really want to work on, and a lot less flexible when they’ll have to grit their teeth for the money.

Web developers are like anyone else: they love some projects that come through the door, and suffer their way through others. What many clients don’t realize is that this makes its way into the prices developers quote for projects.

In general, you’ll find that developers are a lot more flexible on price for projects they really want to work on, and a lot less flexible when they’ll have to grit their teeth for the money. Believe it or not, many developers even have a formal surcharge for “I don’t want to do this” work—which gets passed to the potential client as a higher overall bid. Conversely, many developers will compromise on price for projects that are very attractive for other reasons. If you don’t believe this, check out the dozens of massive open-source projects across the web: projects like WordPress, Drupal, PHP, and Apache (to randomly name a few) attract thousands of hours of work from the best developers in the world, for free.

Sadly, you’re probably still going to have to pay your developer. But if you know what developers love and what they loathe, you can try to make your project as attractive as possible to them. The end result (besides the secondary effects of having a much better experience and a much better product) is very likely to be money in your pocket.

What Developers Love

The Opportunity to Learn.

Most developers will jump at projects that offer the chance to expand their knowledge.

Very few developers, and probably no very good ones, got in it for the money. For the most part, they got in it because they love building things—software with amazing powers, that anyone in the whole world can see and use. Relatedly, they love learning how to build things: expanding both their conceptual knowledge of programming, and the specific toolkit they’re comfortable with.

So most developers will jump at projects that offer the chance to expand their knowledge: to learn about a powerful new programming language, or a new—more robust, flexible, elegant—way to use their existing skills. If your project is an otherwise great idea, but contains several “I’m not sure if it’s possible to…” statements, developers will likely find it really interesting. (Although, unfortunately, complex problems also require developers who are better and hence more expensive.)

Not every project can use interesting technologies; in fact, you have to watch developers on this, because they’ll sometimes try to steer you toward bleeding-edge technologies that your project doesn’t need. But even if what you need is a totally vanilla site, you can at least encourage and listen to your developer’s suggestions for approaching the project. Getting to build a simple site the right way will at least engage the love of problem-solving that makes your developer tick.

Low Overhead.

Overhead is a developer’s kryptonite.

Overhead is a developer’s kryptonite. Initial consultations, follow-up emails, project proposals, preliminary estimates, conference calls, site visits… All these take time out of a developer’s work week without bringing in any money, diluting his or her earning potential.

So developers covet projects that are almost entirely billable work. This could take several forms:

• Large projects
• Small projects with virtually no overhead
• Repeat work with little additional overhead between projects

If you can offer any of these to your developer, he or she will really perk up. In any case, if you can show that you’re making an effort to streamline the process, it’ll be much appreciated and will make your product a lot more attractive.

The Chance to Help.

Does your project’s mission make people happy?

Most developers like projects that really make a difference in the world. Your developer’s specific passions may be punishingly technical (“web server architecture should always be free and open-source!”), but he or she will most likely recognize a project with a great mission, and brighten at the opportunity to help.

Your project doesn’t have to be a nonprofit: working for a for-profit with passionate people and a great mission can be one of the most gratifying experiences as a developer. The distinction is as simple as this: does your project’s mission make people happy (family-run bakery, local bike shop, after-school children’s dance company) or unhappy (personal injury attorney, cigarette company, automated toll processing center)? If the former, and if you’re enthusiastic, warm, and passionate, your developer is more likely to value the project in non-financial terms.

Great Clients.

For your developer, the way you come across as a client is the single strongest predictor of his or her experience during the project.

For your developer, the way you come across as a client is the single strongest predictor of his or her experience during the project. The following are great traits to carry around, and will make developers want to work with you:

Nice!

If your developer finds himself or herself smiling after first hanging up the phone with you, it can have a big impact on how attractive the project looks. Try to put your best foot forward.

Smart, or at least thoughtful

By nature and by training, developers respect clarity and specificity of vision. If you happen to have a lot of raw intelligence, you may be able to bend developers to your will by dazzling them—but I wouldn’t bother trying unless you’re already supremely confident (a Jeff Bezos or Elon Musk type). However, if you’ve done the best you can to think through your project, and you can clearly and confidently present both what you know and what you don’t know, your developer will really appreciate it and see the project as potentially workable.

Focused on needs, not features, and willing to listen

A good developer wants to partner with you to find digital solutions to your most pressing problems. You should know what you need and why you need it, and you should be willing to listen to (and, obviously, intelligently question and push back on) your developer’s ideas about how to get you there. If you set up your relationship properly from the outset, it’ll give your developer reason for optimism.

What Developers Don’t Love (and Remedies for Each)

Rote or Trivial Work.

No good developer likes using his or her skills in silly ways, or for silly things.

No good developer likes using his or her skills in silly ways, or for silly things. One example is propping up inefficiencies—for example, manually copy-pasting a code snippet into each of a hundred webpages. Many developers also don’t like doing light technical support, like Gmail password retrieval. Developers will charge as much as they can for this kind of work, because they’re just as happy if you don’t end up hiring them.

Suggestions:

Engage your developer’s intelligence to find better solutions, not just iterate on inefficient ones. This will probably be the best solution for you long-term anyway.

Projects that Seem Ill-Conceived.

Good developers want to use their knowledge to help you meet your goals.

Good web developers also wince when they’re asked to help on projects that seem very unlikely to succeed, because good developers are partners in strategy: they want to use their knowledge to help you meet your goals. If they start to look for details about your model (“Interesting idea. What’s your marketing strategy? Who are your ideal customers, and have they responded positively to the idea?”), and you reply that you’re just interested in getting the website up and running, they may agree to help but they’ll likely charge you their aggravation rates.

Suggestions:

You don’t have to “pitch” to your developers, but showing that you’ll at least consider their questions and ideas will give them confidence in you personally, and that can translate into confidence about your ability to execute your project. Also, if your idea is brand new, developers can be one of your absolute best sources of real-world feedback: since “getting a website” is a first step for many new projects, most developers work with startups and other new ideas constantly. Carefully considering their input can be a great idea, for your own sake.

Morally Compromised Projects.

Most developers don’t like using their knowledge to hurt people.

Most developers don’t like using their knowledge to hurt people—for example, working on projects that aim to sell defective products to gullible consumers. Many developers will build you a site like this for the right price, but there’s a good chance you’ll take a financial penalty.

Suggestions:

If you’re working on a project that some people might find offensive based on their tastes or views—perhaps a political campaign—then mention the issue (“People often feel pretty strongly about political candidates; do you have any misgivings about the project?”). This ought to create the ground for a comfortable working relationship. If what you’re doing is out-and-out immoral (you’re manipulating or scamming people), you should just stop doing it.

Difficult Clients.

After a while, developers get a sense for people who are going to be very difficult to work with. Some telltale signs include:

Initial lapses in competence.

If you’re harried, disorganized, and unreliable before a project, it’s very likely that you’ll be that way during the project, and your developer is likely to price this in.

Suggestions: Try to put your best foot forward—like you would with any other professional relationship you were working to start.

Complaints about previous developers.

Clients quite commonly introduce themselves with a stream of abuse at the developer they just fired. Maybe your side of the story is all there is—but it’s impossible to tell, and your developer is likely to wonder if he or she will be the next person you tell stories about.

Suggestions: Unless the horror story is directly necessary to explain the current state of the project, it’s best to start your new relationship as a clean slate.

Features, not needs, and unwilling to listen.

If you try to lead with a set of “needed features” first, and most of them don’t make sense or can be done much better some other way, and you can’t hear this feedback, it’s gloomy times ahead for your developer. Good developers partner with clients to identify strategic needs—not lists of favorite technologies—and then implement solutions that meet those needs. Just installing features to no good end is dispiriting work.

Suggestions: Come to your developer with core needs, not features. Read this blog post for more.

Fast-talking and demanding.

Some clients need a website built urgently to capture an amazing idea that will make everybody a ton of money—but we have to start right now. This sort of mania generally signals a badly thought-through idea and an unreliable client.

Suggestions: Breathe! Your excitement is great, but you’ll have to get practical to execute it properly. The right developer can often help immensely to bring your vision about, but you have to be willing to put the relationship on firm, mutual footing.

Multiple stakeholders with conflicting visions.

To a developer, few things are more frustrating than to make a great relationship and a great action plan with one person in an organization, then have the entire project disappear for months while the proposal gets muddled up by a variety of loosely affiliated stakeholders.

Suggestions: Speak with one voice. If possible, assign one person to see the project to completion, set clear needs and a clear vision, and minimize the red tape needed for the person to execute.

In Conclusion…

If you know how to make your web development project attractive to developers, you’ll attract more good developers, and they’ll likely be willing to take on the project for less money. At the very least, you’ll avoid being penalized as a suspected source of migraines down the road.

What do you think? If you’d like to add to this list, please post in the comments below. And, as always, please share with anyone you think could benefit!

Image Credits: pmarkham