Have you ever received proposals from several vendors for the same web project, only to see a significant difference in their fees? While a tightly specified RFP is supposed to guard against this, when it happens, there should be no real surprise. Here’s why: Every respondent will go (or should go through) a detailed costing and work effort estimation, effectively multiplying the rate by the number of hours.
Like their clients, each vendor needs to make enough money to stay in business: rent, technology, salaries, training, and the myriad of other costs need to be covered. So if the developer bids a low price in order to win, then they need to find ways to cut corners.
In an earlier post, we described these pressures in greater detail, and suggested ways that the selection process can be improved. This week, we expose 15 shortcuts that clients need to be aware of – and head off at the pass.
15 ways developers can cut corners:
1) Scope creep strategy: Bid low just to sign the contract, and then increase the contract value through later change requests.
2) Razor blade strategy: take a loss on the website build, but make it up on onerous support annuities. This is no different than what happens with razor blades or ink jet printers. Mitigation: compare total cost of ownership, including all ongoing external and internal costs.
3) Onerous exit costs at website end-of-life. This is typical when the site is built on a proprietary content management system or the developer hosts the site at their facility. Mitigation: ask about the exit costs – and then put it into the contract.
4) Skip the built-in SEO: There are about a dozen search-engine-enhancing development activities that should be implemented during the site build: from descriptive ALT tags, custom TITLE tags on each page, H1/H2/H3 tags, keyword density, friendly URLs, etc. It’s easier to win an engagement when this work effort is completely omitted from the proposal. And it’s easier to justify a follow-up engagement to improve SEO, often on a monthly fee-for-service basis. Mitigation: Review sites that the developer has already built, and see if these are incorporated.
5) Bait and switch: This occurs when those who sell the engagement aren’t doing the work. A slick salesperson will learn about the organization and its needs write the proposal, do the pitch, but when someone else – usually a junior – is slotted in to do the work, that learning must happen all over again. The project budget then gets used to redevelop relationships and learn about the business – not on the deliverables. Mitigation: Determine if the key project team members are involved in the early business development process.
6) Misleading portfolio: Who actually did the beautiful work in the web firm’s portfolio? Often, it was done over the years by former employees, freelancers, and interns – none of who will be on the engagement. When it is the same team who did the work in the past, it is more likely that past performance will be an indicator of the quality (and timeliness) of the work that is done in the future. Mitigation: Do not accept portfolio examples or case studies where the proposed project manager AND designer were not intimately involved in the project.
7) Outsourced to third parties/brokers: Typically, this happens when the web firm is more development-oriented than design-oriented. By outsourcing design, the actual designer is disconnected from your requirements: user experience design and branding work profits hugely with direct interaction with the designer – both during design discovery, and throughout the process. When outsourced, this knowledge disconnect will increase project risk – and cost. Mitigation: Ask the firm how many of their design team are full-time employees, vs part-timers, contractors, freelancers, outsourced, or “partners”. Ask if any of these types of individuals will be doing any work on your project.
8) One-click install: Many technologies, WordPress chief amongst them, can be installed through a standard “one-click” process on a webhost. The problem is that this is inherently insecure, and your custom site is custom… not “standard”. But using this capability can save time… which can then be recaptured with a later change request. Mitigation: For WordPress, go to one of their existing client websites, and go to the “standard” wp-admin login page (eg www.sitename.com/wp-admin). If you see a login page, chances are it is a one-click install, not a customized installation.
9) No firewall security: The most valuable asset for every organization is their reputation. When a web server is hacked, reputation and trust are quickly lost. Budget pressures can cause security corners can be cut – and sometimes completely ignored. Mitigation: Securing a site takes a significant amount of effort. See above – wp-admin – for a quick test, but it’s best to ask them specifically what they do to secure the site.
10) No documentation: Documentation includes everything from strategy documents, to functional requirements, technical specifications, to a visual identity guide, to in-line commenting within the code, to to user manuals. Skipping (or skimping) on any of this mostly invisible work is a great way to bring down the initial cost. Mitigation: If there is no mention of the documentation in the proposal, then it’s not included. To look under the hood yourself, review the HTML code from one of their clients: are comments embedded within the code? (Note: In order to speed the site, better web developers will “minify” the code before publishing a final version of the site – this is not a foolproof check.)
11) Do-it-yourself hosting: It’s financially tempting to capture annuity income hosting a website at the web developer’s facility. And the more sites on a particular piece of hardware, the higher the margin. The developer then trades this forever profit for cheaper web development pricing. The problem with this approach is that in 90% of the cases, web sites should really be hosted on scalable cloud-based servers, with redundant internet connections and hardware. Think the Amazon cloud, not a web developer’s closet or a consumer $8/month plan. Mitigation: ask detailed questions about their hosting recommendations.
12) No performance testing or optimization: Performance testing and optimization is really a double negative for developers: it takes time to do, and when issues are found, then they must be fixed… on the developer’s dime. The unethical developer much prefers to leave Pandora’s expensive box closed. Mitigation: ask about what they do to optimize the site for speed. Then test the site pre-launch using web-based automated tools to determine whether everything that could be done, has been done.
13) Templated design: Why create a completely new design, when you can use a variant of a design (and the underlying code) that has worked perfectly well many times before? Mitigation: Look at the developer’s portfolio: does each site look completely unique, and reflect the brand of the organization?
14) Semi-accessible: In many jurisdictions, legislation (“AODA” is one example) now requires that new websites be developed to be accessible to people with disabilities. To create a site that is fully accessible means significant additional effort: different (and more) coding, different design, and additional testing. It’s far easier to skip the heavy lifting, and not bother with some of the hidden work. Mitigation: After the site is delivered, ask a third party to certify the site for compliancy. Or, ask the developer to prove that the site is compatible.
15) Responsive plug-in: Instead of spending time doing custom designed layouts that are optimized for tablets and smartphones, the developer can install a free plug-in that does 30% of the work – and provides 30% of the benefit. While you might see a mobile-style drop-down menu and a few other minor changes, all of the heavy lifting is omitted: the result is a poorer user experience and reduced conversion. Mitigation: Make sure that during the development process, you sign-off on customized responsive screens.
The vast number of developers are ethical, hardworking, and do not look for shortcuts: the pressures of profitability – and sometimes unreasonable selection processes – can sometimes force a behavior that is not in a client’s best interest.
This week’s action plan: If you have recently built a new site, use this list as a checklist: how did you do? If a new site is on the horizon, make sure that you are comparing apples with apples – and that your selection process does not force developers to cut corners. The best way to do this is before the RFP even goes out: have an open discussion with prospective partners, and see how many of these items they even bring up.
Editorial comment: There is considerable nuance to each of the items in this post. And each item may have a different value to any particular client: for example, some clients might not care about site speed, so performance testing and optimization need not be done. The purpose of this post (and the first part) was to foster a more transparent, knowledge-based discussion – and therefore improve the outcome of the project for all involved.
An open discussion: If you are considering a web project in the next 12 months, and are interested in an open discussion about your selection process, please don’t hesitate to reach out.