Off the launch cliff – Are you orphaning your app?

When most conversations about third party mobile app development revolve around how to find a vendor or how to make the initiative work, very little has been said about [tweetherder]how to keep your app alive, after you exit out of a massive build out with a vendor.[/tweetherder]

Localytics app analytics - one-time usage

According to Localytics, [tweetherder]23% of apps downloaded, never get a second try![/tweetherder] So, one reason to remind the user to use your app is to tell them that there are good updates (and reasons to come back). Unless you have a very responsive, fighting against app fatigue is hard!

Mobile apps go through cycles of rigorous product development interspersed with dominant market facing activities that result in feature upgrades, quick iterations and deployments. However it takes time to settle into a predictable rhythm of build-test-deploy. Ideally [tweetherder]incremental releases would have to be taken in-house as they are market driven[/tweetherder] and often shorter turnaround could mean customer conversion.

The incentives for a dev shop and an app owner start to  get  mis-aligned after a fully loaded build out phase.

For an app owner, your priorities shift after a major launch – It could be front end tinkering, user experience experiments, bug fixes, marketing, alternate/fringe use cases, performance tuning etc.

For a dev shop, this means unpredictable usage of varied skillsets that goes against the business model of metered use of predictable skills in a predefined sequence. Also for reasons un-imaginable, dev shops don’t like to maintain code. They simply want to deliver once and move on.

[tweetherder]So when you hit the launch button, you should already have a plan for app development that does not revolve around your vendor’s availability.[/tweetherder]

Some realities when you launch an app  through a dev shop:

1. Most dev shops needs committed hours per month after the launch, for them to support you with post-launch work. Typically this would start at 40 hours per month (Use it or lose it model)

2. Even after you commit to these hours, response would be tardy (as they cannot make a developer available for you, much less without knowing that skillset you need!)

3. If you can not commit to minimum hours, you could expect the response to be even more tardier!

4. Progressively, your development team might get busy with other work and your code could get orphaned or at least relegated to a place in the priority list where it should never be at.

So how do you avoid falling off the launch cliff?

1. [tweetherder]Negotiate with the vendor if you could hire the developers off their team, at the end of the project[/tweetherder] (But there are better & democratic ways, that I’d describe below.)

2.[tweetherder] Hire a developer who could work on the product continuously. [/tweetherder]Pay the vendor for monthly overhead of managing your developer’s output instead of paying for discontinuous development that is not responsive to your market need

3. Hire a developer right at the start of the project that the vendor can transition to you at the end. Have the developer work out of the vendor’s office.

[tweetherder]Code that’s not continuously fortified is code that’s in rapid decay[/tweetherder]. When you have an outsourcing vendor, completion of a project can set the start of a rot. Plan ahead and mitigate.

How have you transitioned mobile app development back into your organization?





Building an app? Tell us about your project

We'll connect you with the right team for your project, for free!