Remuneration options as developer for upcoming job

updown123

So,

Here we go again. I always come across threads about ideas by businessmen and about getting developers involved, this time i'm coming at this from a developers perspective.

I have been approached by a guy to develop an app for him. I'll grant him that it is a good idea and fits into his niche business to which there is a decent market in Ireland.

First off, he wanted to know how much it would cost. Later, he then went on to mention some kind of royalty, not implying that it be an alternative to cash payment for work, just an extra. I think the reason for this is that he doesn't just want a quick job done. He is not a tech guy so wants somebody techy to be alongside him when needed.

I'm stuck here now, trying to figure out how to quote. My options are:
- hours effort * hourly rate = cost of app. Job done upon delivery.
- hours effort * hourly rate = cost of app & also some kind of ongoing management fee for monitoring of system the fee could be flat per month and include a number of hours or instead of cash, I could do the management but get a slice of each registered users fee.

I guess my main question is, what are the typical models that a developer can use to retain some kind of income post development. e.g. royalty, equity, management fee, feature/bug maintenance etc.

Thanks.

The Corinthian

Forgive me if I go a little off-topic to begin with, but it'll make sense later.

With start-up scenarios, there are typically three remuneration models:

• Financial. Straight up T&M's, typically at an hourly or daily rate with whatever agreed expenses incurred added.
• Equity/Royalty. Either ownership of a percentage of the company and/or a percentage of gross (ex-VAT) of revenue for some period of time (fixed, ongoing or for the duration of work).
• Hybrid model. A mixture of the two above where financial remuneration is partially replaced with equity and/or royalties of a comparative value.

As such your first port of call is estimating a fixed price for Financial remuneration. Research different models for both development and SLA's.

Then taking into account the potentially greater return from equity or royalties, taking into account risk. From that you can estimate an effective financial value and thus exchange rate when calculating a hybrid or equity/royalty model.

Developing a solution, be it an app, Web site, software solution is straightforward as it is finite; it'll take X hours to produce Y functionality, so it lends itself to the use of Equity more. Subsequent SLA's though are often open ended, so equity doesn't work well in an open ended SLA (what happens if you earn 2% equity per month from it and you're supporting the app for five years?).

It's also important to note that equity is not really an 'income'; it's more an investment with slightly better odds than the Lotto. Most start-ups fail. Even those that don't can potter along for years never making that much money. In fact, the only way you'll see any money from equity is:

• A sell-out. Naturally this is the winning the Lotto scenario, although the company could end up sold for as little as a Euro if in debt. Even if lucrative, a sale can take years to happen, if ever.
• Dividends. Don't hold your breath. Start-ups can't afford them and even as more established SME's they are few and far between (easier for the executive directors to raise their salaries).
• Buy-back. If you're a non-executive shareholder, then don't. I've seen buyouts where the directors want to get rid of a sleeping partner who has executive power, but if not, the only reason they're offering to buy your equity is because they're planning or have already an offer for the company and they want to get your share back on the cheap.

Royalties, by comparison, require a certain level of monitoring and contact with the venture, so if you earned this by developing the initial solution and then parted ways, it becomes more difficult to know what's going on and if you're getting what you're owed.

Just bare in mind that the revenue model of many start-ups is foobar to begin with, so you could be getting little or nothing by way of royalties, once they start - which could be a while. Additionally, many start-ups end up changing their business model; charging doesn't work, so they switch to advertising which does. This is fine for the company, but not for you if your royalties are tied to revenue from the former.

But overall, your first step is to calculate what you would charge for the work if it was cash only, as it were. Use that as a basis for valuing your work against equity/royalties and then find a model that works for both parties.

updown123

That's a great overview, many thanks.

I'm coming up with a cost for development of the initial project now. As with anything there is a bit of maintenance of the system, minor fixes etc. I think I'll charge a royalty per registered user to cover this. How does that sound?

Frank Lee Midere

updown123 wrote: »

That's a great overview, many thanks.

I'm coming up with a cost for development of the initial project now. As with anything there is a bit of maintenance of the system, minor fixes etc. I think I'll charge a royalty per registered user to cover this. How does that sound?

Unless those users are paying the business for the app I can't see them going for it.

By and large these business types with "ideas for apps" don't really understand the cost of a mobile dev these days. When you give a quote he will just try and outsource. I gave up on this years ago.

The Corinthian

updown123 wrote: »

As with anything there is a bit of maintenance of the system, minor fixes etc. I think I'll charge a royalty per registered user to cover this. How does that sound?

Honestly, I've no idea. Devil's in the detail.

Whether you target registered users, revenue, or whatever depends upon a few factors, but principally that (a) it'll make you money, (b) won't be too unattractive to the client and (c) does not put you in indentured servitude in the long term.

For example, say the business model is users can register for free and once registered can pay for services. Clearly the conversion rate from the former to the latter will be fractional, so getting paid on the basis of registrations is more attractive for you. However, then the client would be paying out for users who have not parted money yet, and so this model may be unpalatable for them.

Secondly, say no one (or almost no one) ends up signing up or there's a few at the start, then it peters out - it happens a lot. This leaves you in a situation where you're maintaining the application effectively for free, and if you don't have an exit clause, you'll be maintaining it for free forever.

I suggest you sit down, crunch your numbers and consider the various scenarios. Then consider what your client is likely to agree to or not.

Meritor

Though I have not developed any mobile app so far, I had developed many desktop application.
How I used to charge is:
Total cost of development with/without Code given to client.

With Code:
1) I am free from all my responsibility once client accepts and confirms that the application is as expected.
2) I also give them six month free service to fix any bug and for minor changes. Definition of minor/major changes varies as per application and client.
3) Any major changes will be charged as per effort required. i.e. a new contract.
4) Any changes after 6 month, be it bug fix, minor or major changes will be charged as per effort. again new contract.
5) In case of just configuration required, I charge per visit.

Without Code:
1) This is as good as I am the owner the application and selling a copy.
2) Even in this case I give them six month free service to fix any bug and for minor changes. Definition of minor/major changes varies as per application and client.
3) Any major changes, i.e. upgrade to software will be charged as per effort required. i.e. a new contract.
4) Any changes after 6 month, be it bug fix, minor or major changes will be charged as per effort. again new contract.
5) In case of just configuration required, I charge per visit.
I generally do this when I found that the application can be sold to another client(s) and quote less amount current client stating that I may sell this application to another user. I sometime give copy of code to the client if they insists with some extra amount.

There is another approach that can be used is AMC i.e Annual Maintenance Contract
In AMC you may define all your terms and condition..
1) Type of changes / fixes covered under AMC
This is an important aspect to define clearly. One should cover detail list of possible changes / fixes that will be covered under this AMC. It is better to define what will not be covered under AMC. This is important because there are client who can ask to change whole application functionality twice a year.
2) Payment terms (monthly, quarterly etc) and conditions
3) Define development boundaries. Time or number of Changes / fixes. i.e. How frequently the changes should be made. e.g I client asked for a small change to day by the time you finish it, the client may come with another fancy idea to change that once again.

updown123

This is great advice, thanks Meritor!

I will definitely consider the three approaches.