Devin Snipes asks:

I’ve advanced in my iOS development and have officially started work on a client project. My client has requested tons of changes since I told them the application was complete. Should I keep doing these changes or just stop. I under-charged them, made several thousand changes and also felt like I over-worked myself. How would you deal with this?

My second question is related to the somewhat ‘legal’ matters of iOS development. Do you have a standard iOS development contract that you request your clients to abide by? If so, could you send me a copy or could I look over it to get some idea as to what I should do.

Both are really good questions. (“Good question” usually means that they don’t have a simple answer)But let me attempt to go back in my own experience and give you a couple of pointers as to how I dealt with exactly the same situation and what I learned from it.

As a rule of thumb people who contract you for making an app are cheap. Cheap as in Uncle Scrooge. And they know that whoever commits to a number first, loses. That’s why they ask you for a quote knowing dead well that as a beginning programmer you are absolutely incapable of judging the true amount of work that you will put into the app. Being the kind of lottery that is the app store, these couple of hundred dollars are sort of the price for their ticket. Low cost, potentially big rewards. Buy another name this is called “business sense”. Keep costs low to have a big margin.

So they say “it’s a really simple idea, it just needs this, this and this. How soon can you have done it, for what price?” And that’s a trick question that tricks beginning developers into thinking about facts. You think “ok, these are 3 fairly simple items, maybe I can do these in x hours”, you multiply this by a rate that you feel you should be worth and that’s what you quote. Only to find that when you present the first version to the client you get a “And what about feature x? I thought it is obvious that this has to be in there as well! Without that the app is worthless”. And this goes several times back and forth until you have spend three times as much on the job as you quoted initially.

Then there’s work that you did not quote, but still need to do, because the client has no Apple account, you need to build, hand-hold the client through the submission process and the app starts getting downloads you get the crash reports. The app might be successful like in the case of my first contracting client who made $10,000 in the first month, with an app that I charged him $400 for. Or the app might crash and burn and you hear “I would have paid you more, but unfortunately the app is not selling”.

The theme of all this being: you have lots of work, but don’t get paid for it. On a tangent you might be wisening up and refuse to work any more, only to find an e-mail from your client requesting that you hand over the source code so that another developer will continue on the app.

I know this from having fallen prey to several such sharks myself. So how can you avoid being tricked like that? Developing iOS apps should be rewarding, not draining you.

Your second question goes in the right direction, but let me tell you outright that I don’t have a standard iOS development contract. You might find some on the Internet, but I fear that you suspect that if you had a written contract that this would be the magic bullet that would make it all alright for you. But it doesn’t. No contract is worth the paper it is printed on, if you don’t know what it is supposed to do. A contract is nothing but a summary of items that two parties are agreeing upon. So make up your own! You are fully capable of writing on a piece of paper “Devin Snipes and Client X are agreeing that …” and fill in what you feel is worth agreeing on.

Let me give you a list of items that I would put in there personally:

Design

I tell people: ” I am not a designer, I am a programmer”. I expect UI/UX design to be provided in form of Mockups and written functional specification. That means I want a document that describes what the app can do and essentially how you navigate between it’s functions. My strength is writing efficient code fast, it would be a waste of the client’s money if he also paid me for photoshopping some Google Images into app icons.

If you are dealing with companies then most of the time they have their own designers, you can offer to do a (chargeable) workshop with them to give them some pointers as to how to approach the UX/UI and technical stuff like what resolution images you want and that the double-resolution images should be named a certain way.

If the client cannot provide that, then I have friends and partners who can help him distill out such a spec, for a price. In either case you should only start touching code once you feel that all questions are answered and all functions are set. Unless the client wants a prototype, which is a project of its own.

Tell your client “Apple says a good app is 60% design”. This means that they can save 60% of the total app costs of they do all the design legwork before talking to you. You know, a typical designer charges around $500 for an app icon. Not because it’s the first piece of artwork that’s seen from an app. The reason for this high cost is that even a pro would work 1-2 days on it. Knowing this, how do you now feel that you promised that you would do this “quick app” in a week for the same amount that somebody else pays a designer for just the icon?

Price

If you have the strength then you should not commit to a quote. Ideally you will charge for each and every hour you spend on this project and – trust me – you have NO IDEA how many hours this will actually be. But if they insist and threaten to take the business else where (and you need the money) then you can put together a quote, but itemize it. Referring to the earlier mentioned design document you should make a list, item 1 …. x hours, item 2 …. y hours, etc.

Don’t forget to allot time for: project setup, communication, app store submission, version 1 bug fixing, testing and whatever work you have to do besides of coding. And when you have estimated all the hours, take everything times two. You will arrive at a final quote that is orders of magnitude higher than what you would have quoted shooting from the hip.

And then when the client complains that he thinks you are calculating too many hours for “such a simple app”, you tell him: for an all in quote you have to factor in unforeseen eventualities, that’s why he probably will be way better of just paying your billable hours every 2 weeks or monthly. An hour-based arrangement should always feel to the client as being the better deal, because he knows that for all-in projects you are probably faster than you estimate.

Honestly I have the most respect for iOS developers who have an hour-based ongoing arrangement with their clients. And I kind of feel sad for the poor solo developers who let themselves be suckered into too-cheap all-in deals.

There is another philosophy, but this applies more for small contracting outfits: agile project management, called SCRUM. There the amount of effort for certain features is not estimated in hours, but relative to each other as a number of points. One item (called a “User Story”) could have 5 points and if something else is the same amount of work, it will have the same number of points. With scrum the customer will never see hours, but you will have a certain mutliplier (that only you know) to convert these so called “Story Points” into currency.

Scope

On several occasions you should stress that the agreed upon project scope is only what is written down in the functional spec design document. There are absolutely NO “obvious features” and there is no “I thought we also said we would do x”. If it’s not in the spec then it’s not covered. The client CAN have it, but it increases the project cost.

It is usually sufficient to just make a quote addendum similar to the first itemized quote: new item A …. x hours. And then ask the client to agree to the project extension in an e-mail. Everything that makes the project bigger you want to have documented somewhere. You could add it to the functional specification document or simply collect it in your mail box. But you might need to go back eventually and present to your client – refusing to pay more – the items that he sent you his approval for.

I told you earlier: a contract is everything that two people agree upon verbally or in written words. So those e-mails are essentially mini-contracts themselves. But don’t make the mistake of only discussing this on the phone, because people will generally choose to only remember talking that suits their agenda. On a study that was done, they found that people lie the most on the telephone because there is no record of it.

As a beginner you might be falling in love with all the nifty little things you could add to an app to make it “better”. The client didn’t ask for it, but hey, why not do a UIView animation from a to b. It looks SO MUCH MORE professional with that … STOP THAT right now! If you have cool ideas, don’t just put them in the app, but instead suggest them to the client. Most likely he will value your initiative but you will then actually have his approval for the extra stuff.

It is your job to follow the spec as closely as you can with the least amount of extra work. I like to structure my code to be reusing components wherever I can. So if you think that something you develop for one client might be useful later on, then design for reusablilty. This means for example, writing a delegate protocol instead of having all parameters of a class in fixed instance variables. This is not much extra work, but might save you some in the future. But bear in mind that you are not getting paid for too much creative programming. You should not expect your client to be happy about paying for your future benefits.

You want to write the least amount of code that covers the requirements. And if time permits make it loosely coupled and written in a way that you can come back to this code in half a year and still know how the pieces fit together.

Scheduling

Be clear about the amount of time you can put into a client’s project. Often a client would expect you to finish the project in the same amount that a full-time developer would take. But especially when you’re still going to school or university you might not have more than a couple of hours every day to work on this.  Even full time I am not estimated with more than 6 useful coding hours per day. Maybe I’m getting old (37 years) but writing good code is hard work on my brain.

Your client probably approached you, Devin, not because of your speed, but because he knows that he will get his app made for cheap. So right after nailing you on a low price he will try to get you committed on a release date. Rule Number 1 in IT: It’s finished, when it’s done.

Just be honest with the guy. You’ll do your best to do some magic, but miracles take a little longer. If he needs it by a certain date then you need to get more resources. If you estimate 40 hours for an app, then 2 guys might be able to do it in about half the time, possibly slightly more because of the additional overhead. You have to judge when to sub-contract parts of the app to another developer. Don’t feel bad if you have to do, your thoughts should not be revolving around how much money you will lose because it now goes to the second developer. If you were smart in your negotiations then you have enough room to keep 10-20% of the payment and still pass on a decent amount per hour to your samaritan.

Ownership

Generally if there is no other agreement made then the (self-employed) developer retains ownership of the source code. It’s just like any other written piece of art. He who wrote it owns the authorship rights. The client only implicitly gets the right to commercial use of the final product he commissioned. Without a contract that modifies this default situation you own the source and don’t have to give it to anybody. BTW this is not true for employees, there everything they invent belongs to their employer per default.

This is important to know for two reasons: 1) if a client is smart and has you sign a contract containing the “hand-me-over-the-source-clause” then you will need to be aware of this as this means you potentially lose any future business with him. Thus you have to charge more up front. 2) if there is a conflict of interest or he does not pay you have a great hostage.

I usually keep all project source code in a repository on my server so that I have at least two copies, one on my local machine (plus Timemachine backup), one on my server on the internet. For very select clients I give them a read-only access to the repository, but only if I am certain that we have an ongoing business relationship. There is the rare case when I am handing over the source, but that’s usually when I feel that there’s no hope of every making another Dime from this guy.

But even handing over the code does not mean you cannot reuse parts of what you made. When you code you learn how to achieve certain things better and faster and this knowledge you cannot selectively forget. Who is to keep you from building a new class from scratch that does exactly work the same as the other class the source of which you just handed over? (Well, in the US your client theoretically has the option of patenting what you made, but let’s not worry about this for now)

Conflict Resolution

There are two ways how people get paid for projects: either by sending invoices periodically for the hours they worked, or by sending two or three invoices for installments of the total project cost. You could agree on a third up front on signing, a third when the first prototype is done and a third the day you submit to the app store. Any such payment can also be seen as the client being ok with what happened so far.

If you had any form of contract or agreement then the payment schedule would have been a part of it. But then you would also have an agreement on the other items mentioned above. So what do you do – as a beginner – if the client tells you that he won’t pay anything more than he original was quoted. I had this very situation about a year ago, have a look at the recommendations of how to deal with contracting clients who don’t want to pay.

Now about your case: I definitely recommend you compile a list of the original specs and then a second list with all the items that were added later. The original specs are what payment was agreed on. The additional specs still need such an agreement. In one case the original project quote was for 400 Euros and by making this addendum list I was able to show to the client that he approved over 100% more hours of work. Multiplied with my rate at that time, that increased the project payment to 1500 Euros. There were some items where I couldn’t find any e-mail with him responding OK, so these I essentially did for free.

If your client is unfazed by the second list, then you should be clear about being willing to walk away from the project. Either you agree to agree on a mode that you both can live with. Or you agree to disagree. The client is free to find himself another developer (whom you should secretly warn about him and send him to this article). Your stance should communicate that you are definitely willing to drop everything related to his app if no agreement can be reached.

As a beginner your feeling might be “oh my god this is my only customer and if he doesn’t like me I might never again find another”. But don’t you worry, there is much more iOS work to be done than there are developers. Usually demonstrating this “willingness to walk away” does NOT result in terminating the project. Rather the client will start to take you seriously and stop seeing you as a cheap coding monkey but as a human being who stands up for himself. And probably willing to negotiate agreeable terms as he still wants this app to be finished and put on the app store.

And you know, an unhappy programmer might be forgetting a crashing bug in the app, but not be around to quickly fix it. So it’s also in the client’s best interest to keep you happy.

Bugs, New Features

Software is never really “done”. After submission to the App Store your client might contact you because of some crash reports or customer feedback. Typically the app should have been tested thoroughly and bugs should not happen, right? But they do, if only for obscure scenarios where you used a 4.x feature and the app is running on a 3.x iPhone. Stuff that’s obvious to you in hindsight.

Now is the second time to agree on an hourly rate for quick fixes and one or the other enhancement. Again, if the user insists on quotes then give him a high quote for a “maintenance contract”, payable monthly. You are a professional and you are not dragging your feet when fixing your bugs. Hey, it’s a matter of pride. If the client wants to again nail you on a fixed quote, then that means you have not learned your lesson and he still does not take you seriously.

You want to have a situation of trust: he should trust you to work as fast and efficient as you possibly can providing quality that matches the agreed specifications. You should be able to trust that he will pay and treat you as a professional developer.

Conclusion

You might have grown to be a great iOS developer, but now you need to also train your business sense. These guidelines and insights should give you a nudge in the right direction. Your situation happens to every fledgling contractor. In the worst case you should change clients. In the best case you can talk with your client and find common ground based in reciprocal trust and respect.

Granted, beggars can’t be choosers. You might be saying “I was young, I needed the money”. But does that mean you have to do the equivalent of slave labor? Yes, you can have low rates at the beginning, but you still should adhere to some common sense guidelines as they are contained in this article. As you get better, you would not change your approach, but raise your hourly rates.

Most people have no idea how much work it is that has to go into a respectable app. They are not stupid, or maliciously ignorant. It will be your job to dissuade a couple of people from making “a quick app” and be picky about your contracts to take on the projects that are intellectually challenging and where you can work with nice and smart people at eye-level.

Categories: Q&A