Impossible Ventures Apps
This post originally appeared on Impossible.
Over the last couple years, Impossible Ventures has released 4 apps.
In all, we’ve sold 100,000+ in sales over the past few years.
No, we’re not venture backed.
No, I’m not a developer.
No, we’re not building the next Facebook.
But we are profitable and we’ve had apps work extremely well for us.
Here’s a few major lessons I learned as a non-technical founder bootstrapping 4 apps over the past 3 years.
Whatever your idea is, start smaller.
No one who has ever said, “My app is the next billion dollar idea,” has ever made an app that is the next billion dollar idea.
Don’t say this.
If you do, it’s a red flag and you’ve likely come up with way too many complicated features to get off the ground without millions in funding.
Remember, Facebook started as a campus directory. Uber started as an easier way for a rich guy to call limos. Twitter started off as a glorified text message.
I know you think your app is gonna be the best app to ever grace the presence of a mobile device. It’s going to have 20 different options with customizable choices and win tons of design and functionality awards.
Stop it.
Build 1 feature. That’s it.
I know, Facebook’s app had a ton of features in it when they started. Keyword — DID.
You know what they’re doing now? Making 1 app for 1 feature.
Twitter does this too.
And Google does as well.
You get the idea. There’s a reason every major tech company is focused on making their apps SIMPLER.
You can have multiple apps within a brand ecosystem and have each one build upon the other, but you shouldn’t shove a ton of conflicting features into 1 app. When you do that, all you do is just guarantee that your 1 app will be overstuffed, slow and not nearly as good as it could be.
And trust me — you’ll be tempted to stuff features into your app.
People wanted recipes in Paleo (io). People YELLED at us for it, so we added them at first. But the major issue is that good recipe app functionality is COMPLETELY completely antagonistic to building a good Paleo food search app (which is what Paleo (io) is designed to be).
So, in order to make a better app, we got rid of it. Then, we built the feature RIGHT and released it as it’s own awesome Paleo recipe app.
Now, we have 2 awesome Paleo apps that do 2 very separate things VERY well rather than 1 Paleo app that does 2 things in a mediocre way. We’re building an ecosystem of apps rather than a uber-app that does it all.
Most people when they develop an app do this:
Instead, the process should be something like this:
Build your audience first. You’re going to have to get an audience to take a look at your app one way or another, so you might as well build it yourself.
In emoji form, it looks something like this:
What Most People Do
1
2
3
What You Should Do
1
2
3
4
Build your audience first. You’re going to have to get an audience to take a look at your app one way or another, so you might as well build it yourself.
By the way, this doesn’t take NEARLY as much work as building an app without any technical expertise.
If you’re not technical and you’re not willing to build an audience, I don’t think you’re ready to build an app.
I spent years building both Impossible and Ultimate Paleo Guide before deciding to build an app. When we did, we knew exactly how they would answer people’s pain points (because they had already told us).
If you already have an audience and want to build an app about something completely different, consider building an app that serves your audience first.
Don’t try to build version 10.5 of your app out of the gate.
“If you are not embarrassed by the first version of your product, you’ve launched too late.” — Reid Hoffman
Release the first version ASAP. Get feedback, change things and then update.
This is good in another way — it forces you to keep things simple (see item #2 again).
You don’t want to put live a broken app, but you can put live an app that is simple, then add features down the road.
The best part? Every feature you add gives you an opportunity to talk about it, do press releases and announcements, and makes your current customers even more excited about what they already paid for (apps that get updated are the best). It also gives you free marketing opportunities to talk about the updates in all of your apps (LeadPages does this very well).
I’ve outsourced in the past and I’ll outsource in the future. I’ve found — not entirely exclusively — that US devs are the best.
It’s not that overseas devs are bad — many are good — but if you go overseas because you think you’re going to save money, you probably won’t.
In my experience sifting through tons of contracts, overseas devs tend to be 1/4 or 1/3 the cost of US devs. That said, they tend to have timelines that are 3–4x the timeline of a US dev.
This is not always the case. If you know a reliable developer that lives outside the US, use them. That said, if you have to sift through the chaff, it’s simply not worth it.
The app ends up taking much longer to get built and costs about the same amount in the end (not ideal).
There are good overseas dev shops out there, but you’re much better off finding an awesome dev at a startup, whose mobile work you admire, and convincing them to do freelance work.
=> One solid international dev shop is Mobile Jazz
The CST app we just released was sort of working for a while, but not really.
I hate leaving things unfinished. Some features didn’t work. Sometimes it didn’t recognize accounts. Sometimes logins got screwed up. It was embarrassing for a little bit, but earlier this year we got sick of it and decided to fix a bunch of stuff to make it up to snuff.
If you’re going to do something, make sure it’s worth doing well. If you’re going to leave it half-unfinished, just get rid of it or don’t bother doing it.
We recently re-released the CST app for the sole purpose of cleaning it up and making it function in all the ways we originally designed. It’s also interesting to see the leaderboard of who’s really getting competitive in it all.
When people say, “We worked for months to build our app and then put it on the App Store and sold nothing,” I want to slap them upside the head.
The worst part is that they jump to the conclusion: “Apps are dead” (because they didn’t work for me).
Oh really?
You thought that by just submitting something into the world that it would automatically be a success?
When the App Store first opened, there was such a vacuum that you could could get away with that for a while, but we’re at least 7 years past that.
Now, the App Store is like any other competitive market.
Would you put out any other project into the world and just expect to make money?
How ridiculous would that be in any other scenario?
This complaint is THE biggest pet peeve of mine with developers in this space and it’s so common.
If you think Apple is going to do your marketing for you, you need to put on your big boy (or girl) pants, suck it up and stop living in 2008.
If you said that in any other context, you would be laughed out of the room.
I started a coffee shop…
I started a blog…
I started an e-commerce site…
…but I didn’t do any marketing because I thought they would just find it.
That’s the dumbest excuse I’ve ever heard of. Plan your own marketing — or even better, do the dirty work of building your own audience (see #3) before you worry about building some sexy app.
If you build it, they will not come.
They will come if you go out there, find them and tell them a compelling reason why you’re going to make their life easier.
Note: if you’re an Android user, this is solely meant from a business analysis perspective — I still love you guys :)
If you’re building an app (without funding), build for iOS first. Don’t bother with Android.
Why?
Because they make a lot less money, there are a lot more variables (and screen sizes), and they need more testing.
On top of this (and I still don’t know why), despite the market share split being about even (which Android users will love to tell you), Android users spend less on apps and click on fewer ads than iOS users.
I’ll be the first to tell you I have no idea why, but from a revenue standpoint, they bring in a lot less of it. That’s why we develop iOS first.
So, if you’re a bootstrapped, do what you can to help your Android customers be patient, but stick to what makes business sense and build an Android version only after your iOS version has validated itself.
Despite buying less and spending less money with you, Android customers tend to leave a higher quantity and quality of app reviews than iOS users.
This is a strange phenomena that I haven’t seen anyone else point out, but it’s 100% true in my experience.
While iOS users tend to be black and white (5 stars — amazing or 1 star — this sucked!), you’ll get more actionable feedback from Android users (this app does this well, but this part isn’t functioning as well as it could — 3.5 stars).
For this alone, it’s worth getting on this platform as soon as the app validates itself, so you can iterate on user suggestions and implement some of the good feedback.
The last piece is to remember #4 and when in doubt, keep your app development simple and fast. Here’s why:
There you go.
That’s how we built an ecosystem of apps to six figures with zero bootstrapping and zero funding.
We’ve got a lot more on the way as well.
If you’d like to checkout our various apps, you can download them below:
If you enjoyed this post, I’d appreciate if you’d share it with someone who might find it useful.
Now get out there and build stuff.