Printable View
I am sure many of us have had bad clients not willing to pay for the service that we have offered to or delayed the payment too long.
I think of including a time bomb routine of some kind and if payment is settled, to disable the bomb somehow.
Not very moral but we have to defend ourself,don't we?
Ioannis
Hi, Ioannis,
Attachment 6485
This kind ???
Looks fine to me.
Or something like Mikroelektronika's updates : you spend more time updating than working ...:triumphant:
Or insert a random "bug" ... client won't know when output right or false ...
"more ideas available on request"
Have a nice Day
Alain
Hi Ionnis
I wonder if you can share your working style to understand how/why the customer delays payment or refuses to pay.
Usually, hanging on to the source code till all payments are cleared is sufficient for the customer to remember you. Inevitably, a bug or a feature request will help the customer remember. After that, why do you care??
Regards
Alain: i suppose you have something like flash inserted in your post and I cannot see it now (iPhone stupid things).
Jerson: well, we want usually to sign an agreement, get an advance, present the prototype(s) and get paid for the rest.
When? "Ok friend, now the bank is closed, first thing in the morning".
Which morning? Tomorrow morning or 6 months later morning and 100s calls later?
I hear you say "what about the agreement?". Ok, I waited to get it signed while with the advance the prototype was developing. Now no signed agreement exist!
So, a good idea would be to have the prototype die after some time, especially when they sell it as a production device.
Even better if you have access from the Internet to turn it off!
I am trying to makes routine to do just this.
If the device has LCD and buttons is easy for the user to make it operational again. If not we have to find other way.
Ioannis
The idea is device dependent because it might be on a pic that is constantly on or constantly off (like a remote control).
Timer is one resource, times operated is another. EEPROM storage is the place to store our variable to check for... passing away.
Will come back with more practical ideas.
Ioannis
You also can count how timer device is power on. Store that value in EEPROM.
And you can check some unused eeprom address. And if device is powered xy times, and value on that address is FF then STOP. When thy pay you, send them another hex with correct value on that address. Or just make some combination of button that must be pressed at power up to write correct value in eeprom, and unprotect device.
No, no ... just a stupid Jpeg image ... called - by this forum - " attatchement 6485 " ( :confused: ) ...Quote:
Originally Posted by Ioannis
Alain
OK, I sawit now that I am on my PC.
@ pedja089: This is the general idea, but if the secret combination is revealed once, then we lost one round in this game.
If the device has an LCD, it could show the lock code and expect an reaction depending on that code. This code would be different each time.
So the combination is somewhat encrypted.
It would be nice to have this option on non LCD devices too.
Ioannis
It is, but if they pay you for prototype that is it...
Or you can put some connector(3 pin,Vcc,Gnd,Data), and create some type of "activator device" that can activate just 1 device...
If you tell us what is device that you want to protect, maybe you get more ideas...
Ioannis:Quote:
Originally Posted by Ioannis
I wonder how they can sell a prototype as a production device unless they tricked you into parting with the source codes. Like I said earlier, I learnt the hard way. No HEX/SRC files till all payments are done. That is a deterrent enough. You can put it in the agreement too. If they want to reverse engineer the prototype and then go to production, well, they will definitely spend more money than they owe you.
Short summary, make your agreement to release all deliverables only after all payments have materialized. No post dated cheques.
Best
Jerson
@ pedja089: There is immediate need for "this" device. Consider it general. The idea was in my mind for a lon time, as I had over the last 10 years clients that were very difficult. Now I am over an RF remote controled LED controller/dimmer. It has two LEDs as indicators and used to have two buttons for local control, but finally they were eliminated.
The idea of the 3 pins is good if you have physical access to the board.
Anyway...
Jerson, common practice here is to get paid by post dated cheques. Illegal, but since all banks support this, all commercial transactions are paid this way. I amnot fun of cheques and I even do not own a cheque block. I want to get paid cash and pay cash my debts. But is not always possible...
Also I do not give the hex files, since clients can't/won't do production on their own, unless paid well for this. Usually I do not...
Of course and I do not approve the use of prototype for a commercial product, but if the clien is so stupid... What can I do other than a time bomb?
Ioannis