The place for nonprofits, charities, and libraries

Free webinar: What Should a Website Cost?

Free webinar: What Should a Website Cost?

  • Tell us about your web development project: What tool are you using? What challenges have you faced? What have you learned through the process? What resources would you share with others about to embark on a similar journey?

    Allen Gunn, Executive Director of Aspiration, will present on this free webinar, scheduled to happen on Thursday, December 17 at 11 a.m. Pacific time. He will discuss:

    •   The steps you should follow when framing and managing web projects to streamline the process and minimize cost.
    •   What you can expect to pay for different types of websites, from basic “brochure-ware” to higher-end web applications.
    •   The different types of website technologies.

    Click here to register, space is limited. Be sure to come back here after the webinar to post additional questions or thoughts.

    Kami Griffiths

    Training and Outreach Manager



    Hello, in continuing the question portion of the webinar titled "How much should a website cost?" I have a question about using a web browser for having staff maintain the site. Is there something we would need to ask our web developer to add on the backend for using a web broswer managment system? There was mention of using Dreamweaver, but after hearing Gunner's opinion about Dreamweaver, I would like to transition into a modern CMS.  What should we tell our web developer when going with a modern CMS like WordPress, Drupal, etc.?


    Thank you!!!

  • How do you know when you have "custom code development" and is this an area where you can reduce costs by trying to use/adapt open source software?  My organization has a database of information that we want to make available in a variety of ways (different search models), and probably extend in the future, possibly even integrating with other websites. Is this in the realm of "custom code development" and if so, how avoidable is it ?

  • This was fantastic - thanks so much. I'm a dinosaur who learned HTML in the 1990s (when pages were gray), and I'd like Mr. Gunn to elaborate on the geeky reasoning behind the uselessness and danger of using Dreamweaver for content management. I totally agree, but it would help in my own efforts to transition away from this stuff to have an expert opinion and more detail.

    I'd also like to know what you guys think about eCRM ASPs like Convio. You can contact me offline at


    Cindy Olnick, Los Angeles Conservancy

  • Built-in browser management solutions come standard in most CMSs. I've heard complaints about Drupal's lack of differentiation between the admin and user interface causing confusion, but I've not experienced this myself. In terms of what you should tell a developer, this is dictated by what kind of site would best serve your organization, and this takes planning and research. TechSoup has a lot of great articles to help you get started. Here's the "Web Building" link from the TechSoup Learning Center:

  • This depends on the size, form, and state of your current database (is it clean? compatible? large or small?), what exactly you're looking to achieve as an end product(s), and how important this functionality is to your overall website goals. Database migration rarely happens in absence of at least a few hiccups. Typically the functionality your describing is not something that's provided out-of-the-box, and is therefore designated as custom.

  • This was a very helpful session, thank you. I am wondering about building a website that is not a brochure site, that is more of a web application, custom code site where both Joomla and Drupal may not quite fit our needs, what would you suggest in this case? Thank you!

  • I have two comments:


    1) If you have specific questions on this topic, I suggest you do not post them here if you want an answer. Questions are stacking up causing confusion, and most people won't see your questions posted under this thread or topic. Create a new topic and ask your question as clearly as possible. Also include as much information that can help people answer your question. Most of the questions here would be best addresses by a meeting with a web designer or Internet consultant, not a short answer on a forum. The topics are complex and should be as specific as possible so you can get a useful answer.

    2) Someone mentioned that there was a statement the "uselessness and danger of using Dreamweaver". While there may be some situations where this could be true, Dreamweaver is one of many professional web design tools and so those that find it "useless" may be in a unique situation that has nothing to do with web design, and since it is a web design tool the only time I can think were it could be "dangerous" would be creating web pages with content that made someone more than just a little angry.

    I've been using DreamWeaver for about 8 years and I can't say I have every been hurt or even brused by it once. I can't say the same for Windows usage, which continues to cause periodic injury and humiliation.

  • Re: Dreamweaver

    It's a very useful tool in many situations, but a bit bulky for the CMS world. As was mentioned in the presentation DW can be great for the design side of CMS, but in terms of implementation it's irrelevant for some aspects and overkill for others. With CMS you're either adding content directly through the browser (no need for DW), or modifying the site design/infrastructure by editing CSS, text, and php docs that don't render in DW's design view. Firebug is a Firefox add-on that's great for previewing site modifications with your browser in real time. Once you've mapped out changes in Firebug, it's convenient to implement edits with a light-weight color-coded text editor. DW can be used for this. It's somewhat a matter of preference, but why spend time loading DW when you can get the job done with a few smaller, faster programs? 

  • That's a great set of questions.

    You usually can't "bolt on" web-based content administration to a site that does not have it. So you would likely need to migrate to a CMS, but without knowing what technology your site is running on now, I can't give a super-useful response on that point.

    There is *nothing* "wrong" with Dreamweaver, it's a great tool and I still use it in some situations.

    It is simply the case that Dreamweaver-maintained "static" sites are largely a thing of the past, and moving to a web-based content management system provides a host of richer, more powerful web site capabilities, including RSS, "edit from anywhere", and rich multi-user editing, not to mention access to libraries of add-on functionality.

    In terms of platform selection, that's a longer process, and that's what the webinar was about. Don't pick a technology first; have a plan for your web site and find a shop that has experience creating the kind of site you think you want. Make the use of an open source CMS like Wordpress, Drupal, Joomla or Plone be a requirement of your implementation when you ask for a quote.

    That said, Wordpress is an *excellent* entry-level CMS for small to medium-size organizational web needs. The others are "bigger" platforms, more powerful but correspondingly more complicated.

  • What you describe is indeed in the realm of custom code development, and that's not a bad thing. :^) Anytime you make a unique data model available to the world via the web, you have to create a solution that understands how to manage that resource.

    For the purposes of the this webinar and these answers, custom code is functionality distinct from the general CMS tasks of managing text and other media, including "create new page", "edit page", "add navigation link", etc.  By putting together lists of "user stories" as described on the webinar, you can separate them into "general content management features" vs site-specific functionality.

    The key factor in keeping down custom coding costs is not starting to code until you *really* understand what you're building it and have vetted it thoroughly with target users. Understand exactly who you are building your site for, and know exactly what kinds of steps they should be able to take on the site to obtain benefit or useful information. These "user stories" form the basis for getting an estimate on the cost of the coding project.

    In addition, such user stories also let you investigate whether there are existing solutions or partial solutions available. Writing custom web code as a nonprofit is always something you should do as a last resort. If you can find a data visualization library or other platform that meets your needs for publishing your data, I strongly recommend leaning toward existing solutions if at all possible. Code you pay to have written is a stone around your organizational ankle that you'll drag forward with you. Sometimes that's the right thing to do, but only occasionally.

    A related issue is integration with your existing or future "main" site; it's not a given that your CMS and a solution like the one described above will interoperate seamlessly. Definitely verify the status of such issues before starting to code your data model.


  • See my "custom code" answer elsewhere on this page :)

  • As I mentioned in another answer:

    There is *nothing* "wrong" with Dreamweaver, it's a great tool and I still use it in some situations.

    It is simply the case that Dreamweaver-maintained "static" sites are largely a thing of the past, and moving to a web-based content management system provides a host of richer, more powerful web site capabilities, including RSS, "edit from anywhere", and rich multi-user editing, not to mention access to libraries of add-on functionality.

  • Thank you for that reply. Could you refer me to examples of "data visualization libraries" ? Thanks.

  • Unfortunately the data visualization space is not one that we actively track, so I don't have any good recommendations off the top of my head.

    Factors to consider when looking at such libraries include:

    1) compatibility with existing technology that will need to be integrated (possibly your web site, and any software that generates/manages the data you want to visualize, any other subsystems required to publish the data you want to visualize).

    2) Licensing and costs; if there are respectable open source options, those are worth trying, as it's best to avoid being locked into licensed libraries that have annual or usage-based fees. If you have to license, look for 1-time license models as opposed to recurring.

    3) Administrative tools: how does the system let you "drive" it? Are there web-based admin screens, or do you have to hand-edit configuration files in a text editor? Again, understand and document how you plan to and need to be able to manage the tool and the visualization offereings (e.g. how do you create/add a new visualization, how to you list all available visualizations, can users create their own visualizations, can users save custom visualizations in an account, etc) before looking at what's available.

    4) Use by others "like you": do you know of peer organizations or others in your network doing similar visualizations? What are they using?

    That said, I did a quick Google search, and there seems to be a wealth of options. You'll likely need someone somewhat technical to go over the options, as they span a range of languages, underlying platforms, and architectural models (e.g. client-side vs server side):

    In addition, if you've seen visualizations on the web that you liked, follow up and see if there's contact information on the site where you can inquire what they're using and whether or not it's generally available.

    BUT FIRST, before looking at that link or considering any solution, write down your requirements: what should the technology allow you, the data publisher, to do, and what should it enable a person browsing the data to do? If you don't take the time to wrestle with and explicitly record your needs in detail, it's odds-on you won't get it right. Sorry to be pushy, but that's a fact in my many years of experience and mistake-making :^)