App Development

The other day I was asked to explain the process by which I develop an app for a client. I figured it might make a good blog entry. This is specifically about working with outside clients. When developing for myself the considerations are a little easier.

1. What is it? App? Utility? Interface?

The first thing I always consider when discussing an app is to ask about the scope of the data transfer. What goes in and what goes out?

For instance in a game – data is mostly self enclosed in the app. I play the game. It ends.

For a utility, like a mortgage calculator, data meets data. I give the app numbers which merge with equations and then the app spits those numbers back out.

In both these scenarios there is a data out question. Is the high score saved until next time and can I save, email, screenshot, tweet, (whatever) the final outcome of the application?

The third type of app is one that is really just an interface, a connection to a server or database where the app is there as a conduit. This could be anything from email and social media to dating or user forums.  It means that the project isn’t just the app but the server components and the protocols.

In the end you have to always evaluate what goes in and what goes out (of the app).

Input can be from the camera, from a keyboard, from touch, or from a server. Output can be saved images, exported social media, email, text, or again to a server. The more you need the more it costs.

As a rule my company shies away from enterprise apps (for clients).  Not that I don’t have the expertise (I run several dating websites) but because the client work becomes never ending.  When you build a server/client app you are never done – you can’t just hand it to the client and walk away. The underlying infrastructure is constantly changing and someone (either you or them) will have to do ongoing maintenance. Smaller apps or games can be run into the ground – left on their own until the OS no longer supports their features.

2. What’s the target device – phone or tablet?

While many applications run both big and small – by design you are either writing two apps (a big and small bundled into one) or you are writing a big app that is small compatible or a small app that is big compatible.  As screens become bigger and higher resolution this becomes easier but for now you are still always putting one foot forward.

3. Target OS

Of course you can be (and should be) cross platform. When I started developing for mobile we actually even developed for the Color Nook and the Kindle Fire (which I still do). But you have to start somewhere.  As you build and test are you making an iOS app that is also for Android or an Android app that is also for iOS. Sure I will create both, but it is much easier to get all your concept and design testing done on one and then port and bug test on the other.

4. Branding

Always get the branding guidelines out of the way first.  Every organization I have worked with has had rules about credits, logos, colors, icons, fonts, disclaimers and all that jazz. Start there. Know what the limitations are. Often even the client is surprised with what their lawyers come back with and getting them involved to sign off on disclaimers or feature limitations early is essential.  I had a client who got upset when I used their mascot (appropriately) in one of their apps and then after I removed it got word from their marketing people that they wanted the mascot in the app! Also, it is easier to argue about buttons and fonts and colors early in the process than to try to drop a design scheme on at the end. Yes, the design elements that companies demand are often not ideal for phones or tablets but if you have the discussion on day one the compromises start early.

5. Intellectual Property

Who owns what? Generally, my clients are paying for a finished product.  They are buying a house.  The fact that I am building it is secondary.  This means that they don’t own my source code or even have a right to see my source code.  They don’t get the art assets I developed to use in their other projects either. They get the app. Now that doesn’t mean I can use the art or code in my other projects (but it doesn’t always mean I can’t either).  I’ve had clients that specifically wanted the art to use elsewhere. And I wrote that into the contract and the artists got paid more.  If one of my artists draws a hippo for an app they don’t expect to see hippo t-shirts produced by the client unless I  license the art that way.  That being said my artist can’t go and make hippo shirts from the art they created for the app either. It’s a mutual limitation. And it works well.  It let’s people know the scope of what they are getting and what they are getting paid for. The code works like the art. If a client wants the source files so that they can work with their in house programmers to “cut me out” – I will charge more.  That is reasonable.

Intellectual property in the world of apps (and games) is a funny thing.

Art is copyrighted.  That’s easy – in fact it is automatic.  If the client wants to file a copyright on the art then I make sure that it is a full transfer from the artist (and not just a license) and I let the client and their lawyers go to town.

Names and logos are trademarked.  That usually had been done long before I get hired. But if, beyond the name of the company, the client wants to trademark the icon, logo, or name of the app then it all falls on them in terms of both the labor and expense.

What about the code?  I’m not a lawyer. However, my experience is that copyrighting code is silly.  Because there are a million ways to do the same thing. It’s not the code that matters it is the structure of the interactivity or the mechanic of the game and that isn’t copyrighted it is patented.  Let me rephrase that – it is patentable. Sure it would be fun to have a patent but the price of the search and the filing (a lot) the limited timeframe (20 years) doesn’t always make sense.  And what is the utility?  There are fours reasons to get a patent. 1) Ego 2) To block people from doing what you are doing 3) To license to those people 4) To sell the patent to those people.  And all four of those are about other people. So unless the idea is crazy innovative – just drop it and move on.

What’s funny is that it doesn’t matter if someone else has already done the same thing you have. Let’s suppose that there is already a utility that does what you like but it isn’t pretty or you think you can make it better. As long as you don’t violate their trademark, use any of their copyrighted art, and the process itself isn’t patented then go for it!  If people didn’t innovate we wouldn’t have innovation.  But is it innovative!??

6. Distribution & Pricing

The trick here is about credit, money, and updates.

First let’s talk about the money.  There are really 4 business models for apps.

1. Free. And I mean free. Many of my clients are non-profits and it is about having the tool and branding the tool but not about generating income from it.  This is the easiest as no money is changing hands. Altruism. Or since some of these are grant based – socialism.
2. Paid. I charge money for the app.  Apple or Google takes their cut and then they send the rest on to my company.
3. Ad Based.  The app is free but has ads from one or more ad networks and depending on views and clicks money can trickle in.
4. In app purchases. The app is free but features of the app are unlocked by purchases on either a permanent (lite to pro) or a transactional (like 30 days or 3 individual uses) basis.

Let’s pause the money talk and move to distribution.

Who is the app for?

Most people who publish apps, publish them for everyone.  Some clients want the app ONLY for their organization or for a smaller subset of people – for instance medical people might only want doctors to use it or museums might only want museums to use it.  Limiting access can be done in several ways.

1. Install it manually onto the devices you want. This can be done locally or remotely but you need to know the exact devices that you are installing them on and there are only so many you can distribute to per year this way. It’s great for a developer but not for a real rollout.
2. Enterprise distribution.  If a company really know what they are doing and all of the devices are owned (and managed) by the same company, then they can do an enterprise rollout. Its complicated but it allows the company to publish the app invisibly and only allow certain people (but a large group) to get it.
3. Price to hurt. A common way to keep the general public from an app is to charge a price that says this is a pro tool. I once had a museum piece that went for $1,000 and instead of delivering the preloaded iPad I put the software on the app store for $1,000. Interestingly enough I would have lost money on this as Apple takes their 30% but Apple said no! In a very surreal exchange they told me that they wouldn’t let me charge the $1,000 (even though it was in their pricing model) but also wouldn’t tell me what they would let me charge because they don’t get involved in pricing! But the premise is solid.  They actually would have preferred I had done an in-app purchase for the high dollar figure than the straight out purchase because they said it offered less possibilities for accidents. I don’t know if this has changed.

If my company publishes the app then then money goes to my company.  Which means I now have to keep track as the money comes in of which app earned what. And while I SHOULD do this anyways, I don’t have to with my own apps as its all one pile of money called “things I made”.  With a third party company that means that for as long as the app is alive I am a conduit of income for them – we now have an accounting relationship. This sounds scary at first but…

1. Most of the companies I develop for want free apps.
2. There really is a limited time frame before an app expires, 2-3 years before the neglected app is no longer viable or is thrown off the app store for being un-updated.

Which brings us to updates (not maintenance – that’s the next section).  If I publish the app through my company then, as publisher, I can replace it and push out new updates whenever I want. It becomes part of my workflow and pretty straightforward to push an update.

Quick aside: I actually own two app companies.  I am a co-owner in (Lemming Labs Ltd.) where we create apps for ourselves and we publish the apps (we have the accounts on the app stores).  When my partner and I started Lemming Labs we knew that it would focus on our original ideas and not my freelance development.  As I also own a publishing company (ATBOSH Media Ltd.), when I develop freelance I run in through that company and as there is no added expense we publish/distribute through the Lemming Labs accounts.  I could easily have 2 publishing accounts but the added complexity has zero added value – I’m lead developer for both companies anyways so the work from a marketing perspective is equally representational.

So the credits of my of my apps say Developed by ATBOSH Media Ltd. for Name of Company, Published by Lemming Labs Ltd.

Sometimes I have to convince my clients that it’s OK to see the name of the developer/publisher.  Nobody is expecting these companies to have in-house development teams.  They aren’t software developers – I am. No illusion is broken by seeing our name. Going back to the house analogy – every construction site has the name of the construction firm on the signs.

However…

Some companies REALLY want everything under their umbrella. They want to see their name as the publisher in the app store and they want the money to come directly from Google and Apple.

It’s not as hard to make this happen.  I help to setup all of the legal relationships with Google and Apple etc. Of course their lawyers and IT people have to fill out the forms and baking and security but its pretty standard.

Then after I publish the app – I can transfer ownership to their account. And voila – they app is theirs.

But there is one small snag.

7. Maintenance

When talking to any developer this is always the worst part of the conversation because what the client calls maintenance – isn’t really maintenance.

Maintenance is where I keep up with the external factors that might negatively affect the product.

For instance. Apple adds a new security protocol or requires another icon or eliminates a resolution.  The things that keeps the finished product – finished.  At some point maintenance no longer works and I have to break it open again and revise.

There, of course, are also mistakes that are found after the fact. A stray pixel or a typo that could easily be revised. Even an updated logo!

However, changes to user interface or core functionality, these things should have been tested for during beta.  Too often bad beta testing requires revisions that people call maintenance. It is imperative that not only is scope clear but that testing is gone by the client so that the final version is really a final version – and not just the end of the funding.

Some developers charge ongoing maintenance costs.  Personally I would rather write the maintenance into the product – I think of it as my warranty against defect and generally I go for 2 years. After 2 years it isn’t about charging the client for a logo update or a recompile its about the client making a decision – is the product going to live or is it going to die.  And then I do a new revised project accordingly.

Assuming that beta went well and the product is perfect. The problem with maintenance is one of ownership.  I can revise products I am the current publisher of. I can’t revise projects that I have transferred ownership of.  I think we see this on the app store more than we realize. Where app 1 doesn’t evolve but is replaced with app 2.

So if a client takes ownership of the app then there will be no revisions – unless…

The one exception is if the client is actually a developer. In that case, and only if we used all the same tools, then I could send them the project and they could recompile etc etc. But that requires a very high level client at which point I really am primarily being brought it from my design work over my development work. I’ve had clients as but I really can’t, and am not in the business, of training their people to compile and publish my apps on their equipment.

8. Intellectual Property – Part 2

With all of these questions answered. I start to build. And it is all about the IP.  I have graphic designers, user interface designers, character and architecture artists, developers, programmers, plugin developers, copy writers, voice talent, musicians, sound effects artists, and the content specialists! And no – they don’t all look exactly like me (though many do as I wear many hats). The content specialists generally come from the client and work with the developers to translate the idea into reality.  This is iterative and everyone has to be open for the adventure. Along the way the corporate people will usually pop in and add some confusion and I prepare for that as well.

But everything is about scope. What does and doesn’t the app look like. How many revisions can the art actually go though. Some clients are fussy and vague and it becomes difficult to get sign-offs. It is part of our job to shepherd (not railroad) the client though the process so that they get what they want. It is important that the product is what the client wants or what fills the clients needs and not just a matter of where the bottle was pointing when the time ran out or the money ran dry.

The client has to be an active participant of the development team!

9. Timeline

Time is money. In both directions.  How long is this project supposed to last? When is it supposed to enter beta? How long is beta? When will it go live?  What is the schedule of deliverables? Again this is a two way street.  The sign-offs have to be as schedules as the deliveries!

10. Money

How much is this going to cost?

My favorite question.

I have no idea.

I really don’t. And even after I quote the client I am still hoping that they asked for what they really wanted. That it will fit the bill and solve their problems. That they know how to express what they want to see and like visually, that they can give good feedback so the artist can modify and not start over. I’m just praying the client will every be happy and then praying it is on budget and timeline.

In all seriousness in 2020 a single app will run between $15k-$45k.

That doesn’t mean a client should call me up and ask for a $15k app. That range is based on the typical scopes from mild to moderate for most apps I’ve done.  To be honest, more often than not, I am hired to do suites of apps (4-8 apps). And there are unknowns. Some clients come with their own art or artists (when I do medical work I hire CMIs – Certified Medical Illustrators) – that changes things too!

And while the client wants to know how much. I want to know… when?

While I always build a timetable with deliverables. It is usually 1/2 up front, a schedule for the rest, and then a token at the end.

One last thing about money. I often work with non-profits. They often can’t afford me.  That doesn’t mean we shouldn’t talk. If it is a good organization that I want to work with then I often can work within their budget. That doesn’t mean I’m just going to cut my price – it means I am going to build a scope around what they can afford and sometimes I may discount my price to give them more bang for the buck as an in-kind contribution.

11. Contracts

And then when it is all clear what is expected and desired. We write it up into a contract.

Things can change even with a contract. We can revise as needed in terms of scope but its important to make sure that things like that are in writing.

Contracts or not – you can’t build a relationship without trust. The process I outlined is about years worth of collaboration and it is best to make sure that it isn’t ONLY the contract that is holding the relationship together.

In Conclusion

That’s how I build an app for a client. As I review this essay I realize it is really about everything that goes into building an app for a client except for building the actual app. For many that’s the surprise.