Customer does not want to pay for my learning curve [closed]

Question

An acquaintance wishes to contract me for a small embedded programming project. I have not done embedded programming in many, many years.

He had, naturally, asked me for a cost estimate. This field being kind of foreign to me (these days), I said I could not give him a reliable estimate.

He said he would feel much easier if I did not bill him for my learning curve. I said this very rarely happens in the industry, that the learning curve is a very large part of our work, something client pays for. He very reluctantly agreed, but I could see he could change his mind any moment - and this little project is fun and I could not resist it. So I said, OK, you don't pay for my learning curve then, and he beamed and said he is a very fair person and will compensate me fairly. (I believe that, but what is fair to a non-programmer? Don't know!)

Looking from his standpoint, I understand where he is coming from. He knows next to nothing about me; he probably can't grind me with a good tech screening, so for all he knows, I could be clueless and bomb the project completely; I could end up costing him an unknown amount for an end result of uncertain value, and would not give him not only a promise, but even an estimate. That can be unnerving. BTDT with doctors, lawyers and such. Real hit or miss.

So it's been 9 days since, I've been programming obsessively around the clock, still have not given him an estimate (perhaps this is my main mistake right here, but I can't give an honest estimate of what I don't know!) and I realized that my actual work, not counting learning, is so tiny that, knowing what I know now, I could have done it in an hour. Now what? Bill him for an hour? Of course not!

Have not given him the code yet, either; intend to keep it this way until we come to an agreement.

The guy is a very nice guy, and we both intend to resolve this fairly; but our expectations at this point are so vague, I fear the possibility of a major mutual disappointment.

We are on a handshake agreement at this point. No papers signed, not even an NDA yet, even though I know all his IP, and he cares about his IP a lot. So yes, I believe he trusts me. But from the past experience working on a handshake with a non-programmer, this trust could evaporate instantly should any misundersatanding arise. I don't blame him: he is risking too much.

The thing is, what constitutes "learning" is open to interpretation. Just getting back to speed with embedded systems? Learning this particular microcontroller? Learning this particular protocol? Is software design "learning"? We have not discussed that, and it's widely open to interpretation.

I suppose I could split my learning time into non-billable (something an embedded programmer would expected to know) and billable (esoteric things that only a small minority of people know). But this is vague.

What should I do? I don't have much experience working for small clients.

Edit Some people felt it's unclear what I am asking. Sorry. I am asking how to

1. get paid for my work
2. without alienating the customer
3. by communicating to him my POV on what's fair and
4. building consensus while
5. meeting his needs and
6. making him feel secure his needs will be met, at this early stage.

Answer 1

IME your situation is typical of an owner operator type business. The skills are specific to their business, and every cent they spend hurts them. It seems that you started out well, on the basis that the combination of what he wanted you to do, and the unusual system you wanted him to do it with, meant that he'd be paying you to learn. But then you were persuaded that he shouldn't pay you for that, only for your eventual "expert time".

It might help to explain that programming is design if not research and development. Sure, you can sketch a high-level design, but without either experience or experiments you have little idea of the details of the design, let alone the size of the finished product (which is what, an executable?) There's almost never a time where you say "I'll use pattern A, pattern B and link them using framework X. I estimate 1800 lines of code". Which is what most engineering design looks like at the planning stages.

At this stage I think you really have to go back and say "This is more work than I can afford to do as a hobby, or on the off chance that eventually I might get paid for it. I'm willing to hand over what I've done if you pay me for the time spent. But unless you're willing to pay me from now on, I think it would be best if you found another programmer". The problem is as much the pattern (no result = no pay) as the specific case ("I'm learning, not coding").

You don't have the experience to give a solid estimate, otherwise now would be the time to say "I'll deliver X for Y money". If you did that one of you would get screwed, and I'm betting it would be you.

If nothing else you need to lay out concrete expectations and review them regularly. This is where weekly meetings where you only review what's been done and lay out your plan for the next week are key. Try to avoid demonstrating code, this is an office meeting where you talk, not a product demo where you show. But meeting every week and you saying "I have done X, here is my engineering notebook and my project plan", and him paying you, means you both have a good idea of where things are. But again, this is research, so you're not going to be able to say "I am 123 hours into the 456 hour project, therefore 123/456 % complete".

Here are three options that might work:

1. He lends you the hardware and you build some kind of hobby project for that system. Something that he can't use, to make it clear that this is your learning process. Then he pays you a decent hourly rate for everything else, whether it's research or typing.
2. You keep on as you are (perhaps with more non-working time in your life), and he pays you a slightly lower hourly rate while you learn on the job.
3. He pays you as a consultant to help interview and find another programmer. If nothing else that market survey will help him re-calibrate his expectations of how much this will cost, and how common the skills he wants are.

One option that definitely will work: quit. You've learned that picking up a whole new skillset while working for a friend is not a good idea. He's learned that getting a non-expert but expecting them to work like an expert doesn't work.