The Angel Developer

  • Posted on: 13 July 2013
  • By: Shawn DeWolfe
“Hey, I got this idea!”

How many times have you heard that? As a developer, I have heard it many times. Ideas are ubiquitous. Hollywood is built on ideas: but a movie takes a script, a crew, a cast, sets and a whole lot more. Some ventures take a lot of infrastructure to get off the ground. Web ventures (sites, apps, etc.) can take almost no infrastructure to get off the ground. All you need is an idea, some know-how, a computer and the commitment to finish what you started. With so few impediments, this is why website and app ideas are popping up like crazy. But the key to realizing one of these ideas is the labour involved in designing and building the product. If an idea has a bankroll backing it, hire the people and get it built. To get the money, some entrepreneurs rely on Angel Investors. Angel investors get involved with a project at an early stage and fund it on faith that this venture will go somewhere. Most of those investors want to see a working prototype first. They will get on board to see the project mature to become market ready, but they need to see all of the parts moving first. They need a prototype. If an entrepreneur doesn’t have the money or skill to build a prototype, what are they to do? They need talent to justify the angel investment. To get that, they may have to look for an angel developer. An angel developer is the most important part to realizing a cash strapped project.

Good ideas are cheap and easy to come by. Success depends on how rapidly a product can get to market in its minimally viable state: a "minimum viable product" or MVP. That get its out there. It allows for customer discovery, popularity, a capital injection and the march towards success and fame.

An angel developer is talent who can build out a project to some state of readiness. What differentiates them from regular talent is that an angel developer is willing to come into the project at some discounted rate: maybe they need practical experience, maybe they are willing to work for a cut of the profits, maybe they’re just sympathetic believers in your cause.

Why would a developer discount their time? Normally, skilled workers should not discount their time. If they were in their right mind, they should rebuff the request for discounted or free labour. Most of them take the tack of “I’m too busy already and I’m not about to use what little time I have on this project of yours.” They are not giving up that time or that money. I argue the opposite is going on: an angel developer is not giving up on some development money, they’re laying down that portion on a gamble. They are gambling that they can get in on the ground floor for the The Next Big Thing.

Still the discount is a dangerous game and it will stop most prospective talent from getting involved. Ask two developers: the one that gets $500 per project suffers much more than the developer who gets $50,000. When work comes in at a higher rate it’s as though the client is hyper-aware of the expense and value. When you get to the scrappy hyper-discounted $500 guy, they’ll do anything for money.

Keep drawing that curve to “free” (a developer who will work for $0) and maybe they’ll do anything for nothing. I interviewed a woman who did a stint at a local diploma mill as an unpaid intern. I asked her what she did there, in the hopes of gleaning what work she carried out that could apply to the position we were filling. It went something like this, “I helped build a custom module... I did theming for clients.... I washed Windows....” Washed Windows? Is that like scrubbing the hard drive? I asked her clarify this part of her work. “On Friday afternoons, I would go out to the front of the school and wash their windows. All the interns do that....” That’s what free gets you: it turns a $0/hr. programmer into a $0/hr. janitor in the wink of an eye. While $0/hr. doesn’t pay the rent, it also can erode respect. Marketers call an effect like this “The Penny Gap”-- a $0 item is treated very differently from a $0.01 item. If you are working for a heavy discount that will hit your pocketbook. If you are working for free it means the number of hours you pour into a project are still multiplied and juried by your wage-- but free means an unlimited amount of time can go into project and some project managers may expect that much of you. If an entrepreneur antes up some cash they have some skin in the game. Likewise, if you agree to work for a trickle of cash as opposed to your usual rate, you're already volunteering money (your uncollected income). If the originator of the project cannot keep a trickle going, it's a sign that they're not serious.

Free labour, or deferred income, is a proposal you may or may not go for. In a couple projects, I went for “free” because I believed in the project and in the other members of the project. They had a known connection to their niche markets that was significant. Likewise, they were working on the project for free in their own part of the workload. Even so, I put a cap on how available I was; how many months this could go on; and when would expect the project to go to market. That market date was not arbitrary-- it was based on our collective estimates of features and available labour.

Why Do It?

As I see it, these are three of the models that a developer or designer can follow to earning a living. One is very common and the latter two are less common, more risky and more lucrative:

Path #1 - Consulting

This is the most common way to turn your talent into money. One developer said, “You’ll always be busy, but you’ll never be rich.” It’s true. If you are good, you can earn money. If you’re good and smart, you may be able to earn a lot of money. But, as soon as you stop that cash machine seizes up. The good side of this model: the money is also immediate. The bad side: you keep doing the same from-scratch work for everybody. No matter how much you augment your development with a content management system, premade themes, or a streamlined workflow, there is always a lot of custom work. As a programmer, I get tossed the “no one does it this way, so let’s try it” problems. No one mounts a steering wheel under a car, either. Accommodating the weird-to-be-different is doom. You have to turn down a client who considers “the customer is always right” as a holy mantra. Unpopular ideas don’t often gel and it means the client’s return on investment will be lousy. If it is lousy, they will be frustrated with the expense vs. the reward.

Because you have to make a custom body of work for a client, your work is married to the client's branding and business. If they chump out on a bill, you can sue them, you can hope they will pay, or you can eat the work. If you're a baker, that last option can be okay; but as a developer, it's a bitter pill. The consulting model requires you to ask for money up front, or a deposit commensurate with your trust of the client, or you bill after the fact and hope they settle up. Selling established products or offering set services allows for you get payment before the product/service is available to the customer. With a service, continued payment implies continued access to the services which is a great incentive to keep the accounts in good order.

Past all this: the consulting model doesn’t really scale. Some design houses have gotten bigger and more lucrative, but they get there by just throwing more bodies at more clients. There is no financial flywheel in consulting.

Path #2 - The Product

Books, applications, digital products like themes or vector art: these are good example of products. You need to have your products available for sale, but the relationship is finite. You get money and they get to download your product. It’s less enduring that the revenue model from a service, but it’s also less hassle. Ask the RIAA: digital content is really easy to share after the fact. A service model gets users addicted to the service. A product model is something people can take, copy, and share. Amazon has built a fortune on top of their Kindle editions. Apple’s iTunes is a major cash cow. Digital products is an entirely valid way to get money.

Path #3 - Automated Service

The other approach is to build an automated service. This calls for the development of a product (likely a software application) that is available for use when people want it. Many start-ups are offering services. Websites are automated services. Inside of that broad set there are ad services, financial services, social games, file storage system-- there is a long list of automated services that a business can offer the public. The upside of this model is that builds in a flow of revenue. As long as users make pay for the service, there will be an income. The selling cycle of getting a client on board for this service will be lighter than the selling cycle of gaining a client for your custom design work. As you get more customers there will be more opportunity for dissatisfaction (it’s math: if you’re 99.9% excellent, then every 999 happy customers will come with 1 angry customer) and you will have to work out how the mechanics of your customer service works. If you look at the large outfits (Google, Paypal, Ebay, etc..) the key to their success is their lack of customer service. They don’t have a toll-free line or an easy way to talk to a specific person to get satisfaction. They don’t get mired in the work to make a customer figure it out or feel satisfied. They work on the press of bodies-- if some people are trampled, the rest of the herd still gets in and pays.

The caveat is that like consulting, you need to keep the system going to keep the money going. In one project I have, we have to hand over most of our income to keep the server infrastructure running until it “catches on” and then the cost-per-customer expenses will diminish.

You may be offering an elaborate service to your customers, but the service will have boundaries. If your client wanted you do add a widget on every page that was either hard to integrate or one that jeopardized the larger success of their project, you would get into a battle of wills over whether or not that should be in place. If you are offering a service, your defense is as easy as saying, “Our service does not do that.” I had one client want to transpose how “AND” and “OR” worked in their search engine. It was a big battle of wills to impress upon them how it works. The same person would never have expected the MS Word development team to change its “Save” functionality. A service, like a product, implies reproducibility and service boundaries.

Why do it? Why not just keep consulting? Greed. I could be all high-minded about the challenge and excellence of it all. But the reason to drop the consulting model and be part of a product or a service build is a financial motivation. The consulting / client model is one where your business model (billing, work, service offerings, corporate culture) is constantly being challenged by outsiders in exchange for money. One person wants to be on chat all the time. Another one likes [blank] productivity app and insists that you learn it and use it. That guy wants you to get dressed up and meet him for drinks at the gentleman’s club. So’n’so is in town and lonely, wants to hang with his web designer. Your invoices read Net 30 but after 59 days you’re ready kill the project, delete the files and eat development costs. Blah blah blah. Some people are made for the consulting model and some are not. I am one of the latter.

My first job was as a writer. I got hooked on the idea of publishing and the promise of royalty cheques coming in. A start-up that promises to involve me in the service model or the product model is really enticing. Both those models have something in common:

Scaling: If your project takes off it can be replicated again and again giving you the benefits of an economy of scale. It may not only make a little bit of money, it could make a LOT of money.

Residual income: I would like a day off. A job-type-job brings with it sick days and vacation days. In the consulting model, you have to build in the days-off potential as fat on the project. If you make $X on 5 days, you may choose to not work on 2 days. If you make $XXX on 50 weeks, you can take two weeks off from earning and will all be okay. The truth is: your income may be so rattly that you cannot forego two weeks of paid work; or your clients may demand year-round availability as an exercise in customer service. A service or product still has to be available in your absence to generate that ongoing revenue. It is easier to deputize someone to “keep the server running” than it is to get them to “change the application” while you are on vacation. Part of that is a matter of getting good people to fill in for you, but part of it is having a piece of work (product or application) completed and generating income without active development happening. If a product or service can continue to generate income without your having to touch it, then it can generate an ongoing amount of residual income. Someone like me can take a day off.

How To Get Involved

There are approaches to getting involved. Saying “I’m in” is easy. But what you get out of it, is a critical part of the equation. Under what circumstances do you get involved and what are the ground rules you want to lay out? I propose that you get some cash, shares, experience and fame out of any project you step into as an angel developer.

Cash

The most basic motivation to get involved is cash. Some people have a great idea yet they cannot bankroll the $100k it could take to get a project out there. What an idea person could do is raise some money-- just enough cash to bankroll what one entrepreneur called a "ramen diet"-- just enough to keep the developer from going broke. If the developer heavily discounts their rate (eg. working for $15/hr. instead of a more comfortable $50 or $100/hr), it allows for a lot more labour than would be possible if that talent came in at their full rate. This is an approach wherein there is as much cash as possible for the developer, but it negotiates a way to stretch that cash as far as possible. If you are going to build a project for charity, that’s terrific; but usually this is about money. If you are a $50/hr. developer and you put 1000 hours into a project, that $50,000. Either you get your undiscounted rate or a partially discounted rate. If you work for 50% discount, that the same as contributing $25,000 to the project. If you have been asked to ante up $25,000 in time, it’s fair to ask the entrepreneur to ante up something in cash or a similar solid contribution to the project and to your bottom line. I had one prospect want me to get underway on a 500 hr. project and they couldn’t figure out why I was reticent, nor could they figure out that the project delivery would come 25 weeks down the road because should I go for a cash-less development, I wouldn’t commit more than 20 hours per week to the project. In the end, I didn’t go for that project because the partner brought one prospective customer to the table, no value proposition of their own, no money; and in exchange, they were going to reap a good chunk of the income and notoriety.

Be mercenary about the cash equation. Tie your time commitment and availability to how much cash is made available up front.

Shares

When a project goes well, it can go big. The million dollar ideas of the first dotcom era have been supplanted by the billion dollar sales of ventures like Instagram. Shares in a start-up are like a lottery ticket. Instead of 16-million-to-one odds for $2, you are looking at piling in months of effort for better odds and potentially a bigger pay off. If one gets involved in a start-up that is looking for help from angel developers, the idea of shares should be considered a given. That said, there are non-cash motivations to work on a project. From the entrepreneur's perspective, they should consider what they are doling out shares for. The Logo? If Facebook’s originators gave the logo guy 0.1% of the company for the logo that would be worth something like $40-million dollars. Do you think that logo could be worth $40-million or even $40,000?

In one deal I signed up for, I came in for a 2% royalty. Two percent. Or, if the entrepreneur's extrapolations were correct would be $10,000+ per month (that’s if the product makes a good penetration through one state, let alone North America).

In another deal where it was a partnership between myself and another, we each went in for 35% ownership, leaving 30% of the company hanging out there. This is “our” venture-- as in she and I co-own it. As our baby may need new shoes at some point that unallocated portion is there to allow for outside investment-- for someone to give us a cash injection in exchange for a stake in our business and its proceeds.

Expertise

A start-up needs coders but it needs so much more than good code. A start-up needs a good business head, visionary people who can carry out the big goals, and people who can generate great marketing buzz and exposure. In two of the ventures I got into I looked at the talents of the partner. In one case, she was well connected in her field-- the niche we sought to penetrate. In another case, my partner was a business connector. He had a big rolodex of people who could make things happen and who could take part in the venture. I saw there was a hole in the skills mix and I pressed one entrepreneur to fill that gap as a condition of me getting involved. If a coder brings code, other partners who bring value are especially important. If you can manage to be part of a strong team of people who are great at what they each do, your venture could stand a much better chance of succeeding. If it has a better chance of succeeding, it becomes less of a gamble. You are writing the deal when you get on board. You can ask that the team have enough oomph to cross the finish line.

Experience

When I have floated ventures in the past, I have found people eager to get into the project because it would give them real world experience. For the entrepreneur, people seeking experience can be a double edged sword: on one side you get eager talent who will be happy to work for free; on the other side, you get people who may not know what they are doing. I have peeked under the hood at some "I'm learning to code" people and have pulled back in terror. What an entrepreneur can offer a person seeking experience is a good reference and some valuable experience. Resumes never list how much you were paid from a given job. No one needs to know that your experience building exercise was done pro bono to build skills.

Free Time

Some people just have so much free time that they can entertain getting involved in something like a start-up. A start-up can involve a team of smart, driven people and if someone is looking for something to get behind, this could be a terrific way to convert free time into a shot at riches.

How to Get Involved

If you’re like me, being a developer puts you in the crosshairs of people with ideas. Some ideas I have been shown aren’t even remotely technical. Upside down ketchup bottles? Great idea but I have no idea how I play a role in that idea going somewhere. Fit is big part of assessing if you should get into an idea.

Will the idea fly?

Success is a big X factor. It’s the X factor. You have to push past the logic that chills many potential entrepreneurs. Most ventures fail. You have to ask about the different aspects of this start-up.

If I get involved, can I help this succeed? Make an inventory of yourself. In the spirit of full disclosure, I admit I did not do this on at least one occasion. The company was sort of like a dog chasing cars-- one minute we interfaced with remote controls, the next minute it was tied into medical devices, or maybe it was for websites? I ran out of stamina keeping up with what the project was doing. More than that, they made technology decisions based on their budget and not the objectives of the project. Can I code in that language? Hell, no-- but we’re doing it anyways. It was a bad experience all around. When I sniffed that things were off course, I tried to quit-- I told them that I didn’t have a skills fit for where the project was going. Just as the technology was not selected to complete the project, my skills were not being considered as a factor in how well I carry out my work.

Does this idea have a chance? Some ideas may only partially work. For example, you may be able to get an audience, but none of them will pay you. Or, you may not be able to talk people into using the service. Or, it may not scale. There are many ways that a good idea cannot turn into a good product. Make this assessment before you get involved-- play what-if games and look for the weaknesses in the prospect.

Does this idea have mature competitors? If your idea is the same as a mature and dominant product out there, your product may be fighting for air from the very start. Don’t think of a mature player as a killer. Whoever thought that Yahoo could never be supplanted ignored the potential of Google. Whoever thought that Google would be the most popular site out there ignored the potential of Facebook. Whoever thinks there will never be something more popular than Facebook is just plain wrong. That said, don’t expect to turn to your code editor and begin writing the the Facebook killer this afternoon.

Maybe the tech is covered off, what about the rest of it? The technology and code of a start-up is important-- it’s the heart of the operation. But who wants a heart in a bowl? There is marketing, user experience, project management, legal organization, sales team, investor relations and all of the glue that holds an organization together. If the other people in the organization can’t cover these other aspects to some degree, that will leave a hole in the project. Some people just say, “Let’s go!” and rush past the other details-- that’s a huge reason to not get on board. If you are promised 20% of the project revenue and no one gets around to giving you a contract that spells out that involvement, that’s a hole you’re going to trip into. Short cuts lead to short circuits.

Ground Rules

When you get involved, make sure you spell out some boundaries. Some people can do many things, but maybe you’re not on board to do the whole of the project. When you get in, establish your involvement:
  • What’s the goal? Are you getting to the protype? To Alpha? To Beta? To Gold? Are you delivering a website? An app? A service? Don’t let an idea drag you all over the map if you don’t want to go along for the ride.
  • How many hours per week are you on board? How many weeks or months are you available? If you are willing to get on board for free, you really have to set boundaries around how many hours per week you are available. In one case with me, I had to use the rest of the week to earn a living.
  • What skills you can practice? Sure, maybe you’re a coder or a designer. Maybe you also know how to set-up a corporation? Don’t inadvertently get wrapped up in a discipline you don’t want to practice. This isn’t about being selfish as much as it’s about being liable for the whole of the project-- if you over pledge yourself, you may find your time is lost on other matters and you cannot focus on practicing your core skills.
  • What technologies you are bringing to the party (don’t be the PHP guy who has to invent a replacement for TCP/IP)?
  • What do you expect to get (some money, some share of the company, some royalty for each unit, some swag, a job reference, a combo of these)? Speak up at the outset. Don’t revise the deal later unless the landscape changes.
  • What you are expected to provide (in one start-up I was expected to provide the hosting; it’s usually common that you are doing a bring-your-own-laptop in most situations)?
  • What do you expect of others? For example, if you get into a start-up wherein the other partner is going to sell the project to investors put that expectation into the mix up-front. You cannot enforce their good fortune or customer adoption of your start-up, but you can make them declare, “I will talk to 10 prospects per week.” if that's their promise. If they space out and don’t carry out their side of the equation, that may affect the overall venture. They expect you to deliver. Expect the same of them.

I feel that a start-up is a tremendous opportunity to take your skills and parlay them into so much more. I feel that real income comes from the customer model, not the client model. I feel that the Internet is still a terrific place to make money. If you feel the same way, I urge you to consider getting involved in a project.

Choose your project based on:

  • the idea
  • the marketplace
  • the team
  • what you can do
  • what you can get out of the deal
  • how this fits into your life’s goals

Oh, and I know one Angel developer: Me. If you have an awesome project, let's talk!
Tags: 

Last updated date

Tuesday, July 22, 2014 - 11:31