When Should I Hire a Developer for My Startup?
One of the cringiest moments I get when advising early entrepreneurs is when they tell me they have this great idea and are already paying a developer to build it out.
I love the aggressive attitude and the can-do spirit. But there are like a million things you need to do before you start spending money on that freelancer or offshore team.
Wait. Five. There are actually five things you need to do before you hire a developer. I get a little hyperbolic when I’m frustrated.
1. Build Your Paper MVP
If you’ve already built an MVP, move on to Step 2.
Last week, I wrote a post on building a Minimum Viable Product. The concept is to create the quickest version of our product, limiting the feature set and faking most of the automation, so we can prove out our idea.
Now, should you code the MVP yourself? Look, I love Learn To Code, but let me offer a little counter-advice: Instead of learning to code, learn to Hack Shit Together. That’s how you build a Paper MVP, which is like a regular MVP, only there’s a lot more duct tape.
There are all sorts of platforms that can emulate just about any tech functionality. Try AWS and Serverless with Lambdas, or if that’s too daunting, then maybe WordPress, GSuite, Zapier, and Slack. These let you drag-and-drop your way to building web apps, databases, APIs, whatever, with just a little code— you can literally fake the whole thing.
Your Paper MVP should do one thing and do it well, the thing that’s going to prove out your idea. If your idea is that people will pay for interactive VR cat videos, your Paper MVP does ONLY interactive VR cat videos — there is no built in social network, there is no cat ranking algorithm, there is no geolocation of nearby cats. Because that last one is super creepy.
Now, should you launch an actual real-world product off these platforms? Absolutely not. But if this Paper MVP works, you’ve completed Step 1. Four more to go and then it’s the developer’s problem.
2. Create Your Distribution Mechanism
You may already have a way to get your product out to market. If so, go to Step 3.
No matter how great our idea is and how well our product eventually works, it doesn’t mean anything if no one can get to it.
If we’re building an app, we’re kind of locked into the app stores. Any other kind of traditional or web-based software is going to transact over its own website and/or some kind of aggregate — a good example of an aggregate is Steam for games. If hardware is involved in our product, don’t go to Amazon with an MVP, you’ll get booted off. Stick to Shopify or something like it.
Now, that’s just the mechanism, it’s not going to push our product through the store. But for our MVP, we don’t need a huge audience. What we do need is the ability to track any usage of our product that comes through these mechanisms that our company isn’t directly responsible for. We need to know who those users are, how they found us, and why they came.
3. Get People To Use Your Product
If you’ve got people using your MVP, move on to Step 4.
So who is going to use our product? Simple question. Really, really tough to answer.
Describe the kind of person that is most likely going to get the greatest value out of our product. Narrow that definition way down and take out any relationship to you — not your friends, not people in your industry, not left-handed people, not sports stats geeks.
Yes, I’m assuming you’re a left-handed sports stats geek with a desirable job and a ton of friends.
Once you have a really tight definition of your most valuable user, find as many people as you can that most closely resemble that definition. Find huge groups of them. Then sell your product to them, give it to them, leave it on their doorstep in the middle of night.
How they get it doesn’t matter, but here’s what they should have: They should know why they need it, they should know what it does, they should know how to use it, and they should know who to call when it doesn’t work.
Then, you need to be able to contact them and you need to give them a reason to give you feedback. Because they’re going to tell us what kind of product we actually need to build and what kind of market we actually need to sell into.
Chances are it’s not going to look like the idea we had at the beginning of this post. So I just saved you a bunch of money.
4. Get Customers to Pay for Your Product
If you’ve already got people paying for your product, you need to hire a developer, right? Eh, just move on to Step 5 and make your own choice.
But yeah, it’s always best to have money coming in before you start putting money out. I’m not saying the damn thing has to pay for itself, but getting people to open their wallets and give you money is the hardest thing to do. If you can do this, then you have a good idea.
The good news is that we can make some guesses about how much it will cost to make the product and how much we can charge for it.
We can be wrong about those guesses, the only wrong we can’t be is charging way too little. Introductory pricing is meant to get customers in the arena, but selling a $100 product for $1 is going to prove nothing. And that’s also how Ponzi schemes start.
One last step to go.
5. Get Customers to KEEP Paying for Your Product
This is where it gets chicken and egg.
Ideally, we want to keep customers coming back and spending more money, whether that’s through higher tiers of usage, upgrades, professional services, hell, even in-app purchases. It’s much easier and cheaper to sell to an existing customer than it is to find a brand new customer.
But if our product is limited and low-quality, the customers might not be coming back. No matter how much value we initially provide, expectations will eventually rise to create the need for a professionally built product.
A leap of faith my be required.
Thankfully, it’s much easier to to take that leap with data. By now, we may know enough about our product from Steps 1 and 2, and enough about our market from Steps 3 and 4, to be able to connect the dots on where that recurring revenue will come from.
So what do we do? We hire a developer to build the professional version of our Paper MVP. Then, with the developer’s help, we build a traditional MVP (i.e. not Shit Hacked Together) for the next feature set, which are the features that Steps 3 through 5 have told us our customers want. Then we run Steps 3 through 5 on that feature set, developing what works, scrapping what doesn’t.
At that point we’ve got a repeatable cycle that will allow us not just to build out our brilliant idea, but to keep building until we hit on another product, maybe even another company, and start the process all over again.