Ad

Our DNA is written in Swift
Jump

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 😀 Splash screen, some UI and minor functions 😀 (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

4 Comments »

  1. I also would have said “deliver 33% of the app”. 🙂

    As far as contracts go, many people don’t know about what in german is called “konkludentes handeln” (implied action?), meaning that after some exchange – be it oral, by email or in writing – you come to some agreement and start to work there’s a contract between you and the costumer in effect. It doesn’t have to be written down although that makes it a lot easier to proove things in court.

    http://de.wikipedia.org/wiki/Vertrag#Formerfordernisse

    If you can not come to a mutual agreement the best thing is instead to keep your work, or even offer it for sale to others. That is not only your best line of defence and i guess it may sometimes be enough leverage to get your money.

  2. I don’t agree with everyone saying ‘just release 33% of the app’. That’s putting all responsibility with the client. You as a contractor may have left a lot of unclarity, since you didn’t have the regular procedures in place (up-front requirements document, standard contract, first payment etc). I’d say you learn here, take your hit and move on.

    By the way, I’d advise for iPhone projects to always get 100% paid BEFORE submitting to the AppStore. One in twenty app submissions gets denied by Apple. You do not want to carry that risk. Your client should carry it, since he’s the entrepreneur. Of course, if the situation requires something different, then let it reflect in the contract.

  3. Being in another line of work but with many of the same concerns, I make sure on new customers (ones I have had no relationship with or history)they sign an agreement and I get enough to cover the expenses. I make sure everything is spelled out on what belongs to who and what it will cost. It is a great way to learn what and who you are working with before you get too deep. Having worked with you, I know that you communicate very well on what is going to be done (and even more!), but unfortunately sometimes others are not so focused (polite enough?).