Over a million developers have joined DZone.

Clients: How to Work Well With a Mobile App Consultant and Get a Low Price

DZone 's Guide to

Clients: How to Work Well With a Mobile App Consultant and Get a Low Price

· Mobile Zone ·
Free Resource

My experience as a technical consultant has taught me what the best projects to pursue are, how to smell a rat, and how to come up with the highest bid that wins. I don’t know, maybe I bid low, or too high, who knows, but I’ve got a great conversion rate on getting contracts signed so I’d like to think I’m doing a good job with it.

But why just share my insight with other developers? What about the other side of the coin? So, all you potential clients and entrepreneurs out there, here are some tips for getting the best fixed rate on a project from a consultant.

Introduce Yourself and Your Idea Well

I get a fair amount of email from prospective clients, that I’ve never worked with before, who’ve found me on Google. Sometimes they have a contract in mind, and other times it’s a partnership offer from some kid who thinks they can make a million-dollar flashlight app. For every email I get, I have to decide if I will potentially devote a handful of hours to phone calls, requirements gathering and ultimately a formal proposal. Every time I bark up the wrong tree, I lose a half-day or more of work time that will set me back on my current projects — so I have to choose wisely.

My advice if you’re looking for an iOS consultant is, when you write to that developer, take the time to introduce yourself, explain clearly what you’re looking for, and if you are company-backed — say so. This is important. When you tell me you are a manager at a company looking to build a project, you get instant credibility as a good lead. Is that unfair to independent venturists, yeah probably. That’s business, however, and if you have the advantage of a corporate backing then by all means flaunt it.

One of my best clients almost never was because I initially didn’t even respond to his first inquiry. Here’s the first message I ever got from him:

Hi -

I have an idea for an app I’d like to make what are our next steps?

- Some Guy I Never Heard Of

Ask yourself, how much time would you take from your work day to chase this lead down? I didn’t even bother. It took future emails and even then, when I had to cancel a chat due to the flu, I totally forgot about the person afterwards because in my mind it was likely never going to amount to anything. Boy was I wrong. But was it my fault? Hardly.

What he had failed to realize is that I get many messages that look like this from clients who aren’t looking to pay for work. In fact, the email is borderline spam. :-) Now, assuming that a developer does respond to this kind of message, you must remember that it really is true: first impressions matter. Over the course of correspondences, that developer will remember how things started and carry a shred of distrust. Perhaps a shard! So OK, with this particular client, I didn’t fully trust them until we first met some weeks later. Without trust, a developer may up their bid to cover the risk involved with that lack of trust and you may not even realize it.

It matters that much, yet only takes 5 minutes to write a solid opening correspondence. Put in the effort and it will be well worth it.

Know What You Want

This is a biggie. When a customer comes to me with a project in mind the first thing I do, of course, is ask about their idea (generally under NDA). Most customers have an idea, but a handful don’t. In many cases, that client is looking to me for guidance. (I am a consultant after all.)

But is that optimal? I can say that the more unsure the prospective client seems to be about what they want to build, the higher my bid will be. Why? Simple:

  • The more unsure a client is, the more change will be introduced later. The more change, the more net work.
  • It’s easy to envision that I’ll be spending many hours working with the client to nail down their requirements.
  • All of this produces risk that my bid will end up being too low. To be sure I don’t lose money on the deal, the bid must be increased to offset said risk.

I once had a client who I spent about 7 months with exchanging phone calls, emails, IM’s and what have you answering questions about what’s possible on iPad and working with them to formulate their requirements. I took calls on the road, while walking to the train, at work…everywhere. I even wrote a little demo app for them to show their own client. In total, I probably spent 12 hours of my time on all of this before any phase of the project had even begun. Clients like this do themselves a disservice because as a developer it’s easy to see huge warning flags in this behavior.

Contrast this with the clients I come across who have requirements, and even wireframes, in hand. These are the clients that clearly articulate what they want and they just need you to build it. I can confidently estimate the time needed to do it and am able to give a confident fixed price. Most importantly, that price is generally coming out lower than normal because I don’t feel pressured to charge for risk and perceived change. In addition, I don’t want to lose out to another consultant: I *want* this client.

My advice is to be these clients.

Be As Responsive As Possible

Finally, your developer is in butt-in-seat mode and product is being built. You’ve taken all the advice above to heart and have a solid deal signed and now you just have to wait for the work to be delivered. Alas, you’re not done! Fixed-bid contracts (as well as hourly) can crumble right underneath you if you hang the developer out to dry. It’s up to you to prevent that.

Let’s take a fixed-bid contract to start. Let’s say you agree to a $20,000 contract with the developer. With that, the developer has an understanding of the work needed to be done and the timeframe. Now let’s say that the project progresses and your developer is pinging you with questions and clarifications on what the app should do. If you aren’t responsive, the developer is liable to be (A) stuck or worse (B) continuing forward with an incorrect understanding.

You *have* to be responsible. No, responding within a day is not sufficient. Within an *hour* is. This might be inconvenient at times, but the quality of your app will suffer if you push the developer off. And it gets worse…if that developer is constantly having to wait a day or two to hear back from you, they will get irritated because it’s likely increasing their time expectations of the product and, if they are having to do rework, it’s increasing the expected work involved. What does this mean? It means the developer, in order to avoid losing money, will cut corners that will ultimately hurt you down the road.

Even worse, the developer will stop contacting you. That may make you happy, but realize that this means the developer is unsure of what to do but is uninterested in asking you. You’re going to get the wrong thing.

Is it fair? Actually, yes. If you don’t display the care for your app your developer expects, why should they care? A lazy customer suggests to me that they don’t expect the polish I was willing to put the extra effort into. It’s a natural human reaction that if you don’t care, I don’t care. This is best described by the Broken Window Theory and you should take the time to read it as it’s incredibly eye-opening.

So care. You’ll be rewarded. :-)


To get the lowest rate, and the best product possible, you don’t have to be worried about the above if you keep the following axioms in mind:

  • Be credible.
  • Be trustworthy.
  • Be dependable.

That’s it. I can’t speak for all developers but I’m sure I am when I say that we *love* customers like this. Not only will I give my most competitive bid for these customers, I’ll prioritize them above all others because I know I can rely on them and I want their business again in the future. And the bottom line is that if you’re the client, this is what you want your developer to think.

Now that we’ve got this understanding, let’s improve the relationships we have and get to work!


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}