What does a Best of the Web website cost?

The Rochester Business Journal holds a Best of the Web competition each year.  OS-Cubed is proud to have developed sites that have qualified in the past as a finalist - though this year none of our clients submitted an entry.  The RBJ's competition looks at websites in a variety of categories including Not for Profit cultural, Not for profit human services, Banking and Finance, Education, Business and professional services, Government and Community, Health care, Legal Services, Manufacturing, Real Estate, Retail and Tourism.  In short, a vast cross section of the web services industry.

One of the more interesting questions they ask (and not everyone answers this) is the cost to build the site and the annual cost to maintain it.  Note that the interpretation of these amounts is left up to the submitter of the site and (for instance) may not include internal development costs, volunteer costs (on the part of Not for Profit companies) and other non-accounted for expenses.  Nonetheless, the study offers a nice cross section of the community and what it costs to build and maintain an award winning quality website.

If we look at the data gathered from the information provided, the initial cost of development of an award winning site is roughly $40,000 on average with a range of $325,000 to $2500.  The cost of yearly improvements, upkeep and maintenance arrives at around $6700/year or around 17% of the total cost of the initial site and varies between a few hundred and tens of thousands. 

Award winning sites are typically redesigned every 3 years or so, the cost of which isn't surveyed, but we can expect the cost to be somewhere around 1/4 to 1/2 the initial design cost for a content managed site, and as much as the total design cost for a "built from scratch" site.

So what does this mean for the average company looking to build a site?  Budgets in the over $10,000 range should not be surprising to you.  Depending on features and functions (retail, real estate and banking sites probably cost much more than not for profit or information only sites) you could be anywhere along a continuum of a few thousand dollars all the way to hundreds of thousands.  You also should be expecting to expend somewhere in the 15-20% range to maintain, update and improve your site each year.  As new browsers come out (is your site compatible with IE10 for instance?) sites may well need tweaks and updates to function properly.  Security updates need to be applied, and content needs to be changed and updated frequently.

None of these budgets included demand generation activities including SEO, direct marketing, social media, pay for click or other marketing costs.

Of course you could also opt to build a site for much less than that and not go for a "best of the web" site.  Why you would want to do that when there are competing sites that are better than yours is an exercise I'll leave up to your Marketing manager.  Good luck with that discussion :)

With budgets in that range though, you will want to carefully pick a developer and designer for the long haul - one that has your best interests at heart, and will help save you from costly mistakes - as well as recognize when an investment is worth it.

Prioritizing features

So we've built our list of (it turns out) over 85 new scope features that the site should someday have (through "pie"-in-the-sky brainstorming). How do you prioritize 85 new features? Which ones should we concentrate our efforts on - which are more or less important than others. Basically this can be done with a "factorial decision tree". Let's take a more manageable example. Say I know I like 5 pies, but can't decide which one to eat. My list initially looks like this:

Pie	Priority
Cherry Pie
Peach Pie
Pecan Pie
Blueberry Pie
Apple Pie

So the next stage is to take our first table item and compare it to each other item below it in the list. If we HAD TO CHOOSE and we could include only ONE of the two items in the final product (or in this case to eat) which would we choose. If we chose the first item we flag that one, and if we like the second item we flag that one instead. So for our first comparison we compare Cherry to Peach Pie. If I had each in front of me and had to choose one, I'd choose Peach. I'd score a 1 for peach and not points for cherry. Our next comparison is Cherry to Pecan. I'd prefer Cherry, so I score one for cherry, and none for Pecan. My next choice is Cherry and Blueberry, etc. till I reach the end of the list. So after round one we should have as many hash marks as (# of items - 1):

Pie	Priority
Cherry Pie	1 1
Peach Pie	1
Pecan Pie
Blueberry Pie
Apple Pie	1

After round one is done we go to the second item on the list and compare to everything under that. Peach to pecan, Peach to Blueberry, etc.:

Pie	Priority
Cherry Pie	1 1
Peach Pie	1 1 1
Pecan Pie
Blueberry Pie
Apple Pie	1 1

You continue to work your way down the list until you've done all the comparison. Here is my final result:

Pie	Priority
Cherry Pie	1 1
Peach Pie	1 1 1
Pecan Pie	1
Blueberry Pie
Apple Pie	1 1 1 1

We then translate the priority hash marks into numbers that are the final weighting of each item:

Pie	Priority
Cherry Pie	2
Peach Pie	3
Pecan Pie	1
Blueberry Pie	0
Apple Pie	4

The final weighted and rated rankings end up as: Apple, Peach, Cherry, Pecan, and Blueberry. If we wanted we could do a run off with matching choices if we had lots of choices by using the same methodology to choose one over the other and scoring it. And now you know I like Apple pie.... :)

The last step will be to add scope and complexity measurements to the lists. That we'll reserve for next post.

Customer loyalty vs product features....

My good friend Bill Self, in his thinkinglikeacustomer.com blog has a great article on the difference between product focus and customer focus. I recently had a brainstorming session with my long-time customer Knowledge Athletes. We were trying to look further out than the next funding round so we could prioritize scope and determine what things to concentrate on after completing the scope we'd already committed to. We also wanted to be sure we weren't looking at the trees and forgetting about the forest.

We started with an hour or so on mission statement. KA has a GREAT mission statement to start with, but it's useful to periodically review your mission statement to be sure that as you develop new ideas your mission doesn't change. By publicly declaring the mission statement we also gave ourselves a measurement to determine if each presented idea fit within that statement. This stayed on a whiteboard during the entire session.

Our next step was a brainstorming session to get down ideas for the product. Ideas were contributed by the business folks, educational leader, programmers, advertising, customers, sales and marketing. The rules were as follows:

• There are no bad ideas - we're putting them ALL up there, and we'll judge them later.
• We're not evaluating ideas - no judgements on how hard they are to implement, whether they complicate or simplify the user interface, or whether they add value or not. Just get the idea on paper (or in this case spreadsheet). We'll evaluate later.
• View the feature from the customer's point of view - at this stage, since we're looking at features (rather than infrastructure) we're suggesting features only from the point of view of the customer. "If I were a customer I'd love it if the product can do X (and define X)." This is the part that relates to Bill's article.
• Don't dig too deep - while we're capturing input on the ideas, don't start speccing the whole idea out - we just need to get the gist of the idea to prioritize and evaluate it. We can dive into the nitty-gritty of what the feature does and how it does it later. This requires a moderator to call "time out" if the topic strays.
• Use end-user input data - During the brainstorming phase we extensively used the vast amount of research data KA collected during our initial proof-of-concept phases. What did users stumble over? What did they have a hard time learning (IE not intuitive)? Where did the product complexity not solve their problem or issue? What suggestions did THEY have for improvements

After we concluded our brainstorming session we had over 70 new features to evaluate. Note I didn't say add - we still needed to look at what is more important, what is easy or hard to do, and whether the addition of a feature adds or removes user complexity and capability. Obviously the budget doesn't support all these new features so we also have to prioritize them. I'll address how we went about that process in my next post. In the meantime be sure to check out thinkinglikeacustomer.com - it's an awesome blog.

Analyzing software features

In my post on scope I discussed the idea of limiting scope - both to budget and to goals. Brad Feld in this post, mentioned an interesting methodology, which quantifies the method we've used in our projects in a neat and tidy way. Since we work with early seed companies and startups in the Family, Friends and Acquaintances funding mode, we are constantly working to see what features we can build into a project for a small dollar budget. Obviously we need to leave some features out, but how best to decide?

Brad neatly summarized the decision as chartable on 2 axis. Along one axis is appearance vs substance (though I prefer the term functionality), and along the other axis is what users say they want vs whether they are willing to pay for that feature.

I would add a 3rd dimension - what the cost to code, test, implement and train are vs the speed at which the new feature can earn back it's investment. I know this is a purely ROI sort of view of the data, but it lets you see whether it's really worth it to put limited dollars into a particular feature. Perhaps in Brad's discussion they were talking about once there is Venture money already in the development and it's more a choice based on having enough money to do everything but not wanting to overburden the product with features. In our world though it's literally what can we afford. If Feature A has strong functionality, and users are willing to pay for it, but it would cost 2x as much as we have in the budget for development - then trying to build it won't help anyone until we get more funding.

In any case, it's an interesting thought exercise, and one that each entrepreneur should go through as they try to narrow down their feature set and build their demos and proofs of concepts. Take each feature and chart it three dimensionally. This will help you visualize your feature set, and decide which features to build, and which to build first.

How to limit scope to funding

One of the biggest challenges in your early stage development will be limiting the scope of your project to the budget you have. In this stage you're using your money, your friends, your acquaintences, or maybe you have a first round SBIR grant and have a few 10's of thousands to invest. While you may be able to build some types of software with a budget that size - realistically to build something scalable you should be thinking bigger in terms of budget.

As we pointed out in our second post, when entrepreneurs come to us and say "I have $10,000" and in the same breath they say "and I want to develop something just like ebay only better" we just cringe. We know that there's going to need to be some education going on before we get to someplace that will satisfy their need to get real funding to grow their concept, within the budget they have.

Like it or not, the days of having programmers around who will sack out with friends, eat ramen noodles and put in 80 hour weeks for no pay and the promise of "stock options" at some unknown later date is just plain gone. Programmers have to eat, and at least for the moment demand for developers is quite high - so they can make money doing other things. Sure you may find one or two passionate gurus, but building a team is a different matter. After programmers got burned in the 2001-2003 dot com implosion, most want a real salary.

So when someone has a giant bag full of cool tricks that they believe will revolutionize the web universe we usually work closely with them to try to identify the core unique part of their business model that makes them special. Is it some trick or gimmick, a unique view on a market, an interesting model for monetization, a new approach to real estate, or a great educational paradigm? Then we try to work out a budget for a limited demo version of that core idea that can be used to attract new investors, test the idea out on real users, and provide a demo portal for the entrepreneur to use.

We just keep dumping features out of the product bag until we have it's core at our heart. We build that core, and then we add the features into it incrementally as funding becomes available. Got round one for $50K? Ok we'll build out the base site and the most interesting and unique part of your app. Got SBIR Round 2 for $100K? Perfect, we'll rebuild the core to support more users or traffic and we'll add some additional features. To make that work of course and move on to each round, the software has to be built to meet the milestone requirements set forth in the grant or by the funders. We help achieve that by working closely on the proposals and presentations with you to be sure you set expectations that can be met within budget.

That's not all there is to it, but that's the core. We'll build the features out in a later post :)