I had a work-related nightmare this weekend, specifically about the product I am working on. It was my first and I’m pretty sure it won’t be my last, but that’s not a bad thing in my books. I joined this wonderful little team over a month ago as their first employee, and I’m only now getting to disseminating the news to my friends that I had “joined a startup”.
Bear in mind a lot of my friends are hard-working, office-dwelling people, with well defined job titles and managers to report to. As such, they have this utopian vision of what I do that leans heavily towards ping pong, open-layout offices and a dress code that could only be described as a state of undress.
While perks like this get a lot of press, they are really a superficial benefit. Startups are about passionate people working really hard; a cohesive team intensely working toward a vision of something better. I suppose that is where the nightmare plays in, this isn’t a 9-to-5 gig, it’s a 24-hours-a-day-7-days-a-week thing and it’s a tonne of fun.
I may not have started the business, but I get to own the product just as much as anyone else. And that makes the whole thing extremely rewarding. It’s a feeling I can’t get being an office-dweller or a manager. So what if it comes with a nightmare every so often. To me that just tells me I’m doing something I really care about. What else could I ask for?
I don’t know exactly
Here at LaunchPad we are passionate about making mobile better.
PS. We’re still working on the job title thing, what do you think about Director and Interim Head of Sexy?
People talk a lot about on-boarding, whether on mobile, desktop, or really any piece of software. They generally talk about best-practices and show some examples of on-boarding flows or messaging that they think fits in with those best-practices. What people rarely talk or write about are the hard numbers. They don’t show how changes to on-boarding process affects the percentages as it relates to conversions. And more importantly people rarely talk about just how bad conversion rates are to start with.
Maybe people already view it as a given, but to me, I think we need to more openly discuss how big a problem on-boarding is in mobile. Right now, if you publish a native iOS application that requires some sort of login to function you will at best get a 30% download-to-usage conversion rate. And that is only guaranteeing at least one-time usage. While, the 30% number is anecdotal, it is corroborated by personal experience and discussions with many other app developers. The clear trends are like a punch to the gut.
Combine the abysmal on-boarding rate with the fact of life that on iOS it will take you at least a week to get any update pushed to the store, and you have a massive uphill climb for any developer. The only way that has been 100% proven to get over this hill on mobile to date is to spend your way out of it. That is why the revenues generated on mobile are being dominated by a handful of players. It clearly takes a lot of manpower to overcome the problems in mobile.
LaunchPad reduces the manpower requirement, because it gets rid of the structural problems. While LaunchPad can’t automatically fix your problems as they relate to on-boarding, LaunchPad can let you make changes to your app and push them to your users in real-time. This gets rid of the week-plus delay with the app store and allows you to react to your analytics data instantly.
I can’t overstate the importance of this. The only thing that will ever be able to solve the problems of on-boarding is the ability to react to data in a timely manner. Up until now that has just not been possible. The delays in pushing updates has meant that developers tend to push bigger changes with more hypotheses baked in than they should. The delays also mean that getting to some optimal state takes longer than it should. In the competitive world we live in as mobile developers if you can’t fix your problems right away you’re as good as dead. The users and customers aren’t waiting around for you and if it takes you five revisions and two months to fix something, consider your app to have missed its opportunity.
The mobile app market is insanely competitive with almost two million apps on iOS and Android combined. That type of market needs tools that let developers react quickly. LaunchPad is one of those tools and we hope that it helps everyone to build better, more successful apps.
At LaunchPad, we use the latest web and server technologies to help us deliver great interactive experiences. At the core is our MEAN stack (mongoDB, Express, AngularJS, and node.js). While we are huge fans of each technology and the stack that we run on, the nascent nature of each technology periodically has its down sides.
Today, the Angular team at Google pushed the long-awaited release of v1.2.0. At LaunchPad, we’ve been testing the unstable branch for months and love many of the new features that have been added (e.g. animations, better error messages, etc..).
With the launch of v1.2.0, the Angular team introduced a breaking change for anyone using variables with underscores, such as _id in mongoDB or couchDB. This means that any references to _id do not work anymore, breaking many apps and introducing many users to the error message: “secure expressions by hiding “private” properties”.
While its not unusual for breaking changes to be introduced, it is a bit odd for these changes to be introduced when transitioning from a release candidate to a final release. Because Angular already had 3 release candidates, this has left many users frustrated that their apps are no longer working. Within a few short hours, dozens of comments have already been posted in the pull request on GitHub.
To many, this situation may be a turn off to using Angular or other emerging technologies. For us though, while we are frustrated that this change has broken our stack, we are impressed that the Angular team has been so open and responsive with the community. It is clear that they did not intend to make such a breaking change and are focused on finding a solution.
At LaunchPad, we have decided to hold off on upgrading to 1.2.0 until a final decision has been made. Given how fast things move, we shouldn’t have to wait too long!
There comes a time in every startup’s life when you can’t keep things to yourself anymore. You have to stop holding on too tight, stop worrying about how embarrassing your UI or code is and just let people use your product.
Well, we’re not all the way there just yet. Our developers aren’t fully willing to let go of their death grip, so we’ve come up with a compromise. That compromise is our very own private beta.
If you sign up to LaunchPad, we’ll put you in line to get your hands on our platform. We’re going to let people in gradually, to make sure we’re delivering the best possible experience to all of our users. If you want to skip the line though, there is one way and it’s actually pretty simple. All you have to do is send an email to email@example.com and tell me two things:
- Why you’re interested in using LaunchPad, and
- Why you’d be an awesome beta tester.
It doesn’t have to be an essay, in fact I appreciate brevity. Really this is just my way to get to know the people I’ll be talking to as we move through our beta.
I’m excited to get this beta rolling and share what we’re building with the world. I hope you’re excited too.
It always feels odd starting on a blank canvas. This being the first post and all, I really just wanted to give some insight into why. Why we started LaunchPad and why we think there are problems worth solving.
Aaron, Andrew, Jonathan and I started LaunchPad for one reason, we thought there had to be a better way. We had built a number of mobile apps and had grown tired of the many problems that kept popping up. These were the problems that just kept sucking our time away, making projects that were meant to take 4 months to build, take 8 months. These were the same problems that meant it could take months to improve screens and flows in an app.
The problems start with the platforms themselves. Google, Apple and Microsoft have structured their mobile platforms in a way that breeds inefficiency. Unlike the web, engineers are the only ones that can actually update apps, and all apps must be reviewed, no matter the change.
We aren’t willing to accept these as limitations anymore. We hope LaunchPad will be the platform that gets rid of these problems. No matter what though, we just want to be a part of the solution.
We’re excited for the journey, and this is just the first step.