The more detailed answer is that the cost of a website is highly dependent on the degree of customization required. Generally the more time it takes to develop your site the more t will cost. Getting a good understanding of the costs and the drivers for the cost is a very important concern.
In any development project, there are well-known risks:
Risk that the scope (a definition of what will be done) will be underestimated at the start.
Risk that the scope will increase over time. This happens often and is not always a bad thing. For example, through our conversations you may discover that an additional feature will deliver additional value.
Risk that the development firm will be unable to deliver any working solution at all.
Risk that the project will take more time than anticipated.
Risk that the project will take less time than anticipated.
In the traditional time and materials pricing model, you take on most of the risk, and this is generally justified because it’s your site and you will receive the benefits of a successful project. This is a common pricing model used by many development firms.
This model is common because of the problems with the other end of the spectrum– fixed-price contracts. A fixed price contract is a good faith attempt fully describe the project in advance, then specify a fixed price to build it based on an estimate of the time needed to deliver the result. In this model, the developer takes most of the risk, with some unfortunate side effects:
The developer often interprets the business requirements as narrowly as possible. Often at the cost of benefiting the business value of the site.
The developer and the client can end up in an adversarial relationship because of misunderstandings unchecked assumptions.
The time required to complete a project specification and price can significant. Unlike other areas, there isn’t established data on how long it takes to build a website – often because there are so many variables involved.
However, a key benefit in the developer taking on some of the risk is that the developer is in a position to affect the outcome – he or she has skin in the game. This suggests a compromise.
At Tall Blade we are advocates of a compromise between these two models. The compromise is often called Shared-Risk Pricing. Shared Risk Pricing starts during the Discovery Phase. During this phase we will charge a fixed amount per hour and deliver a written document this defines our agreement on a basic set of core requirements that we will develop for a fixed price. This core set of requirements includes the wireframes, sitemaps, and detailed graphic layouts of web page templates. The requirements are intended to show the minimum features the site must have to be useful.
The client accepts some risks:
Scope creep risk.
Some of the risk of the project taking longer then expected.
The developer accepts other risks:
Risk that the developer will be unable to deliver a working solution.
Risk that the developer will spend more time than expected getting basic features working.
Some of the risk of the project taking longer then expected
From your perspective you want to know what to expect. There should be no surprises and you need to feel as if you’re getting a fair price for the work. During the Discovery Phase we will be asking about your budget. Knowing the approximate amount you’re willing to spend will help both of have have useful conversations about design trade-offs. There are often many ways to deliver a project and knowing your budget will help focus on options that are affordable for you.
We’ve developed many WordPress themes for clients for specific projects. I was looking for a 3 column theme with a variable middle column and a vertical menu. (I don’t know why there are so few vertical menus for WordPress.) Anyway, I couldn’t find a theme I liked, so I wrote my own. Feel free to take a look and use it! It’s under GPL license so there’s no charge. If you like it, I would appreciate it if you keep the credit link in the footer.
We’ve developed many WordPress themes for clients for specific projects. I was looking for a 3 column theme with a variable middle column and a vertical menu. (I don’t know why there are so few vertical menus for WordPress.) Anyway, I couldn’t find a theme I liked, so I wrote my own.
When writing a document we’re used to being able to select from a list of many different types of fonts. While the web can use many fonts the process of font selection can be challenging to those setting up a new site. Often one of the early questions I get is “Why can’t I use my super-duper extra special font on a web page?”
Historically fonts have been rendered by the web browser. This means that if the font isn’t installed on a reader’s computer, the font won’t render as expected on the browser. Unlike other tools (primarily Adobe’s pdf format) the web doesn’t embed the fonts in a document; rather the browser will get an appropriate font from a font family that the web developer specifies in the document. For this reason, we’ve developed a list of web safe fonts – fonts that are pretty much assured to be available on any relatively recent computer.
Whoa, what’s a font family? A font family is simply a set of related fonts grouped together. Cssfontstack.com does a good job showing all the major font families currently used. A font family lists the preferred fonts in order; if the first font isn’t found on the reader’s computer, the next font listed will be used. This process progresses from the most specific font to the most general since the most general font will, almost always, be found.
Most of the time this process works well; however, there are cases when the current state of web fonts is clearly broken. What if you want to use a specific font that isn’t assured to be found on a reader’s computer? The common solution was to use the desired font in a graphic image. This works for small parts of a page but is unwieldy for entire pages. This method also severely impacts search engine optimization. Needless to say making significant content changes is a major pain using this process.
There have been a number of attempts to incorporate fonts into web pages. Until recently, most of these methods have had significant shortcomings. There are some good tools available now. Google has a web font service that will embed public domain or free fonts into a web page. Google has many fonts available; these may work for some purposes, but designers looking for a specific fonts will be disappointed. We also use MyFonts, a service that offers licensed fonts for both print and web. They do have a large selection of fonts, but most of these fonts have a licensing fee. Unless your site has very large traffic, the fees are small.
Each of these solutions requires that the font file be downloaded along with the web page so there’s an overhead in using fonts. For one or two fonts this isn’t much of a concern, but downloading many fonts will adversely impact the speed of your site. I suggest not using more than two or three fonts and being careful to only download the fonts on pages requiring those fonts.
CSS3 has the ability to include any font definition via the @font-face declaration; this feature certainly makes more fonts available. However, be sure to check out your font license to ensure that you can use a specific font on a web page. Just because you have a license to use a font in a document doesn’t mean you can use it in @font-face. Typically fonts licenses for web use are sold separately.
Web fonts are evolving and you’re not limited to a small selection of fonts any more. At the same time be aware of the costs of using downloadable web fonts.
One important area for new WordPress site owners is the difference between pages and posts. Let’s try to clear that up.
Posts are entries usually listed in reverse chronological order on your site. There are some ordering exceptions, but the common element of posts is that they appear in some predefined order. Think of posts like posts in a journal or diary. They are not necessarily related but tell a story (sometimes) over time. Generally posts are categorized and tagged so that they may be found easily. It would be very unusual for individual posts to appear on your menus.
Posts are most often associated with a blog. Readers can subscribe to your blog and any new or changed pages will be pushed out to them. These subscription feeds make it really easy for others to keep up on your content without having to visit your site for any updates. Rather than coming to your site for updates, the updates are automatically pushed to them!
Pages are static (they stand by themselves and don’t change much) and are not listed by date. Pages do not use tags or categories. Pages are usually linked to your menu. When a reader clicks on a menu they are taken to a page. An About page is the classic example of a page.
Pages and posts cannot be interchanged. In other words you can’t transform a post into a page or vice versa. Of course, you can cut and past content between a page and a post to move content from one type to the other.
With such head-starts, the five figure medium-sized website cost quickly becomes four. The four figure small business website cost becomes three. The home-grown sideline business goes from three figures to two (many premium WordPress themes designs are available for only $50). You can even get a WordPress website on their sister site for free. Buy a domain name for it and you’re in business for just $10.
To the short-sighted web developer or designer it’s the end of days. To the business owner it should be the start of getting the website they always thought they were going to get, but never quite did, for a price they can justify, and that everyone can use. from – WordPress The Quiet Revolution
I found this quote on a website for web developers and I think that the implications of this trend are fantastic. In the old day of web development, any organization had to throw their hopes over the webmaster wall and hope for the best. They were dependent upon the webmaster for every part of the website including the design and getting the content just right.
The result was that websites were expensive, cumbersome and really didn’t help an organization deliver their message.
In my experience in developing many sites, I’ve actually found that the most challenging part of the process is defining the organization’s message. I actually believe that developing a website is the best thing that any organization can do because if forces a reflection on what the organization is all about.
I’ve worked with several organizations to refine their organizational message – their elevator speech that describes what they do in less than 30 seconds. Let’s look at an example. I recently completed a project with Taproot to help a small non-profit redo their website. The technical work to redo the site took less than 40% of the calendar time; the bulk of the calendar time was helping this non-profit define who they are.
Stagebridge helps older people fully express themselves and live life to the fullest. Their old site made it difficult to quickly understand what the organization was all about. Studies show that most people take around five seconds to decide if they’re going to stick around on a site before moving on. These five seconds are important to let someone know who you are ans what you’re all about.
After several brainstorming sessions we quickly narrowed all their work down into four overall categories. These categories not only helped Stagebridge refine their elevator speech, it formed the foundation for the organization of the new website.
The new site uses few words and some rotating slides to convey the message. It shows the possibilities of healthy aging and how Stagebridge’s offerings help older people live life to the fullest!
So, yes, I’m glad that the days of expensive unresponsive website design are numbered. I’m excited about the possibilities of using a new website as a catalyst to refine any organization’s message!