Bloggertone updates

Developing An App: Forgot The NDA, Don't Own The Source Code And Other Expensive Oversights

Posted: 22 Jun 2012 05:52 AM PDT

There are so many questions that you need to ask before pressing ahead with your app development project that it is easy to overlook some of the most important ones. To some these will be obvious, but to others it could be the difference between a good and a bad experience. I cannot stress enough how important it is, before getting an app, to spend as much time as possible on the preparation and logistics of your app with your developer.

# 1. NDA

It is always a good idea to get a NDA (non-disclosure agreement) signed before discussing your App ideas in detail with any developer.

It allows both parties to talk freely about potential app ideas, business models, etc, safe in the knowledge that anything discussed will not be disclosed to anyone else.
In the context of discussing your app idea, it is meant to give you peace of mind that the developer isn't going to steal your idea. Most developers have enough ideas of their own without needing yours, but the NDA makes this assertion official and professional.

The developer will usually have a copy of an NDA if you don't already have one of your own.

Now, onto those questions that are all too often overlooked…

# 2. What type of App am I getting?

I covered this in a previous post but it is so important to be aware of exactly what you are getting, as Apps do perform differently depending on whether you go for, Native, Web, or Hybrid. They differ in speed, functional capability, availability off line, and look-and-feel. Expensive mistakes can be made in an effort to save a bit of money. Discuss all options and the pros & cons to these type of Apps with your developer, and then just to be sure, double check the information.

# 3. Who owns the source code?

This is a biggie. Most people assume that if they are paying for an app they are getting everything. This is not necessarily the case.

European law states that source code belongs to the developer unless the developer assigns ownership of the code to a third-party.
In the US, the opposite is true, the source code automatically belongs to the client.

So, why would you need the source code? After all, you're not a developer, it's not like you can do anything with the code yourself! Well, if you ever need to change developers for any reason, unless you have the source code your new developer will have to start from from scratch.

There is also the question of why the developer would want to keep the source code; this is usually for one of two reasons:

Firstly to force an ongoing relationship, i.e. to tie you in to getting the existing developer to make any future changes or updates at whatever price they want to charge you
Or so that they can recreate the app again and again for other clients.

# 4. Do you have exclusivity?

This tends to go hand in hand with the previous question; if you don't own the source code, do you have exclusivity? Ok, first of all, what is exclusivity?

Exclusivity ensures that the developer will not sell the source code to someone else to create a competing product, nor will they recreate your app as a competing product directly for another client, or themselves.

Even if you own the source code, you should still ensure that you also have exclusivity. There is a caveat with exclusivity; it will only ever apply to your specific implementation of your app idea, and will not cover variations of it.

# 5. What is the cost of maintenance and upkeep?

A maintenance contract offers some peace of mind that all those little bugs will be dealt with as they arise.

And they WILL arise; It's not a case of IF the app needs updating, it's a case of WHEN the app will need updating.
Negotiate a plan with your developer that suits you both, but as a rule of thumb, an annual maintenance contract for a native app should cost somewhere in the region of 10-25% of the initial development cost of the app, depending on the complexity and the service level offered.

# 6. What happens when Apple or Android bring out new updates?

Quite often, these system changes have an impact on existing apps and your app may need changes to cope with whatever updates arise. Your developer will know about any potential changes and whether they will impact your app before the system updates are released so should be able to pre warn you. Handling these changes will often form part of the maintenance agreement that you have with the developer, but make sure.

If you have a Hybrid app make sure you know the consequences and problems that may arise when Android and Apple do updates.
Remember, with Hybrid apps there are 3rd party libraries involved and these have to be updated so that your app continues to function properly.

For example:

When Apple brought out IOS 5.1 it changed the way temporary data was handled and controlled which meant that the system could (and did) delete temporary data. This effected Hybrid apps that use temporary storage for their data.

These types of issues do not get an immediate fix, the 3rd part libraries have to be coded to adapt.

# 7. Do you own the app in the app store?

We have seen cases of apps being put on the app store under the developer's account. This is not a good option for a number of reasons:

It means the app belongs to the developer not you. Regardless of any legal documents or guarantees that you may have in place, Apple's rules are clear, and if your relationship breaks down with the developer you will have no recourse through Apple to get control of your app.
If you ever change developers and want control of your app, it will have to be removed from the app store and resubmitted under your own developer account. You will not be able to resubmit the app using the same name, and regardless of the fact that it uses exactly the same code, it is a completely different app as far as the app store is concerned, so any reviews or ratings that were associated with the app in the app store will be gone.

Most of the above also applies to the Android Market Place.

You should ensure that you have your own developer account and that your app is released under that account. Your developer will be able to guide you through the process, or even set up the account for you.

# 8. Should the app be localized?

This is less of a question for you to ask the developer, and more something to consider that often gets overlooked. When you're thinking about the initial app idea, you should think global as well as local, most apps can cater to overseas users, and even if your app is only aimed at a local market, the users of the app may not be local.

Most people will associate "languages" with "localisation", and whilst having your app available in other languages is a part of localisation, it is not the only part and may not actually be the most important factor depending on the type of app and the target audience.

Factors such as:

the display of dates & times,
currencies,
metric or imperial measurements,
miles or kilometers,
and decimals or commas for the number separators

These may have a bigger impact than whether the app has localised languages available.

But when it comes to language localisation, there are two very important points;

Firstly, make sure that the developer creates your app to use localisation right from the start, even if you are only going to release the app in English initially, as this will simply the process of adding new languages later.
Secondly, and this is very important, DO NOT USE machine translation services; they make work very well for a paragraph of text in an email, but they do not work for apps (or web sites), where they cannot possibly understand the context of individual words. Aside from the context issues with translation, a professional app translation service will understand the constraints and limitations of the device screen size.

Finally, do your research before implementing every possible language, as you may find that certain nationalities actually prefer the app in English whilst others absolutely must have it in their own language. These preferences can also change depending on the type of app, so a business app may be ok in English but a utility app needs to be in the localised language.

# 9. Have you got contracts in place (re: all of the above)?

This is so important for both parties, no matter how friendly you are with the developer or the client things can go wrong. Make sure you are covered. Make sure you are clear about what you are getting, have it in writing and after you are both happy, sign contracts.

This is your App so ask as many questions as you need to, after all it is your business and your money and a good developer will want to make the whole experience as simple and understandable as possible. App Development is not pocket money, but neither is it as expensive as going for the cheap option and getting stung.

Do your research, ask questions and listen to your gut. A lot of time will be spent chatting with your developer so you really need to have a good relationship and trust.

May your App adventure be an h-Appy one, please leave any questions or comments below.

Did you like this article? Sign up for our RSS, like us on Facebook or follow us on Twitter

Image: "Smartphone with cloud of application icons/Shutterstock"