From the startup who allegedly stole software and raised $2M with it

157 points by jparkside ↗ HN
My name is Frederick Hutson, and I am the President and CEO of Pigeonly. I was recently made aware of a post made here:

https://news.ycombinator.com/item?id=8227225

In light of the defamatory nature of the poster’s statements, I felt compelled to respond. Well over two years ago, we entered into a work-for-hire agreement with the poster to write aspects of the software code for a beta version of our initial e-commerce platform. Our agreement with the poster makes it clear that we own all work product produced pursuant to the agreement. In the end, however, we were very unhappy with the quality of the poster’s work so we terminated the relationship and requested a refund.

In addition to my own assessment I consulted with several independent sources including a founding member of the CakePHP project (the framework the poster used). Everyone who evaluated the code said the same thing, to sum it up (in their professorial opinion) the framework was not utilized correctly which resulted in the numerous bugs and browser incompatibility issues. The truth is even if we wanted to work with the code the poster provided we couldn't because it was flawed. So we were left with no choice but to start from scratch with a new developer.

The bottom line here is that through hard work and determination, we indeed built the Pigeonly platform from scratch and in no way incorporated any of the code produced by the poster. We are very proud of what we have built at Pigeonly, our mission is to build great products that solve the type of problems most would overlook.

113 comments

[ 2.4 ms ] story [ 160 ms ] thread
I think you're going to have a hard time here trying to convince a developer community that a "refund" is something a client is entitled to in a work for hire situation.

You ask a developer to do work for you, they do the requested work, and you pay them. If you don't like the work, you end the relationship. But you still have to pay them for their time.

I don't envy the next few weeks for you guys, but you definitely brought it on yourself by stiffing a developer on an invoice. I suspect you'll come to regret having done that.

As an ironic way of reinforcing the message, you're probably going to employ a lawyer on a work for hire basis in the near future. He's not going to deliver a result that you like. Try asking him for a refund and see how that works for you.

Your best course of action is to pay the developer's invoice in full today. Then edit the above post into an apology.

> I think you're going to have a hard time here trying to convince a developer community that a "refund" is something a client is entitled to in a work for hire situation.

Depends entirely on the contract. Many contracts include terms giving the client recourse in the case where unsatisfactory work product is delivered, especially if it's a pay-for-deliverable rather than pay-for-hours-worked contract. (But some don't, and some have more complex partial-payment or third-party mediation clauses.)

It does sound like regardless of the contract dispute over that payment, the original post's accusations about the code are still false, if the post here is not lying about what code they're using. That post claimed that Pigeon.ly is using stolen code to run their product, while Pigeon.ly claims they are not using that code in their product. Which would still leave a payment dispute but not a copyright issue.

True. It absolutely depends on the specific contract each of them signed. If the contract were to say "Not satisfied? Full refund!" or anything like that, they technically are not under contract to NOT use the code.

They would literally have legal basis, in that case, to run a startup from the very code they refused to pay for. Albeit unethical, it would be legal.

Either way, the contract would clear this up. It's still bad press. With $2M in funding, just pay the dev and move on with a stable image of doing the right thing even if it isn't legally required to do so.

> That post claimed that Pigeon.ly is using stolen code to run their product, while Pigeon.ly claims they are not using the code in their product.

Does it really makes a difference if the code is currently running or not? Let's say, hypothetically, the code was not production ready but used in an alpha version to pitch an investor ?

It is impossible to prove one way or another, but I wonder, if you could sue someone, on the basis that it "could have been used".

It would make a pretty big difference to the legality of their product. If their product includes code they don't own the copyright to, that's a bigger problem than a payment dispute with a past contractor.
This is Frederick, I can speak to our specific case. The code the original poster provided to us was never used in investor presentations. We rebuilt the product from scratch almost a year before we had any real traction or investor meetings.
You've just asked for a colonoscopy.

Don't let the title of this link ("Discovering Python") fool you. It's about the sort of case you've set yourself up for by not paying this guy in full. https://www.youtube.com/watch?v=RZ4Sn-Y7AP8

...and that's just the court case.

I'd be really surprised if the due diligence requirements of your funding contracts won't also require a similar discovery process to prove that not even a single line of code or hint of design work can be traced back to the original developer.

Not paying this guy risks your losing what you're thinking of as "committed" funding due to the loopholes in your funding contracts that likely protect the funders by requiring you to expose your code and that of the original coder to the funders' technical experts at your expense (as a part of the contractually-required "due diligence"), delaying your actually receiving further funding for at least the duration of the discovery process, but possibly forever, if the funder judges there might be a risk.

It also doesn't help that you originally advertized this work as a job in California, complete with "join our team" language. https://docs.google.com/document/d/1NcKW-lnlOMSEzBEj7ywPF5nN.... Whatever contract language you are relying on to protect you in a labor contract dispute over monies owed for work performed is likely superseded by California labor law, something your funders are also likely aware of, and would likely consider a risk to their $$$.

Finally, don't you have enough stigma to deal with being a start-up (notoriously flaky), then adding the stigma of being an ex-con (notoriously untrustworthy), without adding the stigma of stiffing the coder you hired on contract (three strikes), practically cementing your start-up's status as among those most deserving to fail?

I think the bigger issue is that Pigeon.ly is going to eventually want to hire developers. The kinds of developers who they are going to want to hire are the kinds of developers who will throughly Google any companies they consider working for. Based on the content and tone of this post, a very large percentage of qualified developers would turn and run the other way.
Depends what the contract is for. If it's for "programming", then you have to pay, no matter what program you receive. However, if it's for "complete and functional product", then unless they produce that, you don't need to pay. Like in a restaurant, if you order pizza, and get steak, why would you pay?
If you eat the steak you have to pay. Even "complete and functional product" is unlikely wording as very open to interpretation. Quite likely the contract is vague, people often do not lock these things down well at the start.
They're claiming they didn't eat the steak but went and cooked a new pizza.
But if the steak comes, even if you say to a friend "this steak looks lovely" (eg using alpha for a product briefing with investors) and when you cut in to it it's raw or has a cyst or something then you send it back, you don't pay for it then. That's the implied contract at work.

What's the implied contract here? Well we shouldn't need to ask, there should be an actual contract to refer to.

> If it's for "programming", then you have to pay, no matter what program you receive.

Even that would vary considerably depending on the exact contract terms – most of the pure-hourly contracts I've seen had some thought towards standards & quality, client acceptance, etc. Lawyers make a ton of money arguing over the finer points of contracts and given that both parties involved are discussing this in public I'd question whether they had a good lawyer writing the contract given that they appear not to have one now.

It's impossible to say without the specifics of the contract but there are some standard practices that can be assumed. If the contract is for a product, as opposed to time spent, for a product there are usually defined acceptance criteria. A large product will have milestones with their own deliverables and acceptance criteria. Once the customer accepts the deliverable it's considered done and the developer should be paid for that deliverable. If the customer later regrets that choice that's too bad. The customer can usually exit the contract at any point although the contract might specify a penalty for this.
(comment deleted)
> I think you're going to have a hard time here trying to convince a developer community that a "refund" is something a client is entitled to in a work for hire situation.

Not true at all. I'm a freelance developer that would be ashamed of handing over poor quality code and I believe that if there are developers out there who do little in ensuring that their clients receive the best quality software that they're capable of producing and fixing bugs in products given to clients then they don't have the right to demand to be paid.

That being said, if the problems were due to miscommunication about requirements & scope and finding problems with the software as an excuse to demand a refund, then that's an entirely different issue.

"Poor quality code" is a matter of opinion. You can't decide not to pay someone because they've delivered what you consider poor quality code. The best defense from that is to track development (with milestone deliverables), and evaluate code quality (or pay someone to evaluate code quality) as you go along, so you can end the relationship early before you've wasted too much money.

Waiting until they're done and deciding that it's crap and refusing to pay in full is not the way to deal with bad developers.

True, but it's like lemon laws for cars. If your new car isn't reliable, you're entitled to a refund.

Yeah, there's no law that applies in this instance, but I do sympathize with the company if the code really was subpar. There are a lot of bad developers out there, and for someone who doesn't program it's very difficult to avoid them.

I also sympathize, but when you start employing people, a risk you take is that they're horrible at the job. A way of mitigating that risk is by being careful who you hire and monitoring their progress. If you're hiring a programmer, make sure somebody you trust knows something about programming and is available to you.

I'm into firing quickly, too. It's a kindness.

You don't hire someone to work the fryer at your McDonald's, and when they completely blow it and wreck your fryer completely, decide not to pay them for the day. Pay them, let them go. Reevaluate your hiring process.

I sympathize with people who make hiring mistakes — and that's pretty much everyone who's ever made a hiring decision — but they still have to pay the people they mistakenly hire for the work they did. It is both the default mode of the law in most places I know, and also just basic professional ethics.
Normally I'd agree with you but it sounds like this work-for-hire arrangement wasn't based on an hourly wage but rather payments for deliverables. If the software was as bad as described, no deliverables were met and the developer isn't owed a payment. Note that this assumes the contract specifies the specifications for what was deemed acceptable work.
The problem I have with that argument is that the original post said there were multiple payments that were all reversed later. If the code was so bad, why wasn't the developer terminated much earlier? Doesn't multiple payments normally imply that multiple milestones were hit (i.e. deliverables accepted)?
This could be an attempt to get a running proof of concept and then trying to minimize the cost of that proof of concept after the fact. It would be curious how much the investors knew about these events.
You ask a developer to do work for you, they do the requested work, and you pay them. If you don't like the work, you end the relationship. But you still have to pay them for their time.

This is not a given, and it's why we have contracts. I've certainly never worked one that was refundable, but you never know.

Red flag: massive assumption about a contract you've not seen.
Your metaphor does not work. In this case it's not about simply "not liking the result", it is about not producing functional work. If a lawyer does not perform their role competently you absolutely can get a "refund" [1].

There is way too little information in either of these posts for the community to make as definitive statements or recommend COAs as you have.

[1] http://www.calbar.ca.gov/Public/Pamphlets/ProblemwithaLawyer...

From the contractor point of view, dragging the corporation's name through the mud isn't going to serve any purpose and can be used against you in court. While I don't necessarily side with Pigeon.ly, and emotionally, I'm on-side with the developer for calling them out, doing so just started a smear campaign on both sides. This isn't cool. Smearing someone's name is bad behaviour all around. I don't care whether a client does it or a consultant.

Having been in this position myself and being completely blindsided by it, I can tell you first hand, it'll shake your confidence and then you go through the stages of grief - pretty much the same as when anyone betrays your trust. Lashing out, even though you're angry and this client may deserve to be called out doesn't help.

To start you can issue a formal letter to the company regarding the filing a DMCA takedown notice that you will file with their web host and Google for copyright infringement if they fail to pay for the code they're infringing upon. If they don't pay by the deadline you set, file the notices... or you could just go ahead and file the DMCA takedowns with their web host and Google. I don't think legally you're required to inform the company first (though, I would check that with a lawyer. I vaguely recall my lawyer saying that to be the case, but I can't say with 100% certainty), but if you want to be treated fairly in court, you have to act honourably out of court.

At that point of you notifying the company, they basically have 3 options:

- Take down the infringing code (even in a work for hire, as my lawyer explicitly told me, your code is still your code until it's paid for in full. That means that every piece of work you've completed since the cut off period for work completed on your previous invoice is still yours until it is included on your next invoice and that is paid in full.)

- Pay for the code you have written in full.

- Pay a lawyer to fight their case in court.

This is a game, plain and simple. The question is, who is the better player, you as the developer or the corporation. That depends entirely on your evidence/lawyer and who has the fewest scruples. Whoever's got the least scruples and the best lawyer wins. Their lawyer's job is in the first instance to keep this out of court. Outside of a courtroom, the company can bully you into accepting whatever terms they see fit, unsupervised by the court. In the second instance it's to twist whatever material they can lay their hands on to manipulate the judge into taking their side and giving you nothing - all for less than it would cost to pay whatever they can make you settle for. Your lawyer's job is to get the payment you deserve or get it in front of a judge to win more than the company would agree to pay outside of the court, plus your lawyer's fees.

If (like most of us) you have a conscience and spend your life worrying about whether you're really as good as you hope, chances are, the fight will take a huge toll on your confidence and your health. Even if you're right, can you handle the bully tactics that will be used to drag your name and reputation through the mud or will self doubt make you cave? Do you have the fortitude and the finances to stand against their lawyers to the end? Do you have the confidence that your lawyer can outmaneuver theirs in this case? At the end of the day, if it's cheaper to pay you off, they will do so; if it's cheaper to rewrite from scratch and cut you off they will do so; if they can make some money back by strong-arming you into paying back what they paid you, they'll try (usually though, this is just a tactic to make you back off so they don't have to pay their lawyers to fight you - because they don't even want to pay their lawyer.)

At the end of the day, it's about their bottom line, it's not personal, though it will feel very personal to you. You have t...

Terrible, awful legal pseudo-advice about DMCA and "ownership." Do not fall for this, devs.

There is a very strong chance that a payment dispute will legally be viewed as just that -- a matter to be solved by negotiation and perhaps a monetary judgment. The rest of the contract will all still stand, likely including any copyright assignment, work for hire, etc.

Trying to DMCA someone who hasn't paid an invoice is a chump move that has a very real chance of winding you up with a bad faith or tortious interference response, or worse.

A contract dev doing 25k worth of work should generally not be lawyering up, unless there's a major non cash component (eg equity in the project). If you don't trust the counterparts keep them on a tight leash for invoicing meaning get paid often and don't build up a receivable. But spending a thousand bucks on a lawyer and trying to get a company who probably actually does have "standard" paper and very good reason to want to stick with it, to customize their docs for your tiny one off deal is a rookie move and a waste of time and dough.

The stuff you say about keeping an evidence chain of work and commits etc... That's spot on. But the reason it's spot on is that it's just good business.

This was advice given to me by a contract and intellectual property lawyer. Take it as you will.

I've been in this business 25 years and I've been around the block many times with many clients. One thing I've learned over the years is that there is no standard paper. All contracts are written to protect the person or entity that wrote them. Don't kid yourself, if you blindly sign them just because they're "standard paper", you're the fool.

...As for not "lawyering up", just because you're a contract developer with "only" (for example) $25,000 in unpaid receivables... it seems to me that only someone looking to avoid paying their bills by unfair tactics would make such statements... someone who would definitely put their "standard paper" and lawyers in the way of making said payments.

Since both parties are in agreement as to what actions were taken, why don't you show us the contract so that we can determine who acted appropriately?
This sounds like a bad idea. We are not King Solomon, nor should either party want his help. For simplicity's sake, neither party should take the opinion of anyone other than a lawyer on this.
Neither party should be here on HN with this, frankly...
Leave that to lawyers. The HN audience is savvy, but I don't think most of us are capable of legally interpreting an agreement without taking a side on the matter first.
I'm not asking to try the case for them. I'd simply like to come to my own conclusion.
> Everyone who evaluated the code said the same thing, to sum it up (in their professorial opinion) the framework was not utilized correctly which resulted in the numerous bugs and browser incompatibility issues.

How using PHP framework may result in browser incompatibility issues? Whole processing happens in the server side for PHP, not in browser...

I believe Cake is like Rails in that it puts out JavaScript code automatically for AJAXing things.
While that is true, the Javascript it inserts is thoroughly tested for browser compatibility issues.
Yes, in which case "the framework was not utilized correctly" could mean "reimplemented all that shittily rather than using the built-in stuff".
In the past I've definitely written PHP that worked in one browser but not another. I don't know why this is the hardest part of the story to believe.
Like any MVC platform, there are tools in place to handle the V. If those tools were not used properly, and hacked, then it could indeed result in poor HTML.
Requesting a refund is different from a charge-back via PayPal. Working with any contractor be it an agency or a freelancer there is always a risk you wont be happy.

The correct way of dealing with it is to find an agreement you can both deal with. Not use shitty Paypal tactics to reverse the charge.

If you go for dinner and don't enjoy the food, you do not pay, leave and then call Amex and tell them your card was stolen.

> Requesting a refund is different from a charge-back via PayPal.

Anytime Paypal's involved, the waters are so muddled who can say what happened? To even be entitled to a refund, the person has a limited amount of time to file a complaint.

If the complaint is filed, Paypal may do the chargeback all by itself, even if this isn't specifically what the complainant intended.

Paypal nearly always sides with the buyer. If it's a service, even more so.
My limited experience of disputing a PayPal transaction was exactly the opposite (i.e. I was the buyer).
My extensive experience of being a PayPal seller is quite the contrary. People request a charge back, PayPal "encourages" them to contact you, which essentially is just an extra step in the charge back process that they can skip, then nearly every time the money is returned with nothing the seller can do about it.
Afaict it depends on the kind of transaction. For services PayPal is very buyer-friendly. The main area in which I've consistently heard of buyers unhappy that PayPal sides with the seller is with purchases of physical items. It seems like PayPal accepts any kind of proof-of-shipment as conclusive in those cases. If the seller can show a tracking code with proof of delivery, PayPal closes the dispute in favor of the seller. This ends up making it easy for sellers to ship severely subpar goods (e.g. relabeling used things as new), and even carry out outright scams like shipping an empty box full of packing peanuts, or shipping a cheap compact camera to fulfill a high-end sale.
Firstly, there are bugs. In everything, all the time. It's definitely not valid reason to not pay someone. Secondly, it's YOUR responsibility as the client to make sure what's being delivered is what you asked for.

Developers are not mind readers, you need to put yourself in a position where you are regularly reviewing progress, you don't need to be a developer to do this, just sit down with him/her each week and ask them to show you how the functionality works for the user. Sounds like a case of poor product management to me.

A backend PHP framework causing browser incompatibility issues. Eh?

Edit: To reply to the naysayers in one fell-swoop - unless CakePHP is identifying the browser from the request header and sending different templates/CSS accordingly (which sounds unlikely, and like a bad idea to me), there's no way for the framework to introduce cross-browser compatibility issues.

Obviously the developer could create issues in the CSS or templates directly, but that's nothing to do with the framework... which is what I was getting at.

I know!? I was wondering the same thing. Language is a little strange.
CakePHP has a few features for use on the client-side.
Why not? Server-side rendering of views?
Why not? It generates HTML which may have all the browser incompatibility issues a programmer can fit into a PHP file (replace with your favourite web language).
NOTE to developers: This is why you shouldn't accept PayPal!
Note to everyone: This is why you shouldn't accept PayPal.

The only people PayPal benefits is consumers and scammers.

Or why you should get your money out of there as quickly as humanly possible. I never leave more than ~25 bucks on there.
It doesn't matter how much money you leave in there. Do you have a CC on file or bank account, they might charge it, and even if you don't have paypal might not allow you to do any more business using their platform until all is cleared and you paid if the charge-back goes through in the client's favor.
No, you just shouldn't accept paypal. As k3oni states, it doesn't matter how much money you have in your paypal account. When a chargeback happens paypal will take whatever small amount of money you do have in there, and your account will go negative for the remaining balance... and then the bill collectors start calling.
Regardless of how the contract was worded or the outcome of your relationship, requesting a chargeback on PayPal as your first option is really underhanded.
You don't "request chargebacks" on Paypal, you file complaints.

And not filing a complaint wasn't really an option. They have no recourse if they don't file a complaint within some short period of time.

How does airing even more dirty laundry in public around this help anyone involved?

Both sides need to seek professional (paid!) advice on how to handle this situation and then handle it in PRIVATE. Bitching about something that happened on the Internet is not productive and will only give the other side's lawyers things to use against you if a suit happens.

Someone needs to sue someone. Otherwise just shut up, both sides.

I think the OP has a right to say "You don't know the whole truth" simply just to inform readers that they are only getting one side of the story. However, I do agree that the rest should be left to private discussions between legal representation.
You really have no reason to post this here. If nothing else, you'll hit the programmer equivalent of the blue line. The people here will side with the developer reflexively. You literally have nothing to gain.
Err, that is complete nonsense. If there is a reasonable case to be made then people should consider it.
Consider it for what benefit to pigeon.ly? True there is altruistic value to the HN community, but from a business perspective his OP is likely to cause damage to his brand.
Not really. If the original poster hadn't outed them by name it would be fine, but as it is a very popular HN post directly says that Pigeon.ly are thieves. I think they're reasonable to want to counter that.
Countering that you only stole his wallet, not his car might not have been the best response though.
He shouldn't talk about how the code was crap and that he deserved a refund.

But he should say (if true) that they threw out the old code because of reasons, and rewrote it from scratch.

That was the biggest issue raised in the initial allegation: that they were currently using code that they had not paid for.

I'm sorry but I fail to see what this post is for. You made a post complaining about someone else's post (of which should not have been made in the first place) trying too win over people of whom have no opinion on the matter?

Or is this just you trying to get some PR cred by saying that it was buggy/not properly done/blah blah because a bunch of people (which could be entirely made up) said so?

And in my professional opinion (no offense to the CakePHP developers) but CakePHP is about as opinionated as you get with PHP frameworks, it's almost impossible to "use it wrongly". So sorry but that sounds like a load of crock.

>I'm sorry but I fail to see what this post is for. You made a post complaining about someone else's post (of which should not have been made in the first place) trying too win over people of whom have no opinion on the matter?

weeeeell, if he's the founder, he does have a right to defend his companies reputation (that said, i don't agree with the way he's handled it).

As a CakePHP Core Developer, I disagree with the fact that you can't use the framework wrong. Any utility/library/framework can and will be bent backwards to accommodate the needs of the developer, and in ways the original developer did not imagine were possible.

It's totally possible that the developer in question wrote horrid code - though any browser issues would only be caused by html/css, something the framework doesn't generate for you past having initial admin-type scaffolding.

I still think the guy should have gotten paid and kept the money.

Pretty telling that this post's comments have become a place for us developers to warn and caution each other on how to protect ourselves from this kind of predation.
You asked for a refund, or you did a charge-back and let them find out that way? Very different concepts. Did you request a refund, get refused, then do a charge-back? What sort of checkpoints did you have during development?
This is service work, this isn't Walmart. You can't get a refund, the best you can do is end contracts as soon as possible. Hiring software contract work is always, always risky for startups. This is why. Quality varies highly and it's expensive if you choose the wrong person.

Worse is that you did a 'chargeback' on paypal which is a dirty tactic. Considering how awful Paypal's dispute process can be.

Why the heck is "allegedly" in scare quotes? "Allegedly" is exactly the proper word to use. There were allegations made. We don't know what happened.

Also, this drama playing out in public is a very bad idea for all parties involved.

EDIT Title no longer has "allegedly" in scare quotes.

That's my favorite part. I clicked here expecting more evidence that they stole. "Stole" should be in scare quotes, if anything.
> "...the framework was not utilized correctly which resulted in the numerous bugs and browser incompatibility issues."

CakePHP is a server-side framework. Browser incompatibility is not going to be an issue of CakePHP. Either you are too inexperienced to know this or you are making a lame excuse.

I can see where this would go wrong if the developer made a complete rookie mistake and screwing up input on forms, methods, requests, etc. But these are the reasons for choosing and using a framework, anyone using a framework should know this. These types of problems are abstracted and there is not a need to reinvent the wheel. This does not add up with your story.

I am calling BS. I think you stiffed the developer and you trying to save face. You guys were apparently not involved with the development processes of the project, you could have had the developer resolve the problems and thus would not have had a complaint.

In the end, this is basic business, you agreed to pay the developer for their time. You allowed the developer to complete the project apparently without question, pay up and move on.

> I can see where this would go wrong if the developer made a complete rookie mistake and screwing up input on forms, methods, requests, etc. But these are the reasons for choosing and using a framework ...

I think you just pointed what the problem might've actually been: Not using the framework to prevent browser incompatibility. The OP didn't say that CakePHP was the cause of the problem.

The front-end issues may have nothing to do with the CakePHP framework but the developer did have to create/modify views. In that case the dev still could have cause incompatibility issues. I'm not picking sides in this but I'm just saying that the OP not understanding what the framework does, doesn't mean that the dev is completely off the hook.
Most comments here are critical and I tend to agree in that 1) it's unclear whether you "requested a refund" or chargebacked and 2) if you don't like someone's work, you still have to pay the hours they spent. That's the risk when hiring someone, unless there are specific requirements that weren't met by the developer.

On the other hand I would like to say that it's good to open the discussion instead of, like most companies would, not responding and letting the legal team handle anything if necessary.

Interesting situation. One point to make: CakePHP cannot cause browser compatibility issues. CakePHP is a backend framework and does not itself cause client side issues. I know this is splitting hairs, but a lot of things can contribute to client-side issues. If a design is in bad shape (ie. browser considerations were not made during planning), then CakePHP wouldn't be a relevant point for front-end issues.

That's all, carry on. I hope everyone's bickering and finger-pointing goes well on this fine Friday.

I worked as a contract engineer for several years and here is my take:

Typically in a contract relationship you have alot less obligations than hiring a salaried employee. At the same time, this person is using their valuable time towards your project. As a result of this, they usually ask for compensation which is agreed upon beforehand.

You agreed to a certain amount of compensation, and than chose not to pay. Sometimes contractors do not meet expectation, and I've seen this happen. But if you have already agreed upon milestones it is only appropriate to pay them at least up to the point at which you request they quit or fire them.

If you did not agree upon milestones (which a business with your funding should have.) You should still be paying him for the work done. Your disagreement over his work could cause his family to go hungry for a week. Such is the life of a contractor.

All in all, perhaps both of you performed without much regard to ethic. He did a shoddy job and you refused to pay. But your running the business and as a result have a lot more to lose from a bad image.

Just pay up and move on.

You mean as an employer I can't just use 'contractor' as a way to skirt paying payroll taxes, unemployment, workers comp, etc and then hire the cheapest dev I can find and refuse payment if the work isn't top notch? As far as I've been able to determine, as an employer I am entitled to software. I am entitled to workers who produce things that amplify the earnings of my company by an order of magnitude while paying just enough to keep the workers complacent. This is America, is it not?

(note: This post has been sarcasm.)

You should do small projects to evaluate developers you hire.
How many hours of this developers time did you take up? Refunds don't exist unless you're willing to go to court and if the work was actually damaging to your company. You took a risk and you have to pay for at least the time of the developer if not their skill (since it wasn't up to your expectations).

In any case, you built the app from the scratch. The previous dev with their previous crappy code base can go cry somewhere else and stop making defamatory comments about your company.

"So we were left with no choice but to start from scratch with a new developer."

In that case, the solution is simple. Tell them "We are not using the code you delivered to us in any form. You are welcome to keep it".

Clueless clients like these are freelancer's worst nightmare.
I've turned down a number of freelance gigs just from getting this kind of "smell." It's not worth it. If I smell... umm... certain intimate hygiene products... I run away.

Red flags I've seen include:

* Smarmy-looking marketing materials. If I visit the site and think "hmm... would I be worried about downloading this app for fear it would infect my machine?" then that's a bad sign.

* Some advance-marketing and extreme-MVP tactics are okay, but if they take it too far I see it as a red flag.

* Intuition. If I could bottle it I would charge for it and be rich. Earned through school of hard knocks, which is as far as I know the only way to get this.

* No haggling at all on price... especially when combined with other red flags. This leads me to think they're not haggling because they'll just stiff me.

* No milestones or other metrics come up in discussion.

* They don't know what they want. I've seen the screwage go both ways in contracting arrangements where the hiring party kind of just wants "something cool" with only some extremely vague sense of what it looks like. In either case it's not something I want to be a part of.

* Shell company bingo... if I do a search on the founders and they have five dozen LLCs to their names it means they'll just fold the entity and stiff everyone if it doesn't work out. "Extend yourself on others' credit, test a market, and stiff people by busting out the shell if the market doesn't pan out" is a common sketchy business practice.

I once recorded a band. I thought we made a pretty good record, but they said they were unhappy and didn't want to pay me. Then they released the record.

My point: this kind of thing isn't limited to software development. If you benefit from someone else's work, pay them.

Development is the same as any service, refunds don't really happen