Stories
Slash Boxes
Comments
Search

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Tips for Selecting a Web Development Firm?

Posted by Cliff on Wed Feb 23, 2005 09:16 AM
from the before-dumping-eggs-in-a-basket dept.
Businesses Programming The Internet IT Technology
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?"
+ -
story
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Tips for Selecting a Web Development Firm? 50 Comments More /

 Full
 Abbreviated
 Hidden
More
Loading... please wait.

  • what they've done (Score:2, Insightful)

    by zerkon (838861)
    Simplest answer is the most obvious, look at their website, look at websites they've created, and if they've used the languages you want on your website, and have done it well, it stands to reason they are able to do it again.

    • Re:what they've done (Score:2, Interesting)

      by Anonymous Coward
      Exactly, look at their previous work.

      At my last job, they had a similar project. They wanted to port all of our existing applications to a web based system that would be accessable to outside clients and offsite employees.

      The company ended up choosing a consulting company who had just started, and didn't have any previous experience. They just happened to have the slickest marketing, so they won the contract.

      Long story short, the last I heard, they are still developing the project (Which was suppos

      • That's pretty much the truth for any kind of development, not just web development. There is a project that I was handed, which had been in development for about four years prior. It had been through two code changes and rewrites, and was continuously in a state of "beta." I cleaned it up, and got it to about 90% production quality in less than a month.

        I agree though, it is important to know the history of the individuals that you will be dealing with. Keep in mind where the code is going to be written

    • Re:what they've done (Score:2, Interesting)

      by a2wflc (705508)
      Make sure you look at websites created by the indivuals who will be working on your site. I've had a case where the 5+ example sites we saw were VERY impressive and for large & famous companies. But the team assigned to do our site was not quite as competent as the teams that did the other sites we looked at.
      • As someone that use to do design work, I second that. Many companies have several developers, but they only do simplistic things most of the time. I had a room mate that ended up working for a firm as a contractor and did a few templates for some high-profile companies. He ended up signing about 3 NDA's for various topics including not talking about the contract with anyone, not contacting the clients in anyway, not being able to use the work as his own, etc... While it sucked, he was paid about $18 an hour
  • This comes down to a matter of preference, and also what type of skills your own organization has.

    Personally I would stay far away from PHP. I prefer jsp/servlets, however Struts has gained a reputation as an albatross. Is there anybody proposing using Spring, or some other lightweight framework?
    • Very OT, but as a non-native english speaker, I'd like to know what having a "reputation as an albatross" means.
      • It comes from a well-known poem called "The Rime of the Ancient Mariner". The albatross was a sign of good luck, and a sailor shoots it (in a story one of the characters tells another). As punishment, his comrades make him wear it around his neck. The other sailors die from the curse, but he survives after seeing visions and praying. Basically, it's considered a curse, or a deadweight. More explanation can be found here:
      • It's a reference to a story "Rime of the Ancient Mariner"( [virginia.edu] (also a good Iron Maiden song). In short the Mariner shoots an albatross, the shipmates sees it as bad omen, and hang the dead bird around the mariner's neck, which would be a very heavy burden to carry.

  • return -EWRONGBIDNESS (Score:5, Funny)

    by Anonymous Coward on Wednesday February 23 2005, @09:22AM (#11754899)
    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 (Score:3, Informative)

    by FidelCatsro (861135) <fidelcatsro AT gmail DOT com> on Wednesday February 23 2005, @09:25AM (#11754931) Journal
    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... (Score:4, Insightful)

    by haplo21112 (184264) <haplo@@@epithna...com> on Wednesday February 23 2005, @09:26AM (#11754933) Homepage
    ...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.

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

      This is not necessarily true. I'm on loan to an internal organization to help them get a data driven web site up and running. Eventually they're supposed to be able to do stuff on their own. One has some experience with desktop databases, the other is a graphic designer who has maintained several mostly static web pages. Anyways,

  • One Word: Portfolio (Score:5, Insightful)

    by Flooded77 (730881) on Wednesday February 23 2005, @09:26AM (#11754935)
    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.

  • One warning sign... (Score:3, Informative)

    by Singletoned (619322) <singletoned@gmail.com> on Wednesday February 23 2005, @09:30AM (#11754960) Homepage
    I was in a discussion with our web developers and I said that the back end of the site needed to be easy for the administrators and moderators to use, which they disputed.

    They said that they could just give everyone a day's training on how to administrate the site and then it didn't need to be easy to use.

    I was so shocked I couldn't reply, and once I had gathered myself together I couldn't persuade them otherwise. The website still isn't easy to administrate.

    • Re:One warning sign... (Score:3, Interesting)

      by rednip (186217) *

      once I had gathered myself together I couldn't persuade them otherwise.

      Oh, they know better. Ask them to document those proceedures and then ask 'anyone' to follow their instructions from the documentation alone. I'd bet that the instructions are like "telnet to the server as root, log into the database as 'sa' do then do a complex SQL update affecting at least 3 tables." Keep asking questions until the documentation is complete.

      The trouble is that once a system is up and working it's hard to get the

      • No, we had a backend, the issue was just over how easy it should be to use, as in whether links to 'delete this item' should be in an obvious place or not, and whether commonly performed actions should be hidden deep in a cryptic menu system or not.

        It was little things that I had previously thought were self-evident. Not only that, but they were selling the back-end to other people as well (not a custom made job) so I would have assumed it would be in their interest to make it good.

        Probably the age old c
        • Probably the age old case of job-security through code-obscurity.
          Well when you play this game you write obscure code, not obscure GUIs.

          And as a writer of a general purpose CMS myself, i'd say that writing such beasts in a way that allows each clients to do his own thing, and keep it easy for everyone is often something really hard to do. Since each client seems to have different needs, you end up coding a sort of meta CMS where everything is configurable. But it still has to allow the webdeveloppers to b

          • But when you have one CMS for everyone, you might as well make it easy for _someone_ to use.

            But it still has to allow the webdeveloppers to build the website in a few hours, and have a GUI that makes the client thinks that it was done so solve his own particular problems (if it doesn't look like that, the client *will* be confused).

            Not at all. Lots of clients can cope with something that doesn't look as if it solves their particualr problem, as long as they can work out what it does.

  • Get references (Score:2, Informative)

    by torninfinity (817597)
    Get references from them and actually check them out. Sure you'll get only what they want to give you, but if you ask the right questions you'll be able to sort through the fluff. The only other thing I would say is put in deliverables into your contract. Many times development has been hindered by lack of planning and set timelines.

  • W3C Validator and Browser compatibility (Score:3, Informative)

    by Trevelyan (535381) on Wednesday February 23 2005, @09:36AM (#11755017)
    I would check their existing work against the w3c validator
    http://validator.w3.org/ [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.
    • 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.
      • I would agree that the pages should validate cleanly, but I wouldn't go so far as to say against strict mode. To get things to work properly cross platform, you may very well need to work with "transitional." This is largely because of problems with IE. This depends a lot on requirements - strict might be appropriate in a given situation. For a general usage, publicly accessible site, I wouldn't shoot higher than transitional. You'll be giving yourself more hurt than it's worth.
        • Transitional?

          Transitional my buttox.

          XHTML1.0 strict is an XML document.

          If a software company can't generate valid xml, give then the boot.
          BTW, making a website is the same as making software.

          Make sure they make the design completely modular to allow you to use different images, colors, and fonts scrictly by changing the css file(s). See CssZenGarden.com, (especially like http://csszengarden.com/?cssfile=/149/149.css&pag e =0, but that's me)

          And if they use tables for layout, kick them out too. You a
          • An XML document full of crappy non-semantic markup (like the CSS Zen Garden) is just so much text. It's stupid to insist on XML validation when you aren't going to work with it as raw data, and if you're going to work with it as raw data your an utter cretin if you store it in XHTML instead of a usefull XML dialect thats transformed via XSLT. In addition, in the real world, browser compatability is important (maps.google.com doesn't validate against strict, for example), and IE 6 isn't going anywhere for a
            • The browser is the xml parser.

              You are producing a valid xml document for the browser. I define that as "work with" the document.

              XSLT is only workable on the server. Fine, use it on the server, store your data as semantic xml, but the output of the XSLT should still be XHTML 1.0 strict (or 1.1) :)

          • Can anyone tell me why tables are so bad for layout? A bad designer is a bad designer, regardless of what they craft in. A competent graphic artist will know how to build a mockup that is adaptable to non-fixed-width window, and a good web designer will know how to put that into code. There's more to design (annd tables) than that, but most of the complaints seem to be about layout.

            Yeah, the potential to make asshorrible tables+layouts is there, but the potential to make asshorrible ANYTHING is there
            • One thing (that I know of) is that there is a lot of extra markup that must be used for a table-based layout. All the table's, tr's, td's and extra options (border=0, cellpadding=1,...) makes for much larger HTML files. This data is sent for every request, which results in a lot of wasted bandwidth ($) compared to using CSS. Good use of CSS allows for relatively small content pages that all share the same layout. Overall this translates to less traffic for the same result.

              A second issue is flexibility.

            • Can anyone tell me why tables are so bad for layout?

              Table layouts are a bitch to maintain. It's much easier to work with good CSS and proper semantic markup. CSS layouts are lighter. Search engines don't like table based layouts as much (all that extra markup pushes your content further down in the actual file). If you want to move page elements around (say putting the menu on the right instead of left), it's much easier to change a couple lines of CSS than sorting out a bunch of nested tables, counting c

          • Generally, I agree. Especially on the table layout bit. There's no reason to be doing that in this day and age, unless you've got some seriously ancient browser requirements. Yes, budget is going to be a major factor in how the site turns out - underfunded web projects fail the same way any underfunded software development project will fail. And I definitely agree that you should let the dev company worry about the things that you're hiring them for. Micromanagement is going to result in a crap project tha

      • The people they're likely to talk to will probably not be the people who wind up actually doing the work, and they'll likely agree to anything, whether they know what it means or not. "Surrre, we can do that in a week, no problem!"

  • Where's the focus? (Score:4, Insightful)

    by beegle (9689) on Wednesday February 23 2005, @09:37AM (#11755032) Homepage
    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.

  • Check the other sites they've done. See if they look like something you could use. Ask the other companies if they were good to work with.

    See how much experience they have. If one of their developers is an active participant in a Free software project of some sort, that's a good sign.

    Finally, sacrifice a chicken and mutter an incantation from the darkest magick of Voodou. The project will go over-time, over-buget, and will be atrociously broken in unexpected ways. The only way to avoid this for any non-

  • Although not the absolute best way of going about it, it might give you the best feedback:

    Look up existing sites, call the client, and ask them about thier experience.

    Some people may not talk about it or may get upset, but eventually you should find a few that will share thier experiences.

    This is still a bit tricky because clients that stay with a firm do so because they like the results. It's hard to find people that have a strong dislike for the company they're still with - strong bonds are formed bet

  • I work for a development firm (Score:5, Informative)

    by FictionPimp (712802) on Wednesday February 23 2005, @09:52AM (#11755160)
    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.

  • I'll do it (Score:3, Funny)

    by Fished (574624) * <amphigory@gmail.RASPcom minus berry> on Wednesday February 23 2005, @09:56AM (#11755196)
    I'll give you realll gud website for $500!
  • Start with Philip Greenspun's online book [greenspun.com] on database-backed website design. Read the hilarious Book behind the Book [greenspun.com] essay on why computer books are so bloated, but buy the dead-trees version anyway.

    Explore his other books [greenspun.com] and the websites built by his company, Ars Digita (eg the elegant NY Review of Books [nybooks.com] site). Research the tragedy of Ars Digita, via Google [google.com] I guess. Somewhere in here [google.com] there used to be a long rant about how the venture capitalists got their toes in the door and proceeded to destroy the

  • Some basic things (Score:3, Informative)

    by dtfinch (661405) * on Wednesday February 23 2005, @09:58AM (#11755222) Journal
    Web design - The current trend is away from flashy sites that slow or distract the user from what they're looking for and confuse search engines. Fluid layouts are good. Another trend is reducing the space between the top of the page and the content, and sometimes moving the navigation bar to the right to reduce mouse movement between the nav bar and the scroll bar and allow the content to be closer to the top left, drawing the user's eyes to the content and putting it higher up on the page for the search engines.

    SEO - Search engine optimization. If they've researched it they should know the acronym. Most of the old techniques no longer work in Google. Some will get you penalties. No javascript based links that the search engines can't follow. Repetition is bad. Very similar pages are bad, often the case with product pages where a product has many similar configurations, each having its own page. Dynamic pages with long urls or a countless number of possible urls (like with session ids) are bad because search engines will only spider a small number of them to avoid getting thousands of really similar pages from one dynamic page. Aside from avoiding repetition and things that confuse the search engine, content is mostly king.

    Security - They should at least know about sql injection.

    Content organization - As a plus, they should be able to organize your site based on what your customers are most likely to be searching for, what you sell the most of. This decides things like front page links, what images best represent each category, and so on. It's not enough just to have an online catalog with every product having equal weight. It might help if they took microeconomics in college.

    As for which language, php, java, or asp.net, it doesn't matter as much as the quality of the programmer. A lot of things seem to take much less effort in php though.
  • Unless your organization has some vested interest in a particular language (ie: you know you'll want to make your own modifications to the site and your IT guy only knows PHP), don't worry about the language. Someone could in theory write equally capable code in any of those languages... but more importantly, equally BAD code can be written in any of those languages. Fact is, no matter what platform they use, the people coding it could be idiots and make a total mess of things.

    Sadly, as a Senior Web Dev

    • I would have thought you couldn't do this, but I used to work for a web dev company, and some clients would actually ask to see resumes of the developers who would be working their project. I was a senior developer and/or tech lead so I had to keep my resume updated -- for clients to see.

      There are obviously complications for them providing this info (because schedules are often quite fluid), but once you've narrowed down your choices, sort out a rough schedule and ask for the resumes of the lead developer
  • Ask them for references. Ask for positive ones and one that projects completed successfully but took longer then planned, problems arose, etc, and tell them you are looking to evaluate the professional side of their business as well as their technical. If they refuse, I'd think they might be one to stay away from. Also, toss their name into Google and see what comes up.......

    Would I give a semi-negative references to a prospective client if they requested it? I think I would, knowing the reference I ga
  • Get references. Then call those references! And make them give you at least one reference they had a bad experience with. Everyone has had at least one bad reference and if they can't come up with one they are lying.

    Also, just because the company is small or comes in low, doesn't mean they don't know what they are doing. I ran a small (4 person) firm for 5 years and we would lose bids to the big boys in town because the client wouldn't believe we could do it. I'd say half the time they would come back
  • There's a reason why (a variation of) this is written on every prospectus: it is the dead honest truth.

    If you want to know how well a given firm will do, ask them to do one of your pages up front. Of course, you will not use their code if they are not selected (and you will sign a contract to that effect).

    It has been my experience that most firms will not do this -- but then (as others have noted), those are not the firms you want to bother dealing with. The few who do provide a "live sample" will be the

  • Don't put all your eggs in one basket.

    Find a vendor you think will be good, have them break the project down into chunks of no more than a couple of weeks each. Have them do the first chunk only, with the understanding that if they do a good job, they'll get more work.

    Then make sure the first chunk is done completely and well before giving them the next chunk. Accept no excuses or promises that they'll make you happy down the road. Do not give them the final payment until things are 100% complete. An in
  • My true concern is ensuring that the firm I contract will be professional, cooperative, timely and will ultimately deliver their services as promised.

    If that's really what you're after, look for an established and stable company that works on a "fixed-time, fixed-price" model, and keep an eye on any existing vendors that you want to have involved with the project.

    Speaking from first-hand experience, the "fixed-time, fixed-price" model (done correctly) does more than help deliver what you want on time and

  • Advice from a consultant (Score:5, Informative)

    by eddy the lip (20794) on Wednesday February 23 2005, @01:04PM (#11757281)

    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 (Score:5, Insightful)

    by JimDabell (42870) on Wednesday February 23 2005, @02:08PM (#11758018) Homepage

    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 [w3.org]. 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 [w3.org]. 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

  • In addition to paying attention to previous bodies of work, and what part of the world that they will be working out of...

    Try to find out what their ideal design philosophies are. Keep in mind that your company is ultimately going to be the one that maintains that code. Make sure that you agree on those aspects, but don't let on to what you think is right.

    Try to find people that are flexible on the platforms that they can write for. The reasoning for this is to avoid the vast number of cookie-cutter de

All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2010 Geeknet, Inc.