Despite the modern trend of building content-centric websites to satisfy the wants to recreational web-browsers, there will always be a strong demand for practical websites. Through the innovative abilities of designers and programmers to create new kinds of web functionality that allow users to manipulate and interpret data, users are able to realize real tangible value from the tools that are being provided online.
However, because of the way in which these tools are not always conducive to generating organic traffic as well as a content-focused page or as supportive of social traffic as media-driven strategies, we need to understand how it is that a web-page that focuses on creating practical functionality can be valued as a tangible asset.
The fundamental way to understand the value that is created by the practical functionality of a web-page is to asses it on the basis of its opportunity costs. Even though this side of the transaction ignores the worth that the functionality will create for an end user (don’t worry, we’ll get into that later), it allows us to look at the sheer costs of the property, and therefore assess how it is that it will scale later on. Specifically, by understanding the front-end costs of building hard-coded functionality into a page (from both a fixed and variable perspective), as well as the costs of acquiring that sort of functionality second hand, we can begin to build a cost-benefit model for understanding the risks and rewards of building practical website functionality.
While the cost of building on-page functionality is somewhat hard to determine, we can usually come up with a strong indication of its worth in accordance to the amount of time that it would take for a skilled professional to recreate a similar experience from scratch. This should then also take into consideration the additional costs associated with taking on particularly complex tasks.
|Skill Level||Capabilities||Cost/Hr||Project Length||Project Cost||Example Project|
|Basement Hacker||Informed Copying and Pasting||$15||3 hours||$45||Incremental functionality. Dropdown boxes, login screens, social media integration.|
|Interface Designer||iOS, Flash, Java||$60||24 hours||$1,440||Games, animations, mobile functionality, interactive media.|
|1Application Developer||C, C++, C#, Python, Java||$120||40 hours||$4,800||Client-based functionality, data aggregation and manipulation, complicated functionality.|
While these numbers represent just a broad estimate of how it is that contractors charge for their services, it is important to keep in mind that these amounts are extremely flexible. For example, perhaps a particularly skilled ‘Basic’ Designer is able to re-create the same level of functionality that an Application Developer would have normally developed for ten times the cost.
While it will obviously take them longer than 6 hours of working time, it would still save a great deal of cost on the bottom line. This means that an informed understanding of the capabilities of programming fields allows us to make a very strong ‘make-or-buy’ decision. If we can re-build functionality at a lower cost, why would we ever buy it at the developer-level cost.
On a final note, there is quite a bit to be said for the skills of the Basement Hacker skill-level. While these individuals don’t really have the understanding to build anything from scratch, their ability to apply snippets on their own terms means that we can use them to integrate the functionalities created by multiple skill levels, so that we don’t need to trust the full implementation of the project to a single party. Ideally, we should have a Basement Hacker’s understanding of our project, so that we can understand the nuance of the development process, and the costs associated with it.
End User Functionality
In conjunction with the cost-based valuation of a website, we also need to consider what kind of value a given functionality on a website will create for the page itself. The trick to this side of the equation is to remember that we do it in order to stop ourselves from wasting money. No matter how expensive, geeky, or useful a given application is, that doesn’t necessarily mean it will create the returns we want it too. If you’re ever in doubt, just look at all of the undersold apps out there, and remind yourself that you have no intentions in getting lost in such a barren desert of financial loss. The way to avoid such a disaster is to use comparative analysis and consumer-based cost-benefit analysis.
Comparative analysis of asset functionality involves looking at the apparent value that is being created by a similar asset, and then making a discounted estimation of what kind of value could therefore be created by the functionality that we are making in comparison. While effective in determining the long-term potential for such an asset, and to determine whether or not the functionality is being truly appreciated by the market, it is dangerous in the way in which it does not take into account the fact that each web-page is unique, and will therefore have a different level of uptake for its pages. In order to adjust for these discrepancies we need to carefully discount the worth of our own functionality against the comparative benchmark.
For example, if we are comparing our own social media game against Farmville, we need to remember that Zynga has a massive user base, strong social media integration, and a strong brand presence. Unless we can justify that our asset has a similar presence in the market as Zynga, it is not really reasonable for use to use Farmville as a benchmark.
However, if we were too find a small basket of small-scale farming games that all tend to have a similar level of uptake, we could assume that they represent the market for farming games, and use them as a benchmark for the kind of value that users place on the product itself. If users are generally paying $5 for a farm-game app, and there are approximately 200 users on each game, we can assume that an app is capable of creating $1,000 of value on its own, before taking micro-transactions into account.
The second aspect of consumer-facing functionality that needs to be taken into consideration is the cost-benefit analysis that is being done by the users themselves. In doing this analysis, we need to remember that consumers will always try to make informed decisions about which programs they use. They will do a small amount of research to determine which page suits their needs most, and make their decision based on the asset’s ability to fully meet their requirements. In the event that the competitors should all offer near substitutes, then they will instead be evaluating the costs of the different alternatives, rather than the benefits. From a comparative standpoint, this means that we need to be able to differentiate our own asset as being the most favorable.
Returning to the farm-game example, we can do a cost-benefit analysis of our own game against both Farmville (the incumbent), and the basket of other farm games as alternatives. Firstly, we can look at what it is about the smaller games that makes them an ideal alternative for those few users that choose to use them instead of Farmville, and evaluate if it is a cost or a benefit-based differentiator.
For example, if the items in the marketplace cost less in the alternative game, it is a cost factor that is likely driving the traffic to the smaller game. Alternatively, if the smaller game translates into several different languages that Farmville doesn’t have access to, then perhaps it is a benefit advantage that is sending users their way. In the event that the cost factor is the driving decision maker, we need to evaluate our own asset to determine if we are able to provide our game’s functionality at a similar or cheaper price point in order to remain competitive. If so, then we are likely offering a comparable product, and able to assume that our own product will create similar value for the user-base.
The same can be said if we find that our game offers the same kind of benefits as the multi-lingual game. From there, we can take measures to determine exactly what kind of value is created by the incremental pricing differences, and the incremental functionality differences, so that we can properly discount our assumed value, and make the ever-present make-or-buy decision from a valuation perspective.