Lessons Learned the Hard Way

At the Atlanta Real Studio Summit a few weeks ago several presenters were showing off beta code or showing code that they had modified earlier in the day.  Of course you know what happened – there were embarrassed developers saying, “I swear, it just worked a minute ago.”  It’s the Law of Demo’s and happens as soon as you use code not thoroughly tested before you show it off, or when you veer from your script.

When I told my son that they violated the Law of Demo’s he replied rather quickly, “Oh, you mean they tried to modify their program the day of the presentation?”  Smart kid, but then we had learned that lesson the hard way during our First Lego League robotics season.  Trust me, there’s nothing worse than your team (full of 9 and 10 years olds) feeling horrible because they didn’t keep a backup and the modified program just doesn’t work.  Lessons learned the hard way are always the best.

The same goes with consulting and contracts.  I’ve recently been in a spat with a client over unpaid invoices.  Because this person was a referral and well known to many in the Real Studio community I made a verbal agreement to do a lot of work for him.  It was a Web Edition project, which was new to me at the time, so I agreed to a lower rate since it was a good way to immerse myself in a new technology.  In general, I thought the project went rather smoothly while using alpha and beta editions of Web Edition.

Normally, all communications are via email and text iChat so I have a record of all conversations.  This client, however, likes to talk via video iChat.  The drawback is that iChat doesn’t automatically save these (there is an option but I didn’t find out about this until I started doing the research).  So now that the project is done, the client is 60+ days past due on his invoices and is *surprised* that he has a large unpaid balance.

How he can say this with multiple invoices being emailed automatically and the multiple emails and phone calls trying to engage him is beyond me.  He now claims there was a spending cap on the project and says he ‘told me this’ early on.  Right, I would have agreed to two days on-site coding (after a months worth of offsite work) for him since those two days alone are higher than his supposed cap.

The funny thing is that after the project was done he still tried to engage me to do more work.  Unfortunately (or maybe fortunately depending upon your viewpoint) the hourly rate he wanted to pay was so low that I couldn’t have made payroll.

The lesson learned is never to do anything verbally when it comes to money.  At a minimum, after a video chat and/or phone call, send an email confirming the details.  The paper trail, while a pain to maintain, is the only way to cover your bases.

A contract is better, of course, because that’s a legally binding document.  The sad thing is that I presented on this very topic at multiple REAL World conferences so that means I obviously didn’t learn my own lesson.  But then I guess I was blinded by the connections this person has with Real Software (not that I hold them responsible) and the community.  The referral was from a trusted colleague too which made it ‘safe’.  When money is involved there is no trust.

As a word of warning, this person is trolling the forums looking for Web Edition coding help.  Make sure you get a signed contract from him before doing any work.  Get everything in writing, which, of course, is good advice for all business dealings.

Will I get what’s owed?  I sure hope so but somehow I doubt it.  Regardless, I’ve relearned a valuable (albeit costly) lesson.

5 thoughts on “Lessons Learned the Hard Way

  1. I recently re-learned this lesson with a friend of mine. First, I knew he was difficult to please based on past conversations and his complaints about other vendors. Based on this knowledge, I didn’t give him any discounted rate because I knew he’d be difficult. I also didn’t give him a firm bid because there weren’t any specs, the program was to draw from web services from 5 different companies and their requirements were unknown.

    When I develop I like to make weekly releases to the client, even if things are broke and crash. At least they’re seeing my progress and direction. I made the first couple of releases and he liked how things were progressing. After that, I wanted to keep releasing to his machine but he was too busy and wanted the next feature and the next feature. I normally invoice every two weeks but without delivering, I held off on invoicing one cycle. By the time I invoiced him next cycle, and he still didn’t want the program installed on his system he balked at the invoice amount.

    To save our friendship, I offered to forgive the invoice and he would agree not to receive the application. A waste of time and effort all around. It’s too bad too because the program was working nicely, it was just going to cost more than he thought it would be.

    Lessons learned and I seem to keep learning them.

  2. We’ve been going through this a bit too. I think the solution is to require a retainer for all or a portion of the work. Then you can perform the work after you have received the funds. At anytime you can refund any balance.

    The trick is tracking on hand funds with work to be performed…

    Hal

  3. Ouch!

    I have my own scars from times that I didn’t chase invoices, failed to invoice on time or failed to chase up a supposedly solid client about slipping payment dates. The last of those, and by far the most bitter, was the one where I was being “understanding” about their slowly sliding payments because of the GFC and then was distracted for a few months by my Dad dying of cancer. That last one was also a complicated circumstance because I trusted someone with whom I’d established a good personal relationship but didn’t realise they weren’t in control of the money in their own company and weren’t willing to go to the wall for me.

    It’s interesting, now I’m working for Gemcom which is a big company (revenue in the tens of millions) to see how we get monthly reports to *everyone* which include how the company is doing on receivables and the percentage of receivables at 45 days or higher.

  4. Number one rule in any business: get the job specs. in writing. Even a scribble on a back of an envelope initialled by both sides, because with the best will in the world, in a verbal contract both sides can genuinely believe they have agreed but both have actually agreed something different to what the other has, and the problem just gets worse as time passes and memories fade or get confused with other discussions.

Comments are closed.