App Project Startup Checklist

Today I will tell you some important things to think about before starting your mobile app project that will save time and make sure you don’t forget to include the most common functionality.

First of all, everyone involved should be prepared to spend time and quickly respond when participating in the intense process of app development. Projects to develop apps are usually small, and for a good reason – the functionality should be specific. A good app should do one thing, and do it perfect, so this is definitely a case when less is more. Also, as users of an app is expecting frequent updates, it’s better to get something basic out soon, and then keep new features coming.

As it can take some time to get accounts on the relevant marketplaces, like the Apple App Store and Google Play, it’s a good idea to start those processes as soon as possible. Make sure that the contact persons are aware what will happen (e.g. they will be called up) so that they can respond quickly. Also, when using third-party content or custom encryption (according to US export regulations), make sure that the proper approvals are in place. It’s also a good idea to get a real SSL certificate, even in development.

On the client side, at least two roles are required, and the first is a business SPoC (Single Point of Contact) with right to take decisions on requirements as well as coordinating responsibility, e.g. with graphically responsible, acceptance testers, etc. The second client role is the technical SPoC for making both IT infrastructure and development decisions.

The user experience and graphical design of an app is essential, and it’s important to align with the visual identity guidelines of the company. Therefore it’s important that those guidelines are available to the app designers, and as a minimum they should contain things like color codes, fonts, correct use of the logotype, general advice and use of artwork, etc. This also includes graphical artworks in high resolution, preferably vector graphics, of logotype, symbols, icons, photos, splash screen imagery, etc. In the best case, specific app design guidelines are created with accompanying graphical artifacts.

Here are a number of general services that are common in most apps, and a typical example is sharing, which can be done either by built in support in the respective operating system of the mobile device or on the server side. For example, sharing via e-mail on the server side could require an SMTP server (e.g. Amazon’s Simple Email Service in their cloud). Other examples are sharing on social networks, analytics, ad networks and moderators, payments, push notifications and URL shortening, crash logging, and test distribution.

When it comes to the proprietary services, there should be a specification with request/response protocol (HTTP GET with URL parameters or REST), data formats (JSON, XML, RSS, CSV, etc), data/file download (items per page, refresh, get more, limit to number of and size of calls/files, etc), each request/response (URL and parameters/types), entities returned with attributes and data types (this is necessary even for cached and offline-only data), example of each request/response (that can be used for both service mockups and testing), and exception handling (both using standard HTTP status codes and/or proprietary error messages in responses).

There are also a number of non-functional requirements that should be considered and decided before development starts. For example, specify the supported operating systems, versions, and devices (phones). Another example is security concerns like authentication, local storage of credentials (keychain), encrypted communication (e.g. SSL), encryption of local data, etc. Other examples are multi-language support for both user interface and app data, response times, and caching policies.

So there you have the things you should think about before starting your mobile app project, and I wish you the best of luck implementing great apps.