We’ve also learned this lesson the hard way. These are now the clauses we require in every project we do:
- Payment is due X days after receipt of invoice, or immediately after the consultant has addressed any quality issues, whichever is sooner
- Late payment shall incur interest at 8% above the BoE base rate and a late fee of 100 GBP as per the UK Late Payment Legislation. Partial payments on invoices shall apply to late fees, interest, and then principal, in that order.
- In the event of a late payment the invoice for the next deliverable shall immediately fall due.
- The consultant shall be entitled to shift deadlines on deliverables in the event of a late payment as a result of any work disruption, without incurring any liability.
- Payment shall be made in X currency, or an exchange rate at X date on Oanda.com shall apply.
- The client is responsible for any bank fees incurred by their, or any intermediary bank. In the event of a SWIFT transaction it shall be made with the OUR payment code.
- The jurisdiction in the event of a conflict shall be England and Wales. Neither party shall be bound by arbitration.
- The client and consultant shall both indemnify the other up to the total value of the contract and shall not under any circumstance be liable beyond X GBP.
We also no longer share downloadable links of our deliverables until they are paid up. They get a view/comment only link for reports/data etc.
We’ve found that clients that aren’t willing to accept these terms won’t pay you either way.
We determine the net days on the invoice based on the credit rating of the client. Ironically, the good clients pay within 2-3 days normally, and the difficult ones are very “long tail”. About 1% of contracts tend to fully or partially default on their payments.
We’re in a particularly credit poor industry but our average delay due to late payment is 23 days. Those clients where we stop delivery pay on average 11 days sooner than those contracts where we don’t stop delivery.
This is based on around 2,000 invoices sent over the last 5 years.
Oh and another lesson! Ensuring that each deliverable invoice is small enough that it falls under the simplified claims procedure (in the UK it’s 10,000 pounds) greatly simplifies collection.
It costs something like 80 quid to file for recovery in court and in our experience invoices are immediately paid up when a “Letter before action” is sent.
You burn the relationship, but arguably you probably don’t want it anyway.
I believe this is what we call small claims court in the United States. The threshold varies by state, but it is a very effective way to deal with recalcitrant companies both large and small.
Does small claims work for b2b? I thought it was only for people. I've had a small (~£400) business invoice that I've chased a few times and now I'm waiting for the yearly interest to mount up to around the 5 year mark just out of spite
And another lesson: If it looks like a complete catastrofuck the minute you walk in the door, walk straight back out again. Sometimes the only winning move is not to play.
This isn't arbitrary peanut-gallerying, I've walked away from several jobs that weren't anywhere near as bad as the one in TFA because I couldn't see any way forward that wasn't going to end in disaster. One of them at least, I'm fairly certain, would have ended up in criminal prosecution.
I'm a consultant rather than a contractor, but the "shitshow" projects are amongst my favourites. They offer the chance to make a clear positive impact, which can be hugely rewarding.
From my pov, green flags for a good "bad" project mostly come from the attitude of leadership - especially if they already recognise there's a problem, and that some form of cultural change may be needed rather than expecting a purely technical solution.
On the other hand, if they seem reluctant to consider root causes, or if there's any sense that they're seeking to cover up problems or shift blame, then those are pretty clear red flags. Quick fixes tend to fall apart, and aren't really satisfying for anyone.
Hard to put into a list, it was just the equivalent of a code smell. Some random examples:
- Fly out to the initial discussion, talk to their architect, some guy they imported from France in an otherwise entirely non-French company a long way from France (not bashing French folks here but just wondering where they dug this guy up). They've read about scalability and told him to come up with a design for that, which is distributed stateless everything (this was years before microservices and CRUD and whatnot). Except that they don't have the resources to build the stateless distributed everything so they're getting all the downsides of stateless distributed everything without getting the scalability that it's supposed to provide. You know its bad when one of the nontechnical sales guys that you're having a few drinks with after work can give you a breakdown if why it won't work.
- Parachute in for the first date, they've hired a bunch of kids straight out of college who are all hacking away at whatever they've been assigned to. So I'm walking around chatting to all of them, asking what they're doing and how long they think it'll take. Most of the time the answer is "oh, probably about two weeks". At the same time I'm running a mental Gantt chart for all the components and figure out that even if they meet their wildly, ludicrously unrealistic time estimates it's going to take them at least two years to get the product out the door. Some of their two-week timelines I estimate would take an absolute minimum of six months work, but probably a lot longer. Or a few days if they use the existing open-source tool that does the same thing, but they're going to do it better so they don't need to use any existing code.
- Site visit, the office manager screws up the travel arrangements, screws up the accom, the developers clock in at exactly 9am and down tools on the minute at 5pm so it's tumbleweeds in the office at 17:00:01, the mgt. is in a separate set of offices on the other side of the building and don't talk to the devs, over lunch the devs are talking about how much longer they'll stay before they start sending out resumes.
- The possibly-criminal one, I'll use an analogy to avoid identifying the actual job but lets say you've been brought in to develop an automated pen-testing toolkit. Not just a vulnerability scanner but something that then exploits the vulnerability. "You don't think that this could perhaps be misused by the people that commissioned it?". "Oh, we were so enthusiastic about the job that we never even thought about that".
You may have noticed a common theme here, talking to the techies and/or taking them out for lunch/drinks. So if there's one takeaway, it's do that. That's how you'll find out whether it's an organisation you want to get involved with or not.
This is the sort of economics that small companies face when working with large companies, particularly when physical things/CAPEX are involved. Large companies expect net 30/60 terms to pay you. That's much simpler for their accounting/purchasing department. This bureaucracy occasionally necessitates nudging, especially if the intermediary you're dealing with didn't set up the invoice request on time in whichever SAP/Salesforce/Oracle system they use.
This is usually the same the other way; many vendors will give business clients net 30. That's nice if you're a small company and need to plan ahead. But occasionally, because you're considered small (liability), some vendors will want the money up-front. So unless you're very careful with cashflow, you end up in situations where your main sources of income (big contracts) are coming in after you need to spend money on a widget to fulfill deliverables.
Depending on the situation, the contract can demand the client purchase/ship things and work doesn't start until you have them in hand. This is usually the best route as you now have an out, and it's not an unreasonable request, but it doesn't always pan out that way!
I took "good client" to mean, "is easy to work with/communicates well/knows what they want", not just "pays on time". The inverse being, the ones who don't pay on time were already a pain in the ass to work with.
I think OP needed "emergency service is cash up front".
In a different domain, this is the painful lesson of almost anyone who tries to help people in a bind -- you can try to help, but yours is unlikely to be the advice that sets them straight, so you shouldn't get too invested with unproven or, especially, proven unreliable actors.
This brilliantly captures what I see from YouTubers who do off-road vehicle recovery. People are super nice until the bill comes, then you learn “only release the vehicle on payment.”
It's worth keeping in mind that the only practical "saving" for the OP will result in not doing the job at all, since this client most likely doesn't actually have the money and never will.
It should be, oh, short-term rush job in a foreign country for a sketchy client? That is most definitely cash up front time. Oh, you can't afford that? Sucks to be you, not going to do it.
> - Late payment shall incur interest at 8% above the BoE base rate and a late fee of 100 GBP as per the UK Late Payment Legislation. Partial payments on invoices shall apply to late fees, interest, and then principal, in that order.
As I understand it, from our lawyer, is that this exact wording is automatically enforceable in UK courts and easiest in the event of a dispute. It’s also generally internationally accepted.
I've always wondered, in cases like this where 8%+2% (for example) can either mean 10% or 8.16%, why doesn't the contract just give a fictional example of how the maths would work out?
AI has led us into a deep spaghetti hole in one product where it was allowed free rein. But when applied to localised contexts. Sort of a class at a time it’s really excellent and productivity explodes.
I mostly use it to type out implementations of individual methods after it has suggested interfaces that I modify by hand. Then it writes the tests for me too very quickly.
As soon as you let it do more though, it will invariably tie itself into a knot - all the while confidently ascertaining that it knows what it’s doing.
On localised context stuff, yeah no. I spent a couple of hours rewriting something Claude did terribly a couple of weeks back. Sure it solved the problem, a relatively simple regression analysis, but it was so slow that it crapped out under load. Cue emergency rewrite by hand. 20s latency down to 18ms. Yeah it was that bad.
For me it's just wildly unpredictable. Sometimes it gets a small task perfectly right in one shot, sometimes it invents an absurd new way to be completely wrong.
Anyone trusting it to just "do its own thing" is out if their mind
For me I would ask it to do a simple thing and it would give me the tutorial code you could find anywhere on the Internet. Then you ask it to modify it in a way that you can't find in any example online, it will tell you it's fixed everything, but actually nothing has changed at all or it's completely broken.
I think if someone's goal was just the tutorial code, it would have been very impressive to them the AI can summon it.
It only takes a cursory knowledge of what LLMs really are to understand why recreating tutorials is easy, but making actual new stuff that is well engineered (takes way way more than "passes the test suite") is difficult.
Actual novel stuff is so far out on the long tail of iterations that it's a gamble: it might pop up in an early run, or might take 2000 prompts and $20,000 worth of tokens. And it's still not really engineered, it's 10,000 monkeys with typewriters copying random shakespeare snippets off the chalkboard. At some point you'll get all of Hamlet, but most of the time you'll get garbage, and sometimes you'll get Romeo & The Taming of The Tempest.
this is what I've been using freebie gemini chat for mostly, example code, like reminding me of c stdlib stuff, javascript, a bit of web server stuff here and there. I think it would be fun to give googles agent or cli stuff a spin but when I read up here and there about antigravity, I'm reading that people are getting their accounts shutdown for stuff I would have thought was ok, even if they paid for it (well actually as usual the actual reasons for accounts getting zapped remain unknown as is today's trend for cloud accounts).
I'm too poor for local llms, I think there might be a 2 or 4gb graphics card in one of my junk pcs but thats about it lol
I found that unpredictability to be interesting. I'm doing super simple projects with these models and a year, or even six months ago, it would give me a block of code and as soon as you ran it, it would fail. And you'd have to paste the error in and keep going until it was smoothed out.
The other day though I asked for something simple and it one-shotted the problem. To me, that's new.
I know this success was a statistical outlier, however. I grok how to use it and to not trust it. I'm just shocked so many people smart people fail to understand it.
We had this debate at my company and the end result was a ban on “random” service names.
So we ended up with “auth service” instead of something like “Galactus”. The problem of course is that “auth service” isn’t searchable in our monorepo and it was a nightmare to find or discuss any info or references to the service itself. Now imagine if docker was called “container manager”. Good luck googling that and disentangling it from all the search results.
The value of a name doesn’t come from it being self-explanatory but rather from it being a pseudo-unique identifier. The small cognitive tax of remembering it serves as a shared bookmark between people that you can refer to when discussing or speaking to others about it - whether we’re talking about docker, Linux, or another person.
It's especially fun once the service is superseded. Guess which one of these services handles MAC address allocation and storage: macaddr_db or atom-util?
Is there any real drawback to just never giving your real name or address to service providers to minimise the chance of identity theft? Most likely it’s against terms of service, but other than account suspension are you likely to suffer any legal consequences?
The only way to fix the ToS issue you raised is through regulation protecting it.
Unfortunately we're going the other direction, with efforts like verified ID gaining traction in some parts of the world.
It's ironic because in most cases anonymity (or allowing an alternate identity that has its own built-up reputation) would offer real protection, while the verification systems are arguably security theatre.
I don't care what technical genius is built into your architecture, as soon as you force a user to plug their ID information into it, they've forked over control along with any agency to protect their own safety.
The ad tech companies can associate any fake identity with your real identity. So no, there is no problem. Good thing that all ad tech companies are fully on the up-and-up and have never been compromised to spread malware.
- Payment is due X days after receipt of invoice, or immediately after the consultant has addressed any quality issues, whichever is sooner
- Late payment shall incur interest at 8% above the BoE base rate and a late fee of 100 GBP as per the UK Late Payment Legislation. Partial payments on invoices shall apply to late fees, interest, and then principal, in that order.
- In the event of a late payment the invoice for the next deliverable shall immediately fall due.
- The consultant shall be entitled to shift deadlines on deliverables in the event of a late payment as a result of any work disruption, without incurring any liability.
- Payment shall be made in X currency, or an exchange rate at X date on Oanda.com shall apply.
- The client is responsible for any bank fees incurred by their, or any intermediary bank. In the event of a SWIFT transaction it shall be made with the OUR payment code.
- The jurisdiction in the event of a conflict shall be England and Wales. Neither party shall be bound by arbitration.
- The client and consultant shall both indemnify the other up to the total value of the contract and shall not under any circumstance be liable beyond X GBP.
We also no longer share downloadable links of our deliverables until they are paid up. They get a view/comment only link for reports/data etc.
We’ve found that clients that aren’t willing to accept these terms won’t pay you either way.
We determine the net days on the invoice based on the credit rating of the client. Ironically, the good clients pay within 2-3 days normally, and the difficult ones are very “long tail”. About 1% of contracts tend to fully or partially default on their payments.
We’re in a particularly credit poor industry but our average delay due to late payment is 23 days. Those clients where we stop delivery pay on average 11 days sooner than those contracts where we don’t stop delivery.
This is based on around 2,000 invoices sent over the last 5 years.
reply