Making sure you get paid

I’ve been thinking about this for a while, and with the recent thread about recruiting scams, I thought I should post this question:

If you do custom development work online for a customer at a remote location, how do you ensure that you get paid?

I know a number of people that do work online for clients at distant locations and seem to do well. But I also know one or two people that have done work for big well known companies, and had a terrible time getting paid.

I have not had any real trouble. My biggest problem was many years ago and the customer was GE. They always paid but they were always about 90 days late. Somebody told me to give a discount for early payment so I built a little extra in the price and gave them 2% for paying in 15 days and they always mailed the check on the 15th day.

You can put a license code in the software with an expiration date and if you don’t get paid it quits working. When you get paid you can enable the license to not expire.

First, make sure you have a contract with a clear payment schedule included. Lawyers love those.

Don’t wait until the end to get paid. In fact make sure your last payment(s) are purely profit. That way you’re not starving while you duke it out (and less likely to settle for a fraction of the agreed price)

Have a minimum charge. I know it sounds cheesy, but when you have a base, let’s say $10,000, it helps you weed out the projects that are too small and the cheap customers who keep tacking things on.

Make sure there’s a detailed project spec so you know what you’re doing and the customer knows what to expect at the end. Anything above or beyond that spec should be considered a Change Order and have an additional charge associated with it. If you don’t do this, they’ll thing all changes should be free.

[quote=327033:@Mark Strickland]
You can put a license code in the software with an expiration date and if you don’t get paid it quits working. When you get paid you can enable the license to not expire.[/quote]
Careful with that. Companies don’t take well to ransom after the fact. Work for hire is different than writing software that you sell. It’d be better to hold delivery of the final product until you get a final check.

A friend of mine had a situation years ago (mid 1970’s). He had contracts with various car dealers in San Diego to do all their custom programming (this was the advent of small computers, so Ford and others did not yet have corporate level software like today). In Los Angeles, there were two brothers that did the same thing for dealers in that area. Those LA guys ended up with a contract for a dealer in San Diego. That dealer decided to NOT pay that last 1/2 of the contract (about $8,000 if I recall). So on the way off the premises, they reformatted the computer (turn a key and press a button). They then contacted my friend, and told them who the dealer was, what they had done and why, and gave him their software, on the condition that if the dealer called him, they just wanted their $8 grand. Month later, the dealer calls, my friend said, sure, but that he had heard what had happened, so he wanted to be paid in full up front, oh yeah… and it will be $20 grand! They said NO… He said fine… few weeks later, they called again and agreed. For the next few weeks he’d show up, lock himself in with the computer, and work on OTHER projects he had… The after enough time passed, he installed the original software, and walked away… The LA guys got their $8k, my friend made $12k for doing “nothing”, and the dealer learned don’t mess with a developer … Yeah, the dealer tried to sue the LA guys, but their lawyer explained a few things (as in the payment wasn’t made, so no product needed to be delivered), and they dropped it.

Sorry for the long (ancient) story… but in those days things were VERY different than today.

  1. Have a clearly defined target; Before you do anything, you write up exactly what you are going to do, in as much detail as it takes for both you and the client to fully understand what it is that you are going to do.

Only once did I have a problem whereby what I did was not what the client expected, in order to retain the client I swallowed the loss, but ultimately it didn’t work out between that client and I.

  1. If it’s a long term project, make sure that the client understands you’ll be submitting evidence of work on a regular basis and that the client has x amount days to settle. If the client fails to settle within the time frame, the work ceases and should the client refuse to pay, you lose as little as possible.

  2. Trust your gut; if you feel something is wrong with this client or they start badmouthing other developers, walk away. IMHO it’s the clients who act unprofessional who’re going to treat you poorly.

Absolutely; always have a contract that explains your terms and conditions. However as someone who’s gone through the legal system more times than I should have, unless the contract is worth 10s of thousands and the client owes you that much money, it’s not worth it. The legal fees can cost more than you’ll ever receive. Worse yet is winning and then the client is not only broke, but has no tangible assets anyway (which is what happened in the last legal case I was involved in).

Best bet IMHO is to be on the defensive; never put yourself in a position where a troublesome client can take advantage, follow everything up in writing with clear descriptions.

Yes. This has always been my number one rule. That’s probably the main reason why I started this thread. For my past work, I’ve always gone out the the client’s location where I could meet face to face and see their operation. It was a big help in sizing them up. Dealing with a client that I’ve only communicated with online is a whole other ballgame for me.

just happend to me this week but not by an unknown scam-something but by a well-known local software contractor working for some big incs. I was asked if I could do something for macOS. Yes of course. But there were some stuff beyond Xojo. So I had to bring in an additional Developer. In several mails and phone calls back and forth I tried to get more information on this topic but all conversations ended up in something like “sorry can’t say this, you know NDA, just give me your price and time estimation”.

But this doesn’t work like this. How to calc something with too much unknown variables? So I offered him a quote for signing NDA and to get the things sorted out. It was just a quote for a single working-day, not thousands of Euros. You already might know his answer:

“I have a bad feeling about this and after your offered day I still do not have anything in my hands. Sorry I take a cheap student to do this for me.”

My short reply: “you’re welcome, give shout when you’ve changed your mind”.
Everything else I thought would break forums rules if I would try to write it down here.
Somewhere out there is an student, wasting his best time of life for something less than minimum wages.

… and if you planned one day of work, it will surely take him a good 15 days to achieve some crap program …

You know we all were young and hungry… we ripped ourself in pieces for a good project… and I remember those days where we hacked a week long, slept in the office and had joy and fun together… but in the end we always were paid well.

The contract is a must. It defines what is deliverable and in what timeframe. A good contract will spell out as much as possible including what the client is responsible for. I also put in an assumptions section detailing what I am assuming (like some bit of hardware is actually controllable via a Xojo application, for instance). Our contracts also include payment terms.

Every project we do involves some payment up front. It establishes trust with the client (if the check bounces or they are really late you should think about cancelling the project). Depending upon the size of the project we will then have payments at a specific deliverable (milestone builds for instance), or time period (every 80 hours), and what the final payment will be. It is only after the final payment do we hand source code over because if you give it to the client before that they could just walk away and you have no recourse.

Don’t be stingy on your rates. You are not only getting income for this project but income in your next down time, and when you want to go on vacation. Don’t believe a client when they say, “this is the first project of many.” It might be, but if they wheedle you down now they’ll be able to do it later. They come to you for your expertise - charge for it.

The other experience I’ll share is that if a client complains about your rate at the beginning it will never get any better. This is a red flag because they will always be questioning the bill and complaining about it. One client comes to mind where their software was their entire income stream for a good sized small company. They came once and got an estimate and left saying it was too high. Six months later they came back for another estimate (same project) and left saying it was too high. Came back again about a year later (and after another Xojo developer attempted to fix their problem) and had the audacity to ask us to fix the previous developers mistakes and assumed the estimate would somehow be less than the previous estimates. I doubled the estimate and they stopped coming back but I’m assuming some poor sap got stuck fixing a project for a lot less than they should have charged.

I can’t tell you how many times I’ve heard of Xojo developers getting screwed out of the money owed to them. Some of them didn’t create a contract. Some of them gave source code early. Some of them didn’t get any money up front. Some did all of the above.

This community is small and friendly. If you have a bad feeling about a client ask around. You can contact me, if you want, and ask for advice. I may not always be right but I’ve been doing this for a while so more than my fair share of warning signs.

And who probably isn’t even capable of doing the task. I’m not the smartest guy in the room, but even I know that there’s no comparison to what I knew was I was a student. If only I still had the body of a teenager… Now that just sounds creepy :slight_smile:

@Bob Keeney - good story Bob. Could you give some advise about how to treat potential customers coming and knowing only one thing: they probably need software to solve their problem. Offer a business consultant ?

Treat every prospective client like they might be in your life for the next 10 years. We have one client who’s had ongoing development that takes nearly 75% of one of my developers time for nearly 8 years now. We know his product better than he does and clients want to be assured that a) you can actually do what you say and b) aren’t going to rip them off.

These things are hard for the new developer to prove because they don’t have the history. We can provide half a dozen references that are willing to give us a reference. We make sure to contact our reference just to be aware that they might get a call.

Anything talked about verbally must be followed up with an email. We’ve learned this the hard way. Nothing said in a phone call (with new clients) is valid until they’ve agreed to it in an email. That way there is no misunderstanding.

Perhaps there is something more specific you’re asking about?

And something more to add… own your business! 17 years ago I’ve had 50:50 business partner. The plan was he aquires new customers and I do all the operations stuff in the back-office. We’ve had 5 employees on the payroll and 5-7 more as freelancers. One day he stopped bringing new customers in and started doing nasty things in the office. Suddenly he knew how to develop programs in term of knowing everything better. This was my “hard way” to learn. Since then I am better a dictator ruling over my own realm.

Plus one for NEVER doing any of the above!

Great advice from everyone so far. The key is getting paid before you do the work.

Our process is talking about needs, creating a ballpark estimate, then providing either an hourly estimate or fixed price. In an email, along with the cost, we describe how we work and what we expect but we almost never create a contract. We rarely have problems since we’re upfront and won’t work unless we have funding. We try hard to focus on long-term relationships and not having a contract seems to make the relationship friendlier. It’s probably a better idea to have a contract, but we haven’t needed them.

You don’t need a contract until you REALLY need one. Without a contract nothing is legally binding because a client could turn around a sue you for practically anything. Without that contract it’s a matter of your word against theirs. Without that contract I think you’re gambling your future away.

A saying in Germany: Contracts are not for the good times when everything is working fine. Contracts are made for the bad times, when everybody is pissed and nothing works as expected.

Here’s a simple rule: Accept the payment only in one final installment, and make it clear it’s not free software. That way, if the customer does not pay, you can simply tell him that he has no right to use it until he pays for it. If he uses it regardless, you can sue for damages. That threat alone works wonders, in my experience. That’s because no one works for free. If you didn’t get ANY money, it’s clear to any court that the user has not right to it, and it should be clear to any customer that it’s a huge risk to go that way. Disclaimer: That’s me being in Germany. US law may suck and frack you.