As a guy specialising on developing MVPs for people with ideas, here is the general list of rules I use before taking on a project:
1. Are you willing to pay my normal rate?
2. If so, can you convince me the market is there and you know how to address it.
3. Can you convince me _you_ are the guy who's going to be able to bring it all together?
I know that after rule 1 I shouldn't care, but with so many potential projects out there, I like working on ones I think will amount to something rather than spending two months coding and then having it all thrown away. Call it a personal satisfaction thing.
Fundamentally, the rules amount to equity isn't tasty.
Having done this type of consulting myself, I could never work around the maintenance issue.
You likely setup the entire system so if something goes wrong, whether its you're fault or not, you're on the line. It's all about reputation. And if you tarnish that by leaving a paid client behind when their server catches on fire, it will be remembered negatively.
It's hard to do this type of contract work continuously. You build up a portfolio of apps that you have to maintain. Most of the time you're clients are out of cash.
Equity is great but it doesn't put food on the table today. On the other hand it puts you in contact with some really great ideas and you get to play startup founder several times and you gain enormous perspective on what works and what doesn't.
Make it clear up front that you will charge for maintenance work, and if they can't afford it then it's a sad world, but you'll have to move on. You can try be nice and include free bugfixes for issues that are your fault -- this is nearly always a bad idea. You'll end up some some client that will be incredibly insistent that new features are actually bugfixes and all kinds of problems.
Always charge. People will respect you more, and any work you do for them for free will be abused. This is simple human nature - when you give away work for free, all you are creating immense confusion in the recipient. "Why did I get this for free? What's wrong with it? Is this guy so desperate?" This line of reasoning will quickly blossom in your clients mind, and before long your client will expect you to get up at 3am in the morning to add in some new feature he just dreamed up. When you refuse, his expectations of you are shattered and you will be remembered negatively - even when you just gave him free work!
Always charge. The less you need the work, the more your charge. The less you want to do the work, the more you charge. The more difficult the work is, the more you charge. No freebies, unless you make the reason extremely clear up front to prevent any confusion.
The other reason to choose projects that appear to have a decent chance of success is that the longer the project goes, the more work you'll have without having to go through the hassle of finding a new client, vetting their idea, doing the contract back and forth, doing the negotiating, and establishing a good working relationship.
There is also the excellent resume and street cred of working on a successful startup, possibly with name recognition, vs a 'failed' one.
Yes, that too. Funding out of pocket only goes so far, eventually there needs to be some sort of traction by either making sales or being able to attract investment. Without that, I might be out of a client sooner rather than later.
Out of curiosity, why do you specialize in developing MVPs for people with ideas, and how did you get into that type of work as a primary focus? Do you find that the work is more interesting than doing consulting jobs for more established businesses? Assuming you've found plenty of projects that meet your rules, do you have opportunities to become a co-founder, and have you considered them seriously?
I've done consulting, startups, and free work on side projects. At this point, if I find people and projects that meet my requirements, I'd probably prefer to become a co-founder and make a real go of it. I don't think I've ever taken a small amount of equity as compensation for substantial unpaid development work. Under those circumstances, equity is not tasty. I'd rather do well-paid consulting work or find a great team and go all in.
I actually also fix MVPs when they start breaking :)
Honestly, I just find working with startups and small companies in general to be more interesting, even though there is usually slightly less money involved. I got into this type of work by hanging around Hacker News and writing blogposts aimed at a hackerpreneur auidence.
It's amazing how many great projects you can attract if your writing is half decent and you have a good idea once in a blue moon.
As for jumping full in, yeah I'd love to eventually, but I've learned to be cautious and cover my bases first. Maybe when I have money saved up so I don't have to earn anything for months on end. Being young has its disadvantages.
I'm curious as to why the conversation about compensation for work done for "non-technical" upstarts is almost always framed as a binary "payment in equity vs cash" issue. Seems like there would be a huge market for MVP development by developers with a hybrid compensation model. (Maybe this is already common?)
For instance, a developer could quote Price X to non-technical co-founders to develop a simple, proof-of-concept MVP with an agreement to would receive Equity Y upon completion if the developer either (1) stays on for Period P or (2) helps the founders successfully land a more suitable, long-term developer to take over the project. The parties could even agree that Equity Y would be larger (e.g. 2Y) if the developer stays on.
Benefits to the non-technical co-founders would be (a) a proof-of-concept (or failure), (b) alignment of incentives with a developer to try hard, and (c) access to an insider to help find a permanent developer upon completion of the MVP if the MVP developer wants to exit (e.g. for a better opportunity).
The benefit to the developer would be (i) guaranteed fees, (ii) potential for equity (even if he exists) and (iii) flexibility.
More, a subsequent developer would have the chance to deal with someone who speaks his own language in the negotiation with the non-technical cofounders, and could avoid and annoying and/or exhausting translation of technical details.
An obvious objection may just be that non-technical co-founders never have money to pay for an MVP. I am far from an expert, but I would think that some do.
What you're describing is called vesting and is hopefully used by anybody doling out equity of their company.
The options for a developer in today's marketplace are such:
1. Technical founders who can offer equity only
2. Technical founders who can offer equity and money
3. Technical founders who can offer money only.
4. Non-technical founders who can offer equity only.
5. Non-technical founders who can offer equity and money.
6. Non-technical founders who can offer money only.
In either type of founder, the best option for a developer is equity+money, if they can afford a full-time commitment.
If the founder can only offer equity, this raises the stakes significantly and is a problem. Especially if the founder has overlapping skills with the developer. But the overlap of skills also breeds a certain camaraderie that is not to be ignored.
If the founder can only offer money, that makes it a clean [probably ongoing] contracting job with the flexibility to work on separate projects and whatnot.
The real problem with equity+money is that you are roped in full-time and tied down for an extended period of time. The reason I personally got into freelancing instead of having a normal job is that it gives me the freedom to change projects frequently - every couple of months. I advance quicker as a developer, grow my network quicker and my life is more interesting.
Knowing that I will spend the next 2 years working on a specific project is a very big commitment indeed and I want to be damn sure it's something I am extremely passionate about. (hint: this is usually reserved for my own ideas)
Perhaps it's just a sign of the times that I am happy taking on clients with no more than a few months' commitment and be certain that my bandwidth will always be filled to the brim for the foreseeable future anyway. In fact I am strongly thinking about expanding myself into a small team just to keep up with demand.
PS: there's also likely a bunch of legal and tax hassle in having my consulting company or myself be part owner of a bunch of other companies.
You're ignoring a powerful aspect here: Founders are cash-poor, but equity-rich (almost infinitely so).
I don't know whether you have enough money to cover your costs (I assume so, you sound quite successful), but I think it would be interesting to seek out promising founders and take a little bit of equity, instead of another "bunch of money"(tm). That increase in money is not going to significantly change your life, getting an early in at a startup might though. And in addition to that, you'll probably enjoy building that umpteenth MVP a little more if you have the feeling that the quality of your work has a potential stake in your future.
There's of course a lot of my making assumptions here, but I think it's an interesting thought to consider.
This is where my other rule comes in: "I am either a freelancer or a cofounder".
To be your cofounder you must also convince me that this project is something I want to spend the next several years of my life on and it must be great enough to convince me to drop other projects and start working on this full time. I don't believe in part-time cofounders, that way lies burnout and failed projects.
And despite all that, equity still isn't tasty so I will need to earn at least some of my normal rate anyway.
Would you ever consider being a cofounder before the MVC is built?
I guess you're saying that you'll only build MVCs for cash, but then will consider joining as a cofounder afterward if the project looks promising and you can work out a fair equity agreement?
I guess it depends. I usually have enough of my own pre-MVP projects that would love some attention and often some that are MVP's and would also require attention.
But building a MVP together before jumping into a full blown partnership is also rather important in terms of finding whether there's a general fit in working together, you're actually able to deliver on the non-technical aspects of the project and so on ... MVP's are also incredibly good at confirming assumptions about the market.
This is the part about equity that is most likely to bite you in the ass if you receive equity but ultimately do not control the allocation of it. (Common for early employee or founders on the technical side of things).
Day 1: Awesome, I own 10% of this company. If it sells for millions I will make a significant amount of money!
Day 630: Due to the "almost infinite" nature of equity and dilution, I now own 0.05% of the company. If it sells for millions I will be able to buy a cup of coffee!
If you go for this sort of deal you should always have some anti-dilution protection. Otherwise as is pointed out the equity is essentially worthless. You can use some sort of full ratchet clause or ensure the majority shareholder can not issue more shares (though some special resolution requirement). You'll need a lawyer...
1. Are you willing to pay my normal rate?
2. If so, can you convince me the market is there and you know how to address it.
3. Can you convince me _you_ are the guy who's going to be able to bring it all together?
I know that after rule 1 I shouldn't care, but with so many potential projects out there, I like working on ones I think will amount to something rather than spending two months coding and then having it all thrown away. Call it a personal satisfaction thing.
Fundamentally, the rules amount to equity isn't tasty.