If you like my tutorials, you will love my book . It is chockful of advanced programming techniques and the only comprehensive barcode reference for serious iOS developers.
Our DNA is written in Objective-C

How to deal with contracting customers who won't pay

If you do a bit of contracting besides or publishing your own apps then you will have to deal with a wide spectrum of human beings. Some appreciate every tiny tidbit of love you put into their apps. Some of the more entrepreneurial kind will constantly come with new ideas but always assume that those where part of the initial agreement.

I’ve had an encounter with an illustrious specimen of the second kind and so I thought it would be therapeutic for my hurt pride to ask the tweeting community about their opinion. Here are the responses for a view of what other iPhone developers generally think about this topic. I got a big number of responses which for the most part contain good food for thought.

“What would you do as a iphone-dev-biz in this situation: End of project customer says that he only ever agreed to pay 33% of your cost.”

Look over the contract. If there wasn’t one, or it wasn’t good enough, never make that mistake again. (iradel)

Give him 33% of the code :D Splash screen, some UI and minor functions :D (crasholo)

I know this kind of problems man… email me if you want to talk more about it. (micheleaiello)

Have you already delivered the source code? If yes, there isn’t much you can do. Maybe warn other developers about the scammer. (asandroq)

Don’t release the work until he pays in full. If he doesn’t then either sell the app to his competitor or release it yourself. (avalore)

If there is a contract about the payment: talk to your lawyer , if not here is your lesson for today. (thkl)

Put everything in writing. Lesson learned if you gave already delivered your product. (drmiller)

if you can afford to then do not deliver the project to the customer is willing to pay. You do not want to set a precedent. (darrensi)

deliver 33% of the app! (lordugg)

keep the source code. Tell the world. Also, structure your billing to avoid this situation: % up front, % throughout project, final amount on source code delivery. (dunk)

Sue;ignore;negotiate;withhold source; sell source; create competing product; I would choose no. 3 or 2; The others = bad karma. (wuf810)

Since a couple of  people responding also mentioned source code as the ultimate hostage I asked a follow up question because I felt that the implicit ownership of the source is even less clear.

Do you generally assume that you will hand over the source for iPhone apps? Or take the users dev account credential and submit bin?

I would say both. (Reversity)

I never hand over the source for my apps (NJDevilfan26)

depends on what the agreement was – if you agree the the client will own all rights to app, they’d get the source. (stuartcarnie)

me personally would get them to change there dev password upload bin then they can change it back. Unless otherwise agreed (Jonn4y)

Hand over the source. (pearapps)

The client owns the source always. Hence our “confusion” when we starting working together. Always best to get all agreed up front (wuf810)

Case by case basis, most people prefer the 2nd (less work for them) I reserve the right to use the source in other projects though (jhalickman)

i think it’s standard that the costumer will want to have the app source code but your own costum libraries can/should be a binary (gaminghorror)

From boiling down the essence of my experiences and the responses to my questions I put together the following

iPhone App Contracting Best Practises:

  • Have a written agreement (aka “contract” of sorts) upfront about: agreed features (with little room for “interpretation”), estimated hours, price. Estimate high if the customer wants a fixed price.
  • You should also note who owns the source. Obviously most customers will want to own it. Then you will want to reserve the right to re-use utility classes or generic UI element code in your own projects.
  • Get some money at project start to secure customer “buy-in”. Usual are either 50% at start and 50% at end or thirds where the middle portion comes at some milestone.
  • If customer alludes to some new features being part of the original agreement, then be strong and say NO.
  • Send the customer a feature extension offer mentioning the new things, needed time and that this will be charged additionally. The customer needs to agree in reply. Put this agreement into the project documentation so that you can refer to it later
  • Depending on what your preference for the source code is: if you agree to hand it over in the first agreement then you will do so, but only after full payment.
  • And if you did not follow the above advice and are now facing a customer who insists on a historical amount for the original feature set, then your final option is to prepare yourself to walk away from the project. “I keep my app. You keep your money”. More often than not this will spark a sudden burst of flexibility in your customer.

UPDATE: Nuggets of wisdom that came in after I published this post:

I have an agreement that guarantees a payment on milestones or schedule, and a paid deposit signifies agreement to those terms. (dylanrw)

Unfortunately even iPhone app development can be a hard business at times, especially if you get customers who are used to driving a very hard bargain. I hope that this post is as enlightening to you as it was therapeutic to me. Let’s hope we get smarter with every project we conclude.

Categories: Administrative

%d bloggers like this: