6 Steps to get an iPhone Developer to Work for Equity

(Alternately Titled How to Find a Technical Cofounder)

I’m an Austin-based iPhone Developer with a lot of experience. So I get about a couple people a day, 365 days a year, who inquire about my services. I’ve cataloged a few thousand inquiries at this point (99% don’t pan out, obviously). An awful lot of these people want me to work for free (i.e. equity deal). Since I literally have literally turned down a thousand of these, I figure I should write up the blueprint to getting my attention for an equity deal, since I’ve seen just about everything at this point.  A lot of what I have to say is probably applicable to doing an equity Web project, desktop app, Android app, etc.

Step 0: Don’t ask for an NDA

I sign NDAs only with qualified leads that pay actual money.  If I signed NDAs with the thousands of equity people, I’d probably be prevented from ever developing anything ever again.  If you ask for an NDA on an equity project, you hit the rubbish bin instantly.  No exceptions.  I know a lot of smart developers who don’t sign NDAs ever, so if you’re asking for an NDA you automatically get the bottom of the barrel developer.

Step 1: Have a niche

If your “great idea” is a mass-market app, I have zero interest.  I am immersed in the iOS market seven days a week, and as a result I know that market a lot better than the people who come to me with equity deals.  There is never a mass-market idea that I haven’t heard.  Either we’re working on it already, we’re working on an improved version already, or we’ve de-prioritized it to work on better projects.  Probably the latter.  Any mass-market app falls into one of these three categories.  There is absolutely no reason why I would elevate a project we’ve chosen not to work on today to active status in order to cut in a third party on the revenue.  None.  Mass-market apps are a non-starter for equity deals.  (We’re happy to do mass-market projects for clients paying market rates.)

Now there are a lot of markets I don’t know at all.  Construction.  Finance.  Design.  Sales.  Trading.  Analytics.  If somebody says “I’ve been doing real estate for two decades, and what the real estate market needs is X” that becomes very interesting, because it’s probably not an idea a lot of people (who can write an app, anyway) have had.  And the primary value is your experience in the industry, not some idea.  Your experience becomes critical to the venture, and of course nobody can steal your experience, so you’re valuable.  But a lot of the people that have a few decades experience in some industry also have enough money to pay for an app to be developed outright, so a lot of these aren’t equity deals even though I might potentially be interested in them as such.

Step 2: Have Actual Sales in Your Pocket

If your idea of market research is “everybody I’ve talked to has said it’s a great idea!” this is a big red flag.  Why haven’t you sold any yet?

Building a product is hard work.  If you’re not going to be doing that, you had better be doing something.  If you can get enough customers to sign an LOI to fund the development, engineers get really interested in building your project all of a sudden.  If you can’t, we wonder whether A) the market doesn’t like your product, or B) you don’t bring enough hustle to the table to sell any.  Either way, we don’t make a return on our investment, and it’s bad news for your equity deal.  Anyone who shows us a stack of LOIs for people who want to buy their product goes to the top of the list.

Step 3:  Have a Prototype

But I can’t program, you say!  Learn how.  Of course the quality’s going to be terrible.  But if you won’t put enough effort into your project to take a CS class or two and bang something out, how are you going to face the other challenges in your business?  If you’re not willing to spend the time to learn programming, are you going to spend the time to learn sales?

When someone comes to us with a terrible prototype they wrote themselves, I think to myself “Here’s somebody who has enough drive to spend six months producing something out of their comfort zone.  If they can put in six months to learn this, they can face an awful lot of challenges, and so potentially they’re a very valuable partner.”  When somebody shows up with no prototype, I think “Here’s somebody who won’t even spend six months building something to show to customers.  How’s he going to be any help at all?”

Step 4: Have Already Worked at a Software Company Before

This is a practical thing.  If you’ve worked for a software company before (in QA, in sales, in accounting, doesn’t matter), there’s less I have to explain about how the sausage is made.  You already know industry norms.  You already  know what “milestone” means or how software projects are scheduled.  You know that nine pregnant women can’t make a baby in a month.  You can learn a lot of this by picking up a good book on software management, but it’s easier to learn from real life than a book.

Step 5: Have a (Flexible) Specification

Nobody good will ever work without a software spec, and (on an equity project) nobody will write it for you.  When I read a spec, I want 1) to completely understand the product, but 2) not to spend more than about half an hour reading it.  This means that you must aggressively cut features down to the very minimum needed to make sales, and include only those in the spec.  If you find yourself writing “The app should also use Push Notifications and run in the background,” stop and ask yourself–why?  If it’s really important, spend three pages each talking about why it’s important, if it’s not, leave it out.

Also include a sketch of every screen in the application, no matter how trivial.  Every dialog box, every screen, every error message, everything.  Sketches force you to 1) think through everything a user will ever do, 2) get the “full picture” of how complex your app is, and 3) make it really easy to read vs walls of text.  One or two sketches per page, absolutely no more than 15 pages.  This will force you to aggressively cut features.  The fewer features you have, the less we need to develop, the cheaper it is to produce, the better odds we have of making a return on our investment.

If your spec is longer than about 15 pages, the time required to actually build the product will be much longer than we are able to spare for any equity project, and the time it takes to read it and figure out what to cut is longer than half an hour, and we have a lot of other things on our plate today, so we just won’t read it.  If your spec is just a couple of pages, it’s way too short to have any idea what your project actually involves, we would have to have meetings to figure out what you really want, and we have all these specs from paying clients to read and have meetings about, so we’ll never get to your unpaid spec.  If you can, it pays off to have another software developer write your spec.  It’s a lot easier to read, and I can tell the difference.

If we do get to your spec in the pile of things to do today, we will probably have a list of questions/changes.  Sometimes the stuff you want to do is not possible on iOS, or is possible, but is very hard.  Other times Apple might have a problem with something you’re trying to do.  Other times the convention on the platform might be to have the Done button in the upper-right corner and you’ve put it in the lower-left.  The “right” answer is to say “All these changes are fine” unless the revisions are going to lose you a bunch of sales.  We suggest this stuff because we’re convinced it’s the right thing to do, but it’s also a good chance to see how well you trust our professional judgment and how easy you will be to work with.  We understand that certain revisions might be dealbreakers to you, but certain revisions are also dealbreakers for us, and we have a lot of specs to read today.

Another common reaction we have is “X is a lot harder than you think it is”, where X is turn-by-turn navigation, VoIP software, rich text editing, certain types of backgrounding, client/server development, voice control, holograms, nuclear puppies, etc.  Either cut that feature or get outside funding to fund the development of that feature.

But Golly, This is all a Lot of Work!

So is, you know, writing an actual iOS app.  Which is what we do.  Every day.  What will you be doing?

Another way to see this is to realize that there is (actual number) a 1000-to-1 oversupply of ideas to developers.  So developers only pick the .1% best projects.  You can buy your way to the front of the line by paying market rates for development.  But if you don’t, you have to actually be in the top tenth of a percent of projects to even get a developer interested.

---

Want me to build your app / consult for your company / speak at your event? Good news! I'm an iOS developer for hire.

Like this post? Contribute to the coffee fund so I can write more like it.