After spending 200+ hours developing the system, not a dime has been seen or given
Freelancers should always try to get at least a deposit upfront. When I was freelancing, I would get 100% upfront for projects under $500, 50% upfront for projects between $500 and $2000. For projects over $2000, I would get 25% upfront, and then set milestones with payments attached. I had a $7500 project once where the guy made the first 25% payment, I completed the first milestone (graphic comps and UX flowcharts) then he disappeared for a year, not returning phone calls or emails. He then contacted me out of the blue and made the second payment, and I completed the second milestone (HTML/CSS/JS coding), and then he disappeared permanently. Clients like these are exactly the reason you need to get some payment upfront.
We're a small company relative to the kinds of companies who usually contract out dev or tech work, and we will pay something up front. Probably closer to 25% than 50%, but we wouldn't get mad if you asked 50%.
I'm saying this as a data point for people just getting started who might be nervous about asking for payment up front. If we'll do it, I'm sure many other people will too. It's a reasonable request.
On the other hand, just so you know: we never ask for payment up front for our services, ever. That's because we'd almost never get it. Most companies with in-house finance and/or counsel aren't going to pay you anything in advance.
If I were freelancing, I'd ask for up-front payment, but I'd let the issue drop for any company I knew was large/established enough to pay me; if I was in a relationship with such a company and doubted the project really had legs, I'd just walk from the project.
An additional wrinkle is that oftentimes it can take a while to set up the mechanics of payment with a first-time client. So even if there is goodwill on both sides and a willingness to pay an initial deposit, you might not see the money until you've done quite a lot of work.
Since a lot of contract work is time-sensitive, waiting for payment to clear before starting work or handing over an initial milestone might not be an option. There's a tension between the desire to make a good impression on a first-time client and the desire to make sure they're not taking you for a ride.
Fortunately there are often warning signs when a client is going to be particularly difficult, and there are far more decent clients than unsavory ones.
This is a great thing to keep in mind before any of you think of writing an outraged blog post when a client doesn't honor Net+30 on your first invoice cycle. Clients usually don't.
oh man, this. So I've been doing contracting forever; usually direct to smaller companies or through a middleman who was also pretty small. And most of the time, smaller companies are pretty good about paying on time, and pretty responsive if you say "Hey, this is really important to me, I've gotta pay the power bill." (my power bill, well, let's just say it could buy my car every month.)
At my first contracting gig using a body shop way larger than I was, well, they'd kinda sort of start thinking about paying me 30 days after they got my net 30 invoice. This /really/ bothered me. In fact I made a lot of unprofessional noise to the client, and ended up staying home, once, until they paid me. The thing was, I was really worried that they weren't going to pay me at all.
It did not occur to me that this was just standard operating practice, and that they were planning on paying me; they just wanted to stretch it out a bit.
They might not even be trying to "stretch" it (a large company could give a crap about the float on an indie consulting invoice); they might just run accounts payable on a state machine in which the part that elapses a timer hasn't started yet. There might be all manner of reasonable reasons for doing it that way; for instance, if they accidentally release payment early, they may screw up projects by blowing expectations.
In any case, yeah: some of your best clients will do a terrible job paying you on time. 'slife in the big leagues.
I once worked in a bank doing tech support and occasionally fixed a few things in the sealed-off internal finance room. The place was littered with red final notices - including utility, phones, everything. As a bank they could easily put to use any extra cash they had, so the official policy was to pay everything late. No doubt everyone knew they would pay eventually, but when you're big you don't have to.
When I freelanced one of my customers moved the accounting to SAP, which had the unfortunate consequence that they didn't pay me for four month.
It was, however, a reputable, well known firm and I had no reason to believe that they where playing games or trying to bullshit me.
I was right and got payed in full when the glitches got ironed out. Nevertheless, it was a tad annoying and part of the perils of a freelancer, I guess. Thankfully, while being persistent with their accounting department I never blew up and always stayed civil.
Very much second that setting up the invoicing for a new supplier can take time, especially at multinationals or other large firms. I can understand this due to the fact, that procurement is one of the most sensitive areas when it comes to fraud and dodgy invoicing. Thus firms set up a lot of safeguards before actual money flows.
Do you think their accounts payable operation froze for four months, too? Didn't think so. Somehow even that big, complicated SAP migration can keep critical business operations going.
In the UK at least, you may be able to start charging statutory interest after the the second +30. Whether or not you think that's a good idea is up to you...
What do you think of putting less than +30? I've only ever done any large work with long standing clients that pay quickly. Would the majority of clients not agree to it? Could be a way to ensure that it ends up being +30 even with the client dragging their feet.
You can ask for whatever you want. You'll only run into problems with BigCo's if you do one of two bad things:
* Refuse to sign unless the BigCo agrees to your payment terms.
* Actually expect the BigCo to perceive time elapsing in a way that will get you paid in 30 +/- small n days.
They won't get offended when you ask for net+15. They might even agree. But you're getting paid when the stars align, not when you think the contract says you're getting paid. Established consultancies devote a small but palpable bit of effort managing this issue.
I did business with a department which was in the process of spinning off from a big Fortune 100 company. They had plenty of funds, but there was a lot of bureaucracy during the transition. As such, they told me they 'required' net-60
I asked for clarification, and they were apologetic about it. They could only run payments on a 60 day schedule. Solution: I billed net-30, 15% monthly surcharge for late payments, which they happily paid.
The lesson was that sometimes a client has no choice but to drag their feet, so be sure to give them that option (for a fee).
Chances are, anybody new to consulting with BigCo's can build that "surcharge" in without any negotiation at all: just jack your rates. You are almost certainly wildly undercharging as it stands.
Since a lot of contract work is time-sensitive, waiting for payment to clear before starting work or handing over an initial milestone might not be an option.
Sums up my life as a contractor. The most profitable projects were also the most time-sensitive(the start now types).
Then again, I sucked at this. And so I took my first full-time job.
Good point. Its hard to believe how long it can take to get set up as a vendor in QuickBooks/with accounting, (i.e., "get you in the system"). But once its taken care of (after you've been paid once) payments become more timely.
Just to add a +1, we're also totally OK with paying half upfront and half on delivery. Milestones are fine too if that's what vendors prefer, but I think 50/50 is easiest.
Once we've worked together, I'm happy to pay 100% upfront for anything < $2k. Its an easy (~free) way to improve the relationship. I recommend it to anyone who contracts out.
On the other side, we usually ask for 50% from new clients, but will let it drop if there's a good contract in place and/or we've worked together a bit. Much more concerned with getting paid than cashflow.
Agree that big companies are never going to pay upfront, it will be net 30 at best, take it or leave it. But never do anything on net 30 without a purchase order (PO). It can take a while (months, damn the invoice date) but you'll get paid eventually.
Where is a good place to learn the ins and outs of contracts? Is there a comprehensive website or book that you can recommend? I am early in my career and have been on both sides of writing contracts. While I am figuring a lot of things out as I go it would be nice to sit down and wrap my head around this for good.
Also, to the OP, is a few weeks really enough time? If those were 200 billable hours it seems like it's worth a tad more hunting.
Where is a good place to learn the ins and outs of contracts? Is there a comprehensive website or book that you can recommend?
The freelance kit from www.sitepoint.com is where I learned a lot about techniques for freelancing. That's where I picked up the technique for deposits and milestones. In fact, one of the best pieces of advice I got from there was never to be the lowest bidder. There was a project we were bidding on, and the client ended up going with us even though we were the highest bid ($8000). He showed us the other bids, and they came in at ($1600, $2800, and $4500). He liked our proposal for a few reasons: One, the other 3 bids were just Word documents or PDFs attached to email. Ours was printed in color, bound, and sent FedEx overnight. Another, we had detailed writeups of 3 previous projects with testimonials and phone numbers of the clients (used with permission). Lastly, we had suggestions for additional features to add, with a cost/benefits analysis on each, along with suggestions of features that could be cut to reduce the timeline or cost. All of these were suggestions from sitepoint's ebook.
I've run my own marketing firm for the last few years and have dealt with similar issues as the OP.
How you structure up front payment is always up to you. We've always had a setup fee, typically a few thousand dollars, which is due before any work starts. However, there has been one single thing which has kept our revenue flowing month after month for years: Freshbooks.com
I seriously love that site. We use it for:
1. Making estimates
2. Tracking hours worked against estimates
3. Invoicing based on hours and services rendered
4. Making sure the client indeed noticed the invoice - it says "viewed" when you send by email and they actually log in and view, so you can call bullshit when they say "I didn't get it yet!" :D
5. Automatically adding late fees to invoices. We charge a relatively nasty fee each month for a late invoice and it automatically adds it to each one.
6. Tracking payment; clients get notified via email when payment has been received, something many have commented on as a great feature.
Quickbooks and other tools are all well and good, but imho I think Freshbooks pretty much handles 90% of what you need to be successful independently :)
We charge anywhere from 5-10% each month, stipulated in our contract. This takes care of 90% of late payments as no one ever wants to pay that much in a late fee...and they are unwilling to say it is too high because the immediate reply is "why would you worry it is too high? You aren't planning on being late when paying, right?" :D
This is a good video about contracts. It's targeted for designers, but I think most of it still applies to developers. I think the best point in the video, have a good lawyer.
When I saw the title of this submission, I immediately thought of this video. Everybody should watch this video, at least twice.
And never ever ever start work without a contract in place!
Also, the magic words to avoid the described scenario are "intellectual property will transfer on receipt of payment". The parents video covers this in more detail.
>"Where is a good place to learn the ins and outs of contracts?"
It's more an issue of customer relations than contracts. Contract specifics should be a reflection of that relationship (or lack thereof).
The way most people really learn customer relations or contracts is The School of Hard Knocks. The introductory sequence consists of SHK101 - Get it in Writing, SHK190 - Retainers, SHK225 - Applying Retainers to Final Invoice, and SHK230 - Termination Fees.
Be aware that if you client has more than ~50 employees, you are very unlikely to end up working under your MSA. By all means try, but be ready to have your lawyer review their MSA, because their MSA is going to be the basis for your project.
You might almost be better off trying to sneak in under the MSA with the "simplest contract that could possibly work" than you'd be by formalizing the relationship with an MSA. It is very possible to get a one-off contract executed, especially for one-off services. On the other hand, if you ignite the "MSA" neuroreceptors, you may find yourself far worse off than if you had simply gotten a Nolo-style work-for-hire contract signed; for instance, it's the MSA that's going to have IP clauses, noncompetes, insurance requirements, and things like that.
Be careful and don't wave things like "MSA"s around just because they seem like best practices. They are, for a company like ours or like Hashrockets; we're set up to negotiate and review MSA change bars. You on the other hand may not want to round trip with a lawyer several times just to do an $8000 PHP contract.
> Where is a good place to learn the ins and outs of contracts?
Law school. ;)
Okay, okay. Seriously, besides getting a lawyer and have them draw you up a standard contract, there isn't much you can do to "wrap your head around [contract negotiation] for good" as there's just too much to learn. Some of it comes from experience (you'll start getting a radar for certain kinds of clauses), and there's no quick fix for getting experience besides the passage of time. Specifically, make sure there is a provision in there for getting some of the payment up-front (as grandparent suggests), and specify a late fee % for any overdue bills.
Honestly, it doesn't need to be complicated. If you just require 25-50% down on your contracts that will weed out the scammers from the legit customers, and will make sure you get partially compensated should they ever leave you in the lurch. Make sure you document all communication, try to keep it over email so it's easy to do that, and you'll be fine should you ever need to take something to small claims court (which will probably never happen).
contracts usually aren't worth the paper they are written on.
Because even if you win in court, it doesn't mean the guy will pay you...you'll still need to chase after the money.
Completing a project without a contract is begging to get shafted. It sets up an incentive for the client to demand extensive modifications and long-term support --- things you'd otherwise be charging for --- or even invites them to take your work and hand it to another contractor as a starting point.
Message board cynicism is a poor excuse for bad business practices.
They do at least offer you a leg to stand on when it comes to clients asking for constant new features without wanting to pay for them. You can refer to it to back up your refusal to do extra work and by the same token it sets a bare minimum standard for you to meet before the job is considered done.
I did some freelance without a contract once and because I didn't have an agreement in writing I didn't have much recourse to tell them there'd be a charge for additional services.
A contract will never be a quick and easy solution to stop people doing a runner but you can at least limit the damage caused with one.
Contracts are useful for spelling out the rights and responsibilities of each party so there are no misunderstandings later. But I agree with you, if the person you're contracting with doesn't want to pay you, you may well waste more than the contract is worth trying to get your money.
If your client ends up not using your work product, either because their business falters or because they reject your work, you stand a good chance of not getting paid --- contract or no contract. That's life in the big leagues.
If your client ends up using your work, your contract is going to end up plenty enforceable.
If your client ends up using your work and you don't have a contract, don't expect to get paid this year, and expect a painful obstacle course of unreasonable support demands. They'll pay you eventually, but since you've reduced the worst case outcome to "amount we agreed on" from "treble damages and site downtime", they have every incentive to drag things out.
Exactly. This is the same reason car dealerships or mortgage lenders ask for a down payment. You want both parties to have "skin in the game" so neither wants to walk away from the deal. If you can't come up with $500 upfront as a show of good faith, I don't want you as a client. That is non-negotiable. In my experience, this is more of a problem the lower the project price is. On $5000+ projects, you're dealing with a type of client who is used to paying deposits upfront (just like when you buy a car, a house, or hire a contractor to remodel your bathroom). On the $500-$1500 projects you get more amateurs.
Or any company large enough to have a purchasing department or in-house counsel. I'm just saying, be careful with black-and-white stuff like this. Your rule of thumb will serve you in good stead with small local clients, or fledgeling startups. It's a lot sketchier with BigCos. BigCos don't dick around with payables; it costs them more not to pay you than it does just to respond to the damn invoice. They may take forever+30 to pay you, but they will pay you, and they know it, and so they're a lot less likely to go through the contortions they need to go through to pay you anything up front.
Your rule of thumb will serve you in good stead with small local clients, or fledgeling startups
That is a good point that I didn't make clear in my earlier posts. As a freelancer, by choice I only dealt with individuals, small businesses, and startups. I soon found that the $10000 mark was the upper limit for projects those types of clients go for. Above that and you start having to deal with big companies and their bureaucracy, lawyers, etc. Those projects took forever to close because the CTO or some VP needed to sign off. But you know they can and will pay...eventually. We ended up avoiding those jobs just because it meant less headaches, getting paid quicker, and that we would have the upper hand in negotiating. There is nothing wrong with going after the low-hanging fruit.
Our BigCo to BigCo contracts are 50% payable on signing, 50% payable on delivery. But it's a longstanding relationship, so it's not like either side is going to walk.
I originally wrote something to the effect of "BigCos are never going to pay you up front", but tried to go back and edit my comments to hedge this, knowing that someone here would have some kind of counterexample.
I don't have a black and white rule here; I'll just say two things:
* BigCos usually have payable processes, and if they do, your contact at the BigCo is unlikely to have the authority to short-circuit them unless your service is so cheap that they have direct signing authority for it. Otherwise, what you're fighting with the payment-upfront negotiation is the friction it takes to change any part of a BigCo's "how do we release invoices for payment" process. If anyone with title =~ /purchasing/i is involved in your negotiation, give this up.
* Equally importantly, the payment upfront clause mitigates a risk you mostly don't have with BigCo's. Upfront payment is earnest money. You need earnest money when the amount of money you're working with is large enough to be worth your client stiffing you over. For a BigCo, almost any first project you do is going to be worth less than that amount; your $15k web project is a rounding error to them, and any real dispute over payment is going to cost them more than $15k in the end, and they absolutely know it.
We've turned away work from clients who can't deal with our requirement to get at least a token retainer up front. It becomes easier and easier to say no to these clients (even during lean times). After having done this for years, you think back to all the times when something goes wrong on the project and the client uses your invoice as leverage to do something stupid. Having a retainer means that payment of your invoices is not optional for them.
Fantastic video, but doesn't apply in the case of the OP, who was doing work for a client in China, where the legal system doesn't work the same way.
In China, if you have an ironclad contract and no other leverage, you have no leverage.
In cases such as this, it's best to take payment up-front for a portion of the work, either in the form of a deposit (for fixed-bid), or a retainer (for hourly work).
This means you get money up front, which is nice. More importantly, you get something I like to call fiscal inertia -- namely, if a client has paid once, they're far more likely to pay in the future.
He should have AGPL3'd this code, and put a standing offer for a royalty-free unencumbered free license to anyone who contacts him directly. The net result would have been the same, but his deadbeat client wouldn't get the code for free.
... because the AGPL would for sure stop them from using the code without giving anything back considering that they didn't even pay the author for his contract work.
If the deadbeat client was using his work, he had recourse. It might take forever to chase his money down, but it's much easier to shut a site down.
By releasing the code under a permissive license, he gave up that recourse. His client's right to use the code is now a grey area. Technically, he has the same recourse in court as he did before; contracts. But he's severed the connection between that and the deployment of his code.
I'm not expressing nerdly outrage at how he did it. I'm simply suggesting a tactical refinement for the next person who decides to dump dox to Github when a client doesn't pay.
He could have been a bit more vindictive, perhaps a non-osi compliant license like:
"This code is licensed under MIT license with one exception: for 5 years, this license excludes any use
which benefits directly or indirectly the current
owners of UnPayingCompany, Inc. On Aug 1st, 2017, the license for this code is MIT without any restriction."
Tempting and amusing, perhaps, but it wouldn't exactly put him in a flattering light as a contractor. It might even scare off potential future clients.
I think he's doing the right thing by releasing it as OSS. Hopefully he'll pick up some support hours if anyone actually ends up using it.
PS: I once got stiffed for $6500, so I put up a "client hasn't paid" notice on the (demo) website for my code. I later learned that the guy I was accusing of non-payment was very likely a stolen identity. Some guy from Eastern Europe was using many fake identities and scamming lots of developers. So I ended up:
1) out $6500
2) feeling dumb for getting cheated in the first place
3) feeling bad for having pseudo-publicly excoriated a likely innocent
I wish in retrospect that I had taken the higher ground, open-sourced the code and just moved on.
Because it reeks a bit of airing dirty laundry, similar to the guy who added a "my client John Smith hasn't paid his bill, so I'm uploading this message to his website which I still control, in order to publicly shame him" which we saw a few months back.
Don't get me wrong- I think he's totally within his rights to (publicly) exclude him from the license. And as a developer who's been stiffed before, I sympathize. I think the restraint he's shown so far in that README is noble, and I hope he gets some good PR (and thus new clients) out of this.
Right now he can claim the moral high ground, even if he is kind of being a jerk about it: "I didn't get paid, but I gave them access to their work anyway! (I just gave it to some other people, too.)"
If you added the proposed restriction, you demonstrate that you will take revenge on deadbeat clients by trying to give their competitors a leg up.
Publicizing your work may be a fun way to 'get back' at an nonpaying client, but is it good for business? Would the professional thing to do be to simply drop work on this client and move on, or is any publicity good publicity for the coder?
This is damaging to the client. Yes, they may have deserved it, but will future clients be discouraged by this behavior?
Edit: To be clear, I'm not saying the coder was in the wrong in any way. That is to be determined based on whatever agreement existed between the coder and client. I'm asking if as a business decision it was wise to release the work. The client now has all of the work, and there is no possibility of reconciliation.
Why would the nonpaying client, or future potential clients, care what the developer does with his property? If they wanted it, they could have bought it from him. (I'm assuming that the developer didn't sign any IP assignments upfront, or is violating any NDAs or similar agreements about this code.)
If I was a sculptor and a client commissioned me to create a work of art, then didn't want it, surely nobody would fault me for donating the work to a local school instead of destroying it.
I disagree that the commissioned art analogy applies directly. My argument is that this was not a work of art, but a business tool, designed to provide the client with a competitive advantage. Donated art doesn't harm the commissioner, but publicizing this code CAN harm the client. A competitor can take this code and use it against the client now.
It does sound like there was no proper contract between the coder and client, which means there were probably no NDA or IP contingencies, which also explains why the coder was able to work for 200+ hours without seeing a dime. I believe the coder is in the right here. I just wonder if what he did was best for his career. It looks like most of HN agrees that it was.
Quite frankly, a client who pays is a client. A "client" who don't pay is not a client in my book, hence are not entitled the privilege that a client-contractor normally has.
Considering he release something that he created on his own from SCRATCH, he can release it all he wants since all the code belongs to him. In this case, he is doing something within his rights.
If his work is derived from the "client" codebase, then its an entirely different case.
I doubt future clients would be discouraged by this kind of behaviour. The good clients, the kind you want, understand the value of work and the importance of being paid. They will no doubt be able to emphasize with this coder.
If anything, it shows future clients that this coder is hard working and can actually produce code and get projects done. That by itself insures your reputation.
Let's see, he did work for his client, never got paid, but handed over the work anyway. That seems like fantastic customer service right there. :-)
If diluting the client's competitive advantage is harmful to the client, then wouldn't anyone who releases a free product with equivalent functionality be responsible for hurting the client? Is in unethical to, say, release Apache because it dilutes Microsoft IIS? That doesn't seem like a reasonable standard.
Now, if the client provided proprietary information to the contractor (wireless toothbrushes are going to be big next year!) and that information was somehow baked into the now-open code (automatically flag all startups building wireless toothbrushes and move them to the top of the pile!) that would be less than ethical. I see no indication that this happened in this case.
It's akin to how attracted the opposite gender would be to you, if they knew you (however justly) burnt down a (bad) ex's house.
I have seen a friend of mine retaliating on her blogs against clients who didn't pay on time, etc.
And I also know at least 4 prospective clients (honest ones, they always paid in full and on time to their contractors) who got discouraged because they had witnessed the "worst" of this friend when things might not work out between her and the clients.
Debatable that it's bad for the client, since he didn't disclose who the client is.
It sounds to me like the guy was trying to scrape together funding while he was commissioning a developer to work on his "great idea". I was almost caught into a same situation once.
I'm vary wary of anyone who calls himself an entrepreneur.
The client's name doesn't need to be released for this to be damaging. This is work that the client wanted (and maybe already received beforehand). Now it's publicly available. It dilutes the value of what the client may have had. It may open the door for competitors.
NOTE: I'm not saying the client doesn't deserve any of the harm this may cause. I only want to show that there IS a potential for harm.
This ensures that the coder gets some benefit from the code. At the very least he or she can use the code as example/demo code to show future clients. Yeah, its definitely not as good as monetary compensation, but its better than nothing.
On the contrary, I would think people would be be quite inclined to commission this developer so that the work would be done, and then they could just leverage the open source version he releases when they don't pay.
He's trying to make the best of a bad situation- he put in a lot of time for which he was not compensated, but perhaps he can get some good PR out of it. Maybe down the road someone else will use his software and throw him some billable hours for customization.
That's true, but the whole idea was to enter a market with very little to no competition. You would have the advantage with being unique. However, entering a market with 12 other people with the exact same product wouldn't be ideal.
Does someone know under which license is this released? Could not find this anywhere. Without the license specified, the author still retains the copyright.
Also, assuming this was a work for hire, not sure who the copyright belongs to (the author or the client) given the non-payment.
I wish people would include licenses even on first release, and Github could help with this. It's probably one area where Google Code has an advantage, by making the license explicit metadata.
I've generally had good results from mailing the creator when there's no license mentioned - they usually didn't bother and will add a license, and often quite flexible about which license.
Without the license specified, the author still retains the copyright.
Just one minor correction: The author holds the copyright regardless of whether the code is released under a license (open source or proprietary) or not. The fact that he is the copyright holder is what gives him the right to release the code under any license (and change the license later, should he wish to do so).
This is abandon-ware. I saw a lot of similar projects leaved open sourced which died quickly in no-relevance. What a difference between healthy open source project where you get support and bugs fixed...
* Deposit required, typically 25%, depends mostly on the estimated length of the project.
* Payment on milestones (typically first beta and completion, possibly more depending on length of project)
* I own the IP until paid in full
* 50% kill fee less deposit
Though, honestly, I prefer day rate over project based fees. If I do a day rate, payment is due every 15 days.
It's worth the $1-2K of going to a lawyer and getting a contract boiler plated.
It basically boils down to this though: You are in business, act like it. I don't do favors for clients I don't know. Once we establish trust and relationships, I become a lot more flexible.
I thought when I started implementing these terms that I would lose business, and I have lost a few projects because of them, but honestly if they can't respect the terms, they probably aren't going to respect your work and you'll be caught in that endless freelance/consultant cycle of hunting down payment.
I worked on a project around a year back (something like fetch.io, but a stripped version) and had a deal with the employer that we'll be sharing the profits that are made from the service. He invested on the servers and the premium accounts with various file hosting services. I took care of the entire application. But he scrapped that project even before the beta is launched saying that the operation costs are more and he see no point in launching the service and also partly because of the legal issues involved in downloading and distributing content from other services. After reading this post, I feel like I should open source the code that I'm not using now.
I suggest incremental payments and a deposit for any work of any size (which this definitely counts of). We do 20% upfront, 50% on adhoc reasonably functional demo, and 30% before uploading to apple/releasing code.
My company's iPhone fixed fee contracts state that you surrender all rights to the work after a (long) term of non-payment and still owe the amount due so things just like this can be done when people just disappear off the face of the earth but yet salaries and contractors and artists still need to be paid for all that time.
Asking for a deposit for a project does something very important: it pre-qualifies the party asking for the work in multiple dimensions.
Here's what I mean. If they can get you a check cut for a portion of the amount of the project, then you just learned three important things about them: (a) they take you and the project seriously and are committed to your doing it; (b) they have both the signing and check writing authority to commission the project; and (c) they are able to control their organization from their end in order to make the project happen.
If it is not a major corporation and you don't get a deposit up front and you just start working, then any number of bad things can happen:
- You find out that they never intended to pay and they consider your demands for payment a joke.
- It turns out that they are powerless smurfs with no signing authority
- It turns out that there is absolutely no support for the project internally
In any event, it then becomes a crap shoot for you. If you get a deposit it is possible that you may be stiffed on later payments, but it becomes highly unlikelier by orders of magnitude.
A signed purchase order from a large company should be enough to go on, I guess. I have always asked for deposits.
Something not noted: he's turned a negative event (getting stiffed) into positive exposure for his work with hundreds of HN readers. At least at a glance, it seems like solid and clean Rails / Ruby code (and I think I've seen some other commenters noting that as well.) I'd be surprised if this post didn't result in at least one new client down the road... nicely played.
The only time I've been stiffed on a contract job was, surely enough, the one time I took the "project manager" I would be working for at her word and didn't require an up-front payment.
I wonder if he has the rights to use the code himself and/or allow others to use the code. The code is likely a product of a combination of specs, discussions, and his own work.
Join the party. As someone who was recently ripped for $12k+, it's nice to see folks fighting back. In my case the work I did continues to remain online and in use by the original owner while I try to get l my client(who runs a sham design agency) into jail for writing returned checks--and having a history and a prior conviction of doing so.
Have you considered using a debt collection agency? On the first consulting gig I ever did, I was owed $10K by a client who refused to pay. After months of patience, including offers to let them pay off the debt over time I went to a collection agency and got the lot back in a court settlement less $1k in fees for the agency (which at least was tax deductable).
I should mention that this was in Australia and I had a pretty solid contract. So this may not apply to you, but the debt collector took the hassle out of chasing it up and I didn't have to get involved in the court proceedings. It might be worth a look.
For anyone who's contracting I'd recommend a few things:
1. Always have a contract and make sure you get advice before you sign it.
2. Don't be afraid to change or negotiate terms if you need to. Look out for excessive IP restrictions and restraint of trade clauses.
3. If you're doing per-diem work, get signed weekly timesheets. They're a legal record of work done.
4. If you're building a product for a fixed price, contractually define milestone payments and ideally get a partial payment up front.
5. If a client can't or won't pay at any point, stop work until they do!
This guy is far beyond the reach of debt collection agency. He has multiple active civil cases re: money owed. His own former lawyers have been owed money to and have obtained default judgement against him and yet have not been able to collect money as of my last conversation.
I don't understand how you get involved with a client like this and never take payment. Care to explain? Curious as I don't freelance. Surely you take a deposit upfront and vet the client?
I did the routine vetting on google which pulled up only the good stuff: speaking engagements at conferences like ad:tech and multiple interviews. "Pretty legit guy" I thought.
It wasn't until three returned checks, barrage of excuses and threats that I came out of my delusion and realized the guy is a scumbag. A true scumbag: the original client that his agency was hired by had paid the agency--probably several times what was owed to me. And yet, the schmuck owner of the agency thought it'd be better to cheap me than pay me my fair slice of what he made.
I once came close to opensourcing an applicaton because the client refused to pay. I was making preparations for the opensourcing, but he came trough at the last moment.
Seems to me like this was as good a solution as any. Plus now everyone can use the code, and I bet the individual who didn't pay will think twice about that again.
I keep getting a "Could not find sprockets-2.0.0.beta.10 in any of the sources" error when I try to bundle install. Anyone know what may be causing this?
In the gem file change the rails version to gem 'rails', '~> 3.1.0.rc6'., then run bundle update. I also had an issue with the rake gem and resolved it with gem uninstall rake. Evidently the rake gem gets installed twice or something. Note, I am using Ruby 1.9.2, rvm.
The project is pretty good but not quite polished. For example the UI could be improved. There is no indication that anything has happened after signing up an account other than by checking the server log. The messaging system could use some work. Entering in a user name for the message recipient is kind of buggy.
Freelancers should always try to get at least a deposit upfront. When I was freelancing, I would get 100% upfront for projects under $500, 50% upfront for projects between $500 and $2000. For projects over $2000, I would get 25% upfront, and then set milestones with payments attached. I had a $7500 project once where the guy made the first 25% payment, I completed the first milestone (graphic comps and UX flowcharts) then he disappeared for a year, not returning phone calls or emails. He then contacted me out of the blue and made the second payment, and I completed the second milestone (HTML/CSS/JS coding), and then he disappeared permanently. Clients like these are exactly the reason you need to get some payment upfront.