Tips for Selecting a Web Development Firm?

cyrano asks: "The organization I work with is looking for nothing less than a complete re-launch of its web site - upgrading from cobbled together static HTML and ASP pages to nothing less than a dynamic, database-driven site with a full-featured Content Management System and a secure eCommerce component. I have already collected proposals from several firms, each advocating the benefits of Java and Struts vs. ASP.NET vs. PHP...however, the technology used by each firm will only form a small part in my final decision. My true concern is ensuring that the firm I contract will be professional, cooperative, timely and will ultimately deliver their services as promised. What sort of questions should I be asking them, and what sort of warning signs should I look out for to make sure I find the perfect fit?"

Comments

return -EWRONGBIDNESS

[Anonymous Coward]

My true concern is ensuring that the firm I contract will be professional, cooperative, timely and will ultimately deliver their services as promised.
Sorry, wrong industry: web-developers provide none of the above.

prior work

[FidelCatsro]

Just a simple bit of advice , but have a close look at the company's portfolio .
There is no better gauge of skill ,a consistant quality is a fine gaurantee .
Personaly i would also do some background checks , perhaps contact your peers in the other firms for which the web deisgn/development company has worked for.
content first , style second (no mystery meat)

Rabid dislike of anyone approach...

[haplo21112]

...you want people who will complete the work you are asking for...not evangelists rtrying to prove their tech choice is better.

If someone crying the superiority of Java over PHP over ASP, Windows over UNIX/Linux...they are not going to be making the best choices for the various parts of the product.

Each has strengths and weaknesses, and integrates better or wrose with certain things. A key question to ask them if if they know the best X to integrate thier solution with (X). The mythical (x) need not even be what they will be ultimately building against, its thoery question but they don't need to know that when you ask.

One Word: Portfolio

[Flooded77]

These are all questions that a development firm's previous clients would have answers to. Most company sites I see usually have some sort of portfolio listing previous and current clients. If you like the firm's work, start contacting their previous clients and ask them your questions.

As far as what technology they use, I'd say that as long as it fits your needs (each tech has it's own strengths and weaknesses) and is quality work, it doesn't really matter unless you've got something in mind.

Good luck.

W3C Validator and Browser compatibility

[Trevelyan]

I would check their existing work against the w3c validator
http://validator.w3.org/
and open them up in a selection of browsers.

Its is unlikely you will find any non trivial site that passes the validator, but you can see who's is worst.

You may not be that concerned about browser compatibility, but it does show how much care they take when writing their code (in case of dynamic) or html

You could go as far as putting it in their contract that their pages pass the validator.

But note that passing the validator is not absolute proof that the page is correct, just that the sgml/xml is valid.

Re:W3C Validator and Browser compatibility

[white1827]

You actually SHOULD go so far as to state in the contract that all content MUST validate against W3C standards in one of the "strict" modes. If they even bat an eye when you request this, I would seriously be suspicious in the quality of their work. This will help insure that your investment in your website will work with future browsers for as long as possible.

Where's the focus?

[beegle]

You want to find a company that's concerned about how you're going to use and maintain the system. If they're developing use cases and trying to assess the technical knowledge of people who will use the system, they're on the right track. If they're worrying about whether to use Windows or Unix or something else, worry. If they're pushing a specific technology or product, worry.

When they present their proposals, ask why each piece is needed, and take the offensive. Ask why they didn't use something smaller or simpler. "Upgradeability" and "future growth" are, more often than not, excuses to sell you crap that you'll never use UNLESS you specifically told them that those things mattered to you. It amazes me how many people end up with a database-backed CMS for a relatively static site with a miniscule archive.

Ask about things like standards compliance and handicapped accessibility. A good company will either do that by default or jot down that it matters to you. It won't be a big deal to them. A bad company will try to convince you that IE on Windows (or whatever their technology of choice supports) is the only browser that matters.

You also want to be a little bit of a pest early on. Cold-call them a day or two after you meet to see how things are going. If they have -any- progress, you're in good shape. If the answer is "Oh, uh, we're still looking into that" or something equally evasive, well, it's not going to get better.

I work for a development firm

[FictionPimp]

I work for a company that does web development (no I wont plug them here unless asked). I would say the most important thing is to look at previous sites done by them. Call some of their clients and talk to them. We give our clients a list of past clients to call.

You should also check their work in a few browsers (safari, Firefox, IE6, etc). There is no excuse for a professional website not working in all major browsers. Make sure you own the work (A lot of our clients had been screwed in the past by this).
Try to stay away from a company that pushes one language over another. We do whats best for the client, if that means php, asp, perl, java, or even .NET thats what is going to get done. The only thing we really push hard is use of CSS for all layout. It saves bandwidth and makes the site easier to modify in the future.

Finally, if you are also going to host with them, find out who owns their servers, and where they are located. Inquire about their backup system and make sure they have standards for uptime.

Advice from a consultant

[eddy the lip]

Context: I've been doing web development professionaly for seven years, the last four with my own small web development company. We've worked with other firms, and been called in to clean up other people's work (the latter more often than I'd care for - that kind of work is zero fun).

As many other have pointed out, language doesn't matter a whole lot. We do recommend open source platforms, for the reasons familiar to anyone that reads this site often, but the most important question about this is whether the tool will fit the job. I've told clients before that what they really want is a Microsoft solution (because it fits the requirements) and that they should really find another firm to do it (because I'd rather put a hot poker in my eye than work with ASP).

Portfolio is important, but there are a million ways of fluffing it. Maybe it was subcontracted work, maybe they happened to have a really good person working for them for a few months, and they left because the company sucked. Maybe they're a large company, and their portfolio is all A team work, but you'll be getting the B team. On the other side, we've done work that would never make our portfolio because the client insisted on a nuclear orange and blue color scheme, or 500 links on the main page.

Picking a good web development company is difficult, largely because a) most of them are truly horrible and inexperienced, and b) the important things are difficult to quantify. There's a few things that are immediate warning signs, though. These should be rampantly obvious, but this is Ask Slashdot, and I've encountered each of these from companies that a client thought looked good on paper:

• where does the design phase come in? If it's early in the process, run away. You don't know what the design requirements are until you've worked out the site architecture, at the very least. Design usually shouldn't happen until somewhere around halfway through the project. (We don't touch design until the information architecture is done, we've seen any print materials you have, and layout grids are produced)
• they tell you that as long as it works in IE, browser requirements don't really matter
• can you talk to the project lead? Many companies will have a suprememly non-technical person doing the client liason. While I think this is generally a bad idea, it's the way a lot of companies work. But if you can't talk to the person that's going to be making technical decisions, run away.
• print is not the web. There's still this strange idea floating out there that print designers are interchangable with, or even superior to, web designers. The web is a whole different medium, and requires different skill sets. If they try to sell you on their print designers, it's a bad sign. Similarly, they shouldn't be selling their web designers as print designers.
• they make any kind of guarantess about search engine optimization. SEO is this week's snake oil. There are common sense things you can do to improve your ranking, but if they're promising top ten rankings, they're blowing smoke.

Some of the things that you should look for (this list keeps growing, I had to stop early):

• do they make recommendations? There's usually some aspect of a site that can be improved by a slightly different approach than what's outlined in the RFP
• do they provide source files for creatives? You don't want to be asking them to hunt down some graphic two years from now.
• ask about process. There isn't necessarily a "right" answer to this, but they should have a design process in place, and be able to explain to you why they do things this way. They should be able to explain this in a way that's understandable to a non-technical user.
• ask about usability. Budget is going to be a factor here. It's not necessarily cost-effective to run the site through multiple usability labs, but at the very least they should know about general usability guidelines (keeping content above the fo

A few heuristics

[JimDabell]

Disclaimer: I'm a web developer, and I don't always do things this way myself. They are rules of thumb, not laws that must be followed.

The most important thing to bear in mind is that you need to know what it is you want to achieve with the website. Some firms are all too happy to sell you an all-singing, all-dancing e-commerce haven (and charge appropriately), when all you actually need is a contact form, address and phone number on a single page.

Business stuff:

• Use a contract. This is for your protection and theirs. If they don't use contracts, the chances of them getting sucked into a legal battle with one of their other clients rises. It also outlines exactly what you expect from each other in clear terms, which is, amazingly, an overlooked step in building a site a lot of the time.

• Get concrete deliverables. Example deliverables:

  1. A systems requirement document detailing exactly what it is you need.
  2. A mock-up of a couple of pages to see how they look.
  3. A demo version that doesn't work in all browsers.
  4. A beta version that is supposed to do everything.
  5. Final version.

  These deliverables will be missed a couple of times. The important thing is that your contract states what constitutes acceptable quality and how slips will be resolved - if they lose money every time they miss a date or forget a feature, they'll keep to schedule and not rush things out the door.

• Every time you pay them, get the copyright for the work they have done so far signed over. If they start acting badly, you need to be able to take the work elsewhere instead of being forced to either put up with them or writing off the current investment.
• In a similar vein, make sure that the code they write isn't dependent upon any in-house tools. If you get your code off them, but it is built on top of their proprietary shopping cart API (for example), it's useless.
• As everybody else said, talk to a few of their clients.

There are a few signs to watch out for from people selling snake-oil.

• Unlimited bandwidth or disk space. The truth is, there are limits, and you won't know about them until they decide you're using too many resources.
• Guaranteed search engine placement. They can't do that. Additionally, ask them if they can guarantee stuff like this, how come they aren't #1 in Google for "web design"?
• "Meta tags". Virtually no search engine has used these in the past decade, so if they tell you they'll add them to each page, they are working with very obsolete information.

The human touch. Visit their offices a couple of times.

• Do people seem relaxed?
• Is it some guy in his parents' basement?
• Is it the same people both times?

Technology:

• Validate their HTML. If they have no errors, that's a good sign. If they have one or two errors, ask them about it. If they have dozens or hundreds of errors, stay away, they don't have any Q.A.
• Validate their CSS. If they don't use it, stay away, they are using 90s technology in the year 2005. If they have a couple of errors, ask them about it.
• Look through the validator output to see if they have any lines starting with width and ending in px; (percentages etc are fine). If any of them are setting anything to a width greater than 200px, it's a sign that they use fixed width layouts. This is a negative sign, but not the end of the world. Ask them what steps they take to deal with people on small screens - a technical explanation like "we offer alternative stylesheets" is okay, being blown off with "nobody has small screens like that" is very bad.
• Go to the front page of the most recent addition to their portfolio. View source. Are there <table> tags in there? Look at the