philippb

as far as I know is airbnb using this framework or something similar.

Thanks for the great input. I Agree on some points and disagree on some other.

Security is something you have to be aware. The easiest way is to just setup the server with https so that the communication is secure. This seems to be the recommended approach for client server communication that Google them self suggested during the Google I/O app security session.

We currently don't use Switchboard for anything where you can manipulate the behavior of the app. Remember, the code that gets executed is still in your control when you build and sign the binary.

We focus a lot on streamlining the development process. We're only two people cranking out code all day. For this reason we want to have one version out there that we're able to maintain. We test the app that it runs on as many devices as possible and crashes as little as possible. The problem with providing old versions is that users then also have support request about old versions. At this point we're getting about 400 emails a day. When a user has an old version, we send him an auto reply to update to the latest before we deal with the problem. Otherwise it's not getting manageable.

I think Internet access is by now default for close to every app. You can always justify it in the app description with Ads, even if you never show a single ad in the app. Another option is to track crashes. Here the same again as before, if a user does not like that the app needs internet access, he should just download a different one. The reason here is that you will not be able to improve your app ongoing if you can't measure what happens.

Linking the analytics together with tests or stage roll outs back to an automated configuration tool is super cool. But again, we're 2 people and we have a pretty good overview of what we're running and what to look at. But I agree that this becomes very powerful when your team size gets bigger and not every engineer is keeping track of all business metrics.

I like the idea. When I worked at appbackr we thought about something similar.

It would be cool when there is a little more data in the about the performance of the app. I think of it like a dribble for app developers that keeps itself up to date. As we're programmers we don't want to maintain it :)

You should talk to my friends from appmonsta. They have a lot of data around apps. Maybe you can work something out.

thanks for sharing this!

Take every service that is on the web and give it a try on mobile. Close to all of them don't work for mobile.

Most products are build for the web and then ported to mobile. I believe to be successful on mobile you have to think mobile first. Example: Web forms and surveys. There are services like Wufoo that build a great web product, but on mobile it sucks. We have a mobile app and close to all our users use this as their only computer. There is no service for great forms that we just can use.

This is the case for many other products.

These are my thought beside the typical mobile apps. Think of existing services, but think mobile first!

As I remember there is an interesting information out there from Evernote. they can tell a little more about that at scale. Apparently 20% of all Evernote subscribers have never hit the paywall, meaning getting to the point where there are limitations in the product. Those 20% signed up because they use the app a lot and love it. They feel that it's worth the money even without limitations.

The growth come all from organic search traffic in the android market. We haben't done any PR. We got picked up from some android blogs, but this will only give you a little extra traffic for a certain amount of time.

We believe that search is a valid model for a utility app where people actually have a need/problem and can describe it in a search term. Multi language takes a big part to the success of a search strategy. We also translated the app store description to all possible languages, even if we don't have the app available in these languages. The user will then get the english version as default.

For games and social apps growth has to come from within the app as search wont work.

Yes, the app is free. As you can see we have on the android market a gold version.

We started with the gold version to see how many people are willing to pay for the app even if they can get it for free. The only difference is a new icon and a pin screen that says Gold. We advertise the app clear in the app store as "Buy this app if you love KeepSafe and want to give the developers money".

We will be adding additional features to the app over time that will then also be premium. The typical freemium business model.

Rock solid point :) It's in there now.

I'm not sure if I agree on that. when we think about viral we think about one existing user is inviting another one. This is not the case just because you are on the store if your app does not add more value to the user then they invite a friend. Facebook is one of these examples. Your Facebook is better when your friends are in there. For this reason you invite them. An app that you use to hide some of your pictures is not getting any better just because your friends are using it.

Still good reviews and a good placement in the market makes finding and trusting you easier for the user. But if you don't get up in the ranks or search results there is nothing that gets you anywhere. Where as if you have a viral loop in your app, you can still grow even if you don't rank in the store.

I think it's great that you want to learn something new. The main question that I would ask myself is, what adds the most value to my portfolio?

How much value does another similar backend language give?

My thoughts on this would be: Not to much. I would rather look for something that makes you a more interesting engineer. You could e.g. learn to make android apps. That would make you a quite valuable person being able to code mobile frontend and a backend service. Or a backend language/framework that is far different and let's you solve problems that you run into with PHP on high traffic websites. Some companies started using Scala for high performance parts of their service. Or get a good understanding of Apache Lucene a search engine.

But something that is more different from PHP and will make you a more interesting engineer.

San Francisco, SOMA. Fulltime first hire, >3m downloads

We at KeepSafe are two co-founders who are looking for our first engineering hire. We have over 3m downloads and a killer retention. When you're interested to join a smal and successful startup where you have impact and server a lot of users, we should talk. Job post: http://dl.dropbox.com/u/620820/SF%203m%2B%20Startup%20first%...

Salary, equity + benefits. (and yes, we already raised money and have it in the bank)

Contact us at jobs@getkeepsafe.com

I lived together with Arram when he had 6 customers and did it with his mobile phone and a Excel spreadsheet by himself.

I have to agree with what you say. A very inspiring story!

I think there is a lot of interesting data in the stores. I'm interested at finding a correlation from app descriptions, update frequency of them and store rankings.

This has been one of the very interesting questions that probably a lot of universities tried to tackle. Taking the approach of just analyzing over 600 startups and finding relevant pattern is remarkable and smart.

I truly believe that this work can have a huge impact on how we're going to build high scalable companies in the future.

Taking a new approach is at it's time where business plan competitions are not "the way" to go any more.

Great work!

Google based this site of the result of the website Cyclex.de. That apparently publishes the data without that the owner (a good friend of mine) submitted his address or gave permission to publish it. This is a good friend of mines place. And it is his private phone number and his business is on a different address.

Weather the data source is fault or not, it's Googles mistake that it shows up as first search result in their index.