Costing a website or webapp: A guide for the non-developer
I won’t cover how estimates are produced, or how to conduct the actual project management – these are covered in loads of good books such as James Shore’s: “The Art of Agile Management“. What I want to cover here are initial techniques that you, the stakeholder, can do to help get the best estimated costs for your webapp or website.
The question “how much does it cost to build my website or webapp?” is like asking a builder “how much does it cost to build me a house?”. It totally depends of your requirements. As with all estimates, Requirements Are King.
“Requirements” are based on 2 fundamentals:
- Your understanding of what you want
- Your ability to communicate the requirements in a easy to understand way, and continue to communicate them as things change.
Even given detailed schematics, for custom, original projects that may change once building has started, the best any bricks and mortar builder can do is to provide a good initial estimate and then keep you updated as the project progresses. Web-app production is no different.
The cost structure for custom web-app development is most often based on an hourly charge rather than a flat fee. This is because the level of satisfactory implementation is variable for every customer, and is only really understood by doing and communicating. This doesn’t mean that an initial cost estimate can’t be reached, but it does mean that it should always be viewed as a continually updated guide.
They first step is to understand that you are the visionary, so only you know what you want. If it’s not written down, no matter how many people say: “yeah, I get it” etc, don’t be deceived: they don’t.
So, how do you cost up something that exists only in your mind? No tricks here, you have to to solidify it into detailed storyboards explaining the scope of what you have stuck up in your noggin. You’ll get best results doing this by hand on big bits of flip chart paper. Start big and vague to get a general feel for the entire site, and then iterate over each page gradually redrawing and refining the details until you have something that is like an annotated engineers diagram. Don’t get too distracted from your core idea, and the moment you sense yourself drifting off into “generic” territory, stop yourself (eg, “hey! it would be cool if the users could make friends with other users etc”).
Next, start to draw generalised flow charts of all the bits that won’t be visible to the user but that will be going on under the hood. Again, start very broad, and try and break down each stage of the flow chart into sub-flows.
Identify any black-box, “unknown” areas in your flows or storyboards that you have no experience of (eg, “fancy prioritisation algorithm”, “handwriting recognition”, “print money” etc).
Finally, go over your storyboards, and flow charts and replace any general words like “data”, or “information”, with more specific descriptions of what you actually want. Any areas where you don’t know what to put down instead get put into your list of black box areas for open discussion with your developer/expert.
At this stage, you should have the rough requirements of the product you want to make. You’ll also know the areas of your idea that need more work (the black box bits).
You should then identify a web expert and black box area expert(s). I say experts, but anyone who knows more that you will move you forwards. Working with this person(s), attempt to break down your storyboards, flows and (especially) black boxes into broad areas of work. Some of these areas of work may not stem directly from the storyboards, but may be a prerequisite (eg: setup programming tool X, bank manager Y, data agreement Z).
Prioritize the areas of work. Then break down the top few areas of work into smaller task/job like chunks and prioritize these.
At this stage, you should have a prioritized list contextualized by the area of work and ultimately your design to the best of your ability. Some of the lower priority items are still vague, but the most important bits should be fleshed out as best you can.
Next, revisit the list and ask yourself: “What are the bare minimum components that will get my idea out there and capture the most proportional value”. Have a good think. These components are the things you should aim to get done in your first release/set of work, and the things you should aim to get estimates for.
Try and broadly group the remaining components into clear chunks ranked by ability to add proportional value to your site. Then forget about everything except the bare minimum components defined above. The idea is that there is not much point trying to cost areas of secondary importance, as they are likely to change based on the success of your first stage anyway.
The final stage in this initial should be refining your storyboards taking into account the smaller scope of your new prioritized list.
Once this is done, you have something to present to a developer or development company for coming up with a decent estimate, and for creating your site. Be aware that as soon as development starts and the first demos start coming out, you’ll want to revisit your prioritized list, and repeat the above process until the site is built.