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.

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.

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.

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".

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?

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.

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

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...

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.

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.

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'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.

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 to take the same stance as the corporation: Look at the bottom line, let's say you're still due $25,000, you've been paid $15,000. You stand to lose $15,000 plus court costs (and damages if they can prove it) if they win in court (i.e. if their lawyer is better than yours.) You stand to win $25,000 if you win. Out of that $25,000 you will have to pay your lawyer - which, if the case runs on could cost you as much as you're owed if not more. Is what you get after what you've paid your lawyer worth the time you lose working on some other project that is paying their bills? Probably not.

If you've got a case, file a DMCA takedown notice, if you don't, chances are you should just move on and chalk it up to lessons learned.

The best lessons I learned in this situation:

- First and foremost, have a lawyer, someone that knows corporate and intellectual property law. Someone you trust.

- Never sign anything until your lawyer has looked at it and made sure it's in your best interest to do so. A contract presented to you is a starting point of negotiation. Don't just blindly sign it assuming "it's just a standard developer contract". Any contract presented to you to sign is likely to be sided all in favour of the corporation. I've had contracts presented to me that by signing them, I'd be in breach of contract or NDAs for turning evidence over to my lawyer if that should be needed. So I reiterate - never sign anything until your lawyer has looked at it!

- Check your ego at the door. This isn't personal, it's a business relationship. Your quest to be the best and change the world for the better are your biggest strengths, but they can also be your biggest weaknesses. Don't let emotion and ego dictate your client interactions, they will be your quickest undoing.

- Never agree to anything that cannot be recorded. Every piece of communication regarding your work should be carried out in some form of recordable communication: Email, Skype chat, Lync chat, Text Message, record every phone call from your clients. Every scrap of supporting documentation you can find confirming your approach to your code should be kept to hand. Make sure all evidence the most credible it can be.

- Always use a form of source control that you have complete control over. When you pull down their original code base, check it into your local source control, unchanged. Doesn't matter if it compiles, doesn't matter if everything is there. Just check it in, in whatever state it's in. This is the starting point of your chain of evidence. If the shit hits the fan, you have a point of reference from where this whole relationship started. If you use centralized source control and they lock you out, you've lost your chain of evidence, but their lawyer has theirs. They could tamper with it to favour their story and you're powerless to do anything about it.

- Keep a log of your relationship with the client, things like what happened today, what frustrations you faced, what went wrong, what could be improved upon tomorrow. Is policy and procedure keeping you from doing your work? Have you been provided the tools required to do your job? Are you actively prevented from doing your job because of X, Y or Z?

- Every commit should have an accurate commit note. This isn't just some bullshit hoop to jump through. The notes are important. This is an evidence log of the work you've completed, it is a description of why that commit exists. It contains a timestamp, fingerprint and your username proving that you did the work and when you did the work. If nothing else, your daily check ins can be used as proof that you were working on any given day.

- Every check-in should be married with a clearly and unambiguously written task or bug to be completed.

- Make sure code review happens, someone else needs to check your code. This again isn't just some bullshit big brother tactic. This is you covering your ass. This is your ability to say, this code was tested, checked and validated before it was checked in. It was the right approach, it was good code.

- Write unit tests, make sure every unit test passes before check-in.

- Never check in broken code. If push comes to shove, you want to say that their production code was working at the point of your final check in (which was code reviewed) and all unit tests were passing. You have proof of this because their production application has the same version stamp as the check-in you wrote. You can demonstrate the same from the final check in from your local source control.

- Never say anything in writing that could later be used as evidence against you. Any time you sit down in front of an email to a client, before you hit send ask yourself how this could be construed in court against me if it ends up there. It can and it will end up in court if it suits your client's purpose.

- Never take shortcuts. Do it right. If someone is pressuring you to do it wrong, get it in writing. Support their wishes, be a team player, but make your objections in writing clear "I don't like this approach because of X, Y and Z, but if that's what you want, under duress, I will see that it's done exactly as you ask." You want to be able to say in court, "They asked for this in writing (here is the email) and I clearly made my objections in writing (here is that email) at the time this was asked of me."

- Never get so far ahead of your client in terms of work vs. what they owe you that you can't afford to live if they refuse to pay for work not yet paid for. If you can't afford not to get paid under the terms set out, then don't agree to those terms. If for instance you're paid on 30 day terms on each calendar month - that means that by the time you get your first payment, you'll have completed 2 months work. Can you afford not to get paid for 2 months work? If not, don't agree to those terms. Always make sure you have enough of a buffer that if the client refuses to pay, you've got enough to cover, plus enough to cover you while you find your next client.

- If you can put yourself in the right situation (though it's hard in the contractor world), never hand over code until it's been paid for. Take it to the client, demo, get sign off that it's complete but don't hand off until you have payment.

- Never think "this won't happen to me." It can happen to you. I'm told I was lucky to make it through the 20 years I did without it happening. It's commonplace in this industry, chances are, it's just a matter of time before it happens to you, if not, you're lucky. Just be the best you can be, act honourably and cover your ass. Hopefully if it does happen, all you'll lose is a bit of money.

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.

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.

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.

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.

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.

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 might have been unsure if you were running copyrighted code, but now I know for sure you stiffed a programmer and are trying to cover your ass after the fact.

As a professional consideration, I won't be using any of your services. Failing to pay an appropriate invoice for services rendered to you is a serious black mark for a company, particularly to people who depend on contract work to make a living.

Finally:

> Our agreement with the poster makes it clear that we own all work product produced pursuant to the agreement

I suspect that this is only true in the event that you completely paid the programmer. Failing to do so likely invalidated the copyright transfer, which is standard language to include in a contract.

I also suspect that the code you're currently running is not a clean rewrite, meaning that the next programmer based his code on that code and likely didn't remove literally every piece of it from the code base before starting.

This very easily could have left your company with liability regarding the code you're no longer using, because the formation of your current code base depended integrally on violating the copyright of the programmer you didn't pay.

I suspect you should just shut up and stop making a bigger deal of this in public, and that you should ask your lawyer point blank if the cost of fighting over the liability you might not have properly controlled will be cheaper than just paying the rest of the programmer's fee.

Considering their product is to help prison inmates communicate -- I hope none of us get to use their services!

In a "Three Felonies a Day" (http://www.amazon.com/Three-Felonies-Day-Target-Innocent/dp/...) society the odds of your ending up in one or the other position are probably greater than you think, certainly greater than you hope.

I won't be using their services either, neither as a communication method nor as a data supplier, and will try to steer any companies I work on data analysis at away from using their data.

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.

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.

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 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.

* Don't renege on agreements.

* Don't play hardball with bit players.

* Don't ask for refunds on contract work.

You biffed it[1]. Suck it up, pay the guy his money, apologize for being a douche (maybe ask for a public acknowledgement of him receiving his money even), move on.

[1] A good way to properly manage this sort of thing is to have milestones, on each milestone, evaluate the contract for a terminate/no-terminate point; if it's terminate, pay what's owed up to that point and tie the relationship off. Which, by the way, is not uncommon advice on the internet.

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

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.

In particular, you cannot use a work-for-hire agreement to cause on-the-fly copyright transfer as code is written, you have to include in your contract a requirement about a separate copyright transfer.

Here's a decent write-up I found: http://www.metrocorpcounsel.com/articles/9954/work-hire-doct...

There's a separate point here though - your contractor wrote the code which you claim not to be using, but he most likely also did a great deal of software design - data modelling, layouts, behavioral descriptions, navigation, etc. If you are using any of that, you are still using his work.

Legally speaking, even if he was as terrible a developer as you say, you are probably screwed for the money he was owed unless you had a lawyer write his contract with an eye toward not paying for poor work. That's just how contracting works.

The only people PayPal benefits is consumers and scammers.

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

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

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.

(note: This post has been sarcasm.)

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.

This was a business to business transaction. What it said in the contract, and the jurisdiction that the contract fell under are about all that matter. Anyone in this business knows the grey area work for hire programming contracts fall under. (Depending on some legal opinions if it was "work-for-hire" it may be completely void as work-for-hire doesn't cover programming except under narrow cases.)

Here one party has publicly received a large sum of money. Lawyers will look favorably on that upon taking cases. The programmers who feel they were wronged can then decide, should we wait a while? Will the company get more funding or will they go out of business?

A worst case scenario would be that the original contract programmers are entitled to a large percentage of equity in this company. Whether or not the code is used today may not even matter.

Another lesson here is to be careful who you work with. Make sure they can accomplish what you expect. It should be damn evident pretty quick when a developer is producing poor code (if it isn't, you shouldn't be in tech.) If you bake defaulting in to your business model, be careful. Individuals and small businesses remember getting screwed far longer than faceless corporations who will just sell your debt to a collections agency.

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.

That said, there is a significant difference between paying someone and getting a refund, and not paying altogether.

A better recourse would have been to go to court to get your payment back, and have independent professionals (as you already did yourself) grade the work completed. Note that in these cases the software is graded by its "peers" (average programmers), meaning that if the work is deemed "barely" acceptable, you will not see your money back.

I hope you the best on this issue and also hope that hackernews will not be used as a platform for legal/code-theft arbitration in the future.

1. The work-for-hire occurred at least two years ago. This would peg the time frame at roughly early-mid 2012.

2. Pigeonly started out as Fotopigeon, the photo sending portion of the company. Telepigeon was added at a much later date.

3. Pigeonly applied to the YCombinator Summer 2012 batch, but was rejected [1].

4. Pigeonly entered the NewMe Accelerator as part of their Spring 2013 batch[2]. The equity stake that NewMe took was 4%[3]. Crunchbase lists the intial investment date at October 2012[7]

5. Pigeonly also received a $20000 investment in December 2012 from FIU AVCC as well as $10000 in services from New Frontier Nomads to build out a MVP[4].

6. Frederick Hutson is placed in a work-release program in September 2011 and is released in March 2012[5].

7. Hutson's budget prior to December 2012 was a minimum of $2500[5].

8. From the article: "From the halfway house, he did not have any money, so he persuaded the photo company to do some coding for free." [5]

9. The developer claims Pigeonly fell behind on payments[6].

Now for the assumptions/conclusions:

A. From #2 and #5 we can conclude that that the codebase in question is not in use today.

B. Prior to October 2012, based upon #3, #4, #6 and #7, we can assume that the total amount of funding Pigeonly had was not substantially more than $X000.

C. From #8, interpreting the identity of "the photo company" is impossible, but if we assume that it is the developer, then D follows.

D. From #8, initial coding occurs while Hutson is in the work-release program ("halfway house"), pegging the date at some time between September 2011 and March 2012 (from #6)

E. From B and D, it seems that #9 is plausible, if not probable.

[1] https://news.ycombinator.com/threads?id=jparkside [2] http://www.newmeaccelerator.com/2013/02/04/spring-2013-start... [3] http://www.f6s.com/profile/38508 [4] http://avcc2012.fiu.edu/ (second image on the carousel) [5] http://www.tampabay.com/news/humaninterest/idea-mans-latest-... [6] https://news.ycombinator.com/item?id=8227225 [7] http://www.crunchbase.com/organization/pigeonly

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".

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.

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.

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).

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.

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

If nothing more, then you knew what not to do or what was difficult to do.

Regardless, you probably should have paid him.

It all depends on the nature of the contract. If it was for services and not for a completed project, then you absolutely needed to pay him. If it was for a completed and usable product, then you didn't have to pay him.

Regardless, people here will think twice about working for you.

On the flip side, as an employer, this is why you should hire slowly and fire quickly. And if you're nontechnical, you better be sure that your contractor knows what they're doing.

You had a D level agency write the code, then you consulted (apparently) B level players in technology field about this code.

Obviously they will find issues with it. Hell I will find issues with anything if I really wanted to during a code audit. Without details it's all bull.

Now, you are claiming you rewrote the code internally. Your LinkedIn shows a CTO that does not seem to have A level background and an software engineer who used to be a network technician prior to joining your company.

Not A level team either. So I don't believe your claim that you rewrote it 'properly' after getting some sort of feedback from 'Founding' CakePHP member.

There is no way you are entitled to do refund at this point. In my observation.

Good luck.

It's a little ambiguous, but by "start from scratch with a new developer", I interpreted that to mean they dumped the first contractor and hired a new contractor, not that they rewrote it internally.

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.

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.