Nothing.

Nothing makes me more livid than people who steal our work (or work we publish), publish it as their own, and then claim it was only being used for "inspiration," as a "proof of concept," or for "testing purposes."

"It was never meant to be seen by anyone."

Yep, I guess that's why there was no .htaccess/.htpasswd to prevent public access. Too difficult. Or perhaps we'd just never stumble across the site, so no harm no foul.

This happens to us all the time, and we have an incredibly low tolerance for it. People then post big rants in response as if we're the bad guys.

The work we publish takes hundreds and hundreds of hours. Personally, it requires me to be on trains and planes away from my family, beating the pavement in multiple time zones in in order to sell the work necessary to feed the folks and their families who put the incredible thought and attention into the things we make. They pour their souls into it. I watch them do it.

When you simply take what we've done and slap your own name on it, it's not only illegal - it's morally bankrupt. Those who succeed build their reputations themselves. There are no shortcuts.

The lawyers won't adequately level the playing field. Your peers and customers will do that for you.

(download)

Click here to download:

p220.mov (67.49 MB)

Baked beans in 10 seconds. This won't turn out well.

Back in the beginning of March I posted this on Twitter:

Then, just yesterday, I posted this:

Prospective clients (often big companies with legal departments or government agencies) will require you submit your financial statements to them as a condition of an RFP. The idea behind that is so the organization can minimize their risk by making sure that you're financially solvent. They don't want to engage with a company that might be here today and gone tomorrow, because it will cost them time and money to re-engage with someone else if you end up disappearing. The information can also shed some light on how your company has (or hasn't grown) over the years, and which way you're currently trending. Its a value estimator. It all sounds perfectly reasonable on paper, right?

Well, we don't accommodate those requests.

Why? Well, I wish I had a better answer other than, "It's none of their business." But that's it.

Sure, you can sign an NDA so there are assurances they won't go discussing your numbers with anyone else. But for me, an oragnization that asks to see your books is an organization that probably didn't have you on their radar in the first place, or at least not on their short list. If you're responding to an RFP, you can be assured you're one of umpteen other companies that is also responding to the RFP. The way I see it, if an organization really wants to work with you, they won't treat you like a number. They'll take the time to look at your work, ask you tough questions, understand your history, read your articles, and talk to references you provide them (which, for the record, I think is a perfectly reasonable thing to do). The health of your organization will be evident by your longevity, your client roster, your thought leadership, and most importantly, your body of work. It won't be based whole or in part on how much profit you made or what your accounts payable balance looks like.

I see it as a filtering mechanism, much like I view requests for spec work. It's a safe bet that if you're asked to show how much money your company makes (or doesn't make) or what kind of work you'll do for free to prove your worth, you're not being considered for what makes you truly valuable.

At Happy Cog, the structure and scope of each project is different. Sometimes we architect, design, build and integrate everything into a content management system. Sometimes we only design. Sometimes we only code. Lots of times we hand off templates to our client to implement on their own.

Before we deliver our design and code to a client, it goes through hours and hours of QA. We don't ship something we're not proud of. We may need to make a few compromises here and there that causes the end result not to be exactly how we would prefer, but we're not doing anything that we aren't comfortable standing behind. Not every client agrees with us on every point we try to make, but we do everything we can to make a compelling case.

Sometimes, after we deliver our template code, our clients face their own challenges. Compromises can be made to meet a business objective, or to make code play nicely with a publishing platform. Like making copies of a mix tape in the good ol' days, fidelity can also be lost if something is passed from one person to another. And these actions can have downstream adverse effects on accessibility, usability, findability, and any other '-ability' you can think of. So you have to have a plan.

When we announce that a site we worked on launched, for better or for worse, we're put under the microscope. Our colleagues and critics scrutinize every last detail. Most of it is very positive, and it feels good after such a ton of work. However, if they see something that raises a red flag, breaks a rule or best practice, or is simply misspelled, we hear about it. And frankly, we love it. This feedback helps us tremendously as we perform our post-launch audit and prepare for our post-mortem. We don't see our job as finished once a site launches. We continue to work with our clients to resolve any issues we (or anyone else) finds. When you build a new house and move in, things break. Drywall cracks, lights flicker, pipes leak. Then, the builder comes back with a punchlist and fixes that stuff. You can't anticipate those things in advance.

So, in short, thanks for helping us do our job.