In a recent article on Forbes Ilya Pozin tries to answer the question “What does a Website Cost?” Before he starts to explain the challenges of pricing, he apologetically admits that after working on 2,000 projects he “…still cannot answer this question.”
As someone who has estimated thousands of web projects, I feel his pain. Deeply. For as long as I can remember, there has been a conversation about the difficulty in measuring projects by the hour. I really want to find a concrete solution for this problem and not blame subjectivity or lack of standards for not pricing our services. Clients and web designers/developers are both getting a raw deal if we don’t figure this out. Given its importance to modern business, we need a more scientific method to determine the value of design and development work.
Bigger isn’t better, it’s just more complicated
In fairness to Pozin’s dilemma, it seems the article was aimed at smaller website projects. Small projects are inherently problematic because the lower-end of the market is either made up of unsophisticated buyers (i.e. never been in the market for a website before) or restricted by a lack of funding. Buyers of small websites (less than $20,000) tend to think about the price of a website project in terms of what they have available to spend rather than ultimate value (visibility, leads, orders, etc.). Nothing you do or say will change how much capital a small business has to spend on a web project. Add to this equation the innumerable entrants to the supply side of the lower end of the market and it becomes an elastic mess. There are thousands of aspiring designers and developers that are willing to undercut project costs just to get something into their portfolios. It’s safe to say that there will always be lots of price elasticity and discounting at the lower end of the web design and development market. I’m going to avoid this commoditized end of the market for now and focus on the upper tiers of digital product creation. For the most part, large complex web application designs most commonly undertaken by enterprises or funded startups have challenges related to return on investment. They question the value of investing dollars into products as part of their long term goals. It’s this value conversation I’m really interested in.
The Bermuda Triangle
To understand how professional services (including web design and development services) are valued by the industry you need look no further than the Project Management Triangle. Sometimes called the Iron Triangle, there are three fundamental aspects to designing and building everything: cost, scope and quality. Often *scope* is replaced with *time* on the triangle. The triangle is supposed to guide decisions on where resources can be applied or removed from a project. The common refrain is, “Pick two because you can’t have all three.” In other words, if you need the project to be inexpensive but maintain features, you’ll need to sacrifice the quality of the results. For the most part, this is true. It’s extraordinarily difficult to produce a great product if the scope is broad and the money is not there. My concern is that this simple model doesn’t fully explain the value of the work being done or the impact that the work has on the client’s business. The triangle itself is not the problem.
The problem is that the triangle’s practitioners use it, unwittingly, as a scapegoat for not doing a direct calculation for the value of a project. To further complicate calculations, it’s not uncommon to hear designers or developers remark that quality is almost impossible to determine because it’s subjective. To avoid having the *quality* conversation, they then scope projects on the cost of time for the required deliverables. We’ve been guilty of doing this ourselves, and it’s taken some time to find alternatives that benefit both sides. Time has many forms though. Some firms and agencies have escaped the billable hour and moved to broader time containers like weeks, months or sprints (generally a 2-week period).
In development services the “man month” is also a common measure of effort. This is a calculation of the resource cost over a single month. Regardless of the period, time is still the common denominator for valuing the services. Whether you build from the bottom up and use hours as your time unit, or if you boil it down from salary, you’re still using time as the measuring stick. There’s no calculation for the other factors. For example, how do we calculate the cost of choosing the wrong vendor or the opportunity cost of not doing the work? The bottom-line is that the ‘cost of time’ approach forces the industry to use billable hours as their sole basis for calculations. It ignores the essential question of any successful project – was this the best use of my budget?
As mentioned, design and dev studios use either hourly, weekly or monthly rates, but there are some exceptions where firms charge a fixed rate for a project. Fixed rates are also pegged to time and materials but in an indirect way. The firm estimates the time and materials for a project and then wagers that they can do it for less time and make a fair profit. This is very risky. It can be used for small projects or discrete tasks, but it hardly ever works on long or complicated projects.
The Client’s Viewpoint
On the other side of the market, clients generally use a market rate to determine what they think a project should cost. If they think they can do it cheaper internally, they may go that route. The latter option is becoming increasingly less attractive. Like other industries, building an internal team is lengthy and expensive. You don’t start your own construction company to build a skyscraper. Most progressive companies will choose to outsource the work. To determine the price of the work, they look outside the organization for a valuation. They either compare estimates from multiple vendors (e.g. RFP process) or they use internal calculations based on internal deadlines and budgets. Neither of these is optimal because they lack the expert understanding of how those tasks are performed. The winner of an RFP process will indicate who was the cheapest but not the best. Internal budgets tell you nothing about the actual cost of the required work to complete a project and only serve to provide a source of friction during the project valuation process. The hourly rates used by the web designers/developers undervalue their effort, and the client’s reliance on the comparative market rates simply reinforces this undervaluation. This is a lose-lose scenario. If the project is undervalued, the firm or studio will fail to meet its obligations and the client won’t get the quality they desire.
Lets look at a typical example of how this plays out: Jane is a CMO of a company that provides a B2B software application to the healthcare industry. The company needs a new website and user interface for their web application. Because the application will be used by practitioners on several different handheld devices, because of this the web application may need to be responsive. Jane starts the estimation process by working with her product team and detailing the new features as well as they can. They might even create a priority list of these features. Not really knowing what each of these features will cost, Jane asks around the office and hears things like “when I did a web project at my previous company we paid $XX for that kind of stuff” or “the last company charged us $XX to build the original site, but that was a few years ago.” Jane has lead web design projects before, but none as large and complicated as this. She’ll need several domain experts to collaborate on the project.
The standard solution to this requirement is to hire a consulting company from a short list. The value of the work provided by these expert consultants is generally valued by the time they would be investing in producing the solution (or product). She gets a few proposals, has a few high level conversations, and then pulls the trigger. She still has no idea of the real cost of the work because the only comparison she has made is among vendors. Again, we find ourselves measuring the work against time and not value. Jane’s experience shows us why paying for time is a broken model. Measuring the time a consultant spends on a project is counterproductive.
Equitable Value Based Pricing
The possible solution to getting an accurate estimate for the cost of a custom design and development project lies in a concept called value based pricing. There are two ways to look at value. The first is the value this work has to the organization (also referred to as return on investment), and the second is the value of the resources required to create the output. The latter method is similar to a working capital calculation. In light of the fact that it’s very difficult for a company to know the ROI value before the start of a project, we should focus on using the second value calculation – working capital. The idea behind working capital is that a business should always have more assets than liabilities. The difference between these two numbers is the working capital. Obviously if you have more liabilities than assets you can run into problems. The goal is to make sure you employ your capital so that you don’t hinder your growth opportunities or hurt your cash flow obligations. For a company to understand the value of a custom design and development project, they need to know what capital is being employed to make the project success possible. Using the working capital as the value basis allows you to do this effectively. A project’s value should be compared to the cost of what full-time employees (FTEs) would be paid to do the same work. Instead of measuring the value of a project on the time it takes to build something, the client team would measure the value based on the equivalent effort if it had to hire all of those people internally.
Here’s a real-world example of value based pricing: Jeff, the Chief Product Officer at Flashnotes, a SaaS business, will be starting an overhaul of his website and web product UI. To estimate the scope of the project Jeff makes a list of all the features and functionality the project will need. He adds to that the content requirements, expert input and the time he’ll need from his internal team (meetings, reviews, decision points, etc.). Now that Jeff has an outline of the work ahead, he compares his requirements list to the skills those things will need to get done. For example, he sees that he’ll need about 5-6 pages of original content on the new website. This will require a copywriter or content expert, neither of whom the company has internally. He makes a list of the types of people he will need to have on the project. Even though these people are not on his staff, he prepares himself for the question, “What would it look like if I had to hire all of these people full-time?” Here’s what Jeff’s list looks like:
- Senior UX expert: User experience planning and architecture
- Senior User Interface Designer: Lead visual design and layouts
- User Interface Designer: Second visual designer to provide assistance and redundancy
- Senior Front-end Developer: Coding or development of UI elements
- Project Manager: Project management and administration of the project
Now that Jeff has a list of the skills he needs he can make an estimation of what it would cost the company to hire those people full time. The cost of each person can be estimated from public survey data and salary guides on the web. In this scenario the range was $300,000 to $500,000 depending on the seniority and experience of the team members he wanted. Once salaries are added Jeff still needs to add the cost of hiring. This includes internal interview time and recruiters costs (normally 20% of first year salary), the cost of onboarding and training, and the opportunity cost of time lost to this process. This is the real cost of the project. The value of the project can be calculated by comparing this cost to the cost of hiring an outside firm.
If Jeff were to invest $500,000.00 per year in a team of FTEs, he would have a negative return on his investment. In other words, the future value of his investment in permanent skills is equal to the completed product’s present value less the initial annual investment. Or $100,000 – $500,000 = -$400,000. Needless to say, Jeff is in a very big hole. What’s more is that he may need to carry those costs annually if those FTEs remain with the company.
What does this mean if you are considering a website redesign or an application UI project? Well, if you had a choice between making hiring decisions that will cost you $500K over the next several months or paying $100K for something that will provide a return on your investment over the same period, you would do the latter. It’s a no brainer.
Here’s Jeff Kushmerek’s own words on the experience:
Even if the company decided to hire part-timers or freelances they are still dealing with the same expenses and ongoing costs. Because design and development part-time staff is in high demand right now the company would still need to go through the search and recruitment process. Hourly fees tend to skew higher than salaries rates so there’s no cost saving there. In fact, it might even be more expensive to hire part-time designers and developers. Although there are lower ongoing costs related to paying benefits, the opportunity costs remain the same.
To illustrate further consider the following experience: Peter has a big interview next week with a future employer. He’ll need to get downtown from his home in the suburbs twenty miles away. There are no buses where he lives but he has several other options. He can take an Uber (black-car or SUV service), ride a bike, or drive a car. The only catch is he doesn’t own a bike or a car. He could buy either. Buying a car can take a long time and is really expensive, but then he’s guaranteed to get to the meeting exactly when he wants. The bike is the cheapest option but he’ll be sweaty when he arrives – not the best way to impress at an interview. The Uber is going to be way less expensive, expertly driven and still very reliable. The logical choice is the Uber. Obviously, this is a metaphor for building a website or app. For comparison, buying the car represents hiring a full-time team (expensive long-term and complicated to purchase), the bike represents a freelancer (cool, but not always the fastest option), and the Uber represents a firm of experts for hire. So why do so many companies still buy the car?
In this example, the ownership process is bureaucratic: cars can break down, get stuck in traffic, and the long term costs are significant in comparison to the public transport or biking options. Here’s what it looks like when you hire a team of experts:
The Unreasonable ‘Product is Strategic’ Argument
It’s been said to me a few times that the reason software companies have their own product design and development teams is because these activities are strategically important. I agree with that statement. What I disagree with is when those activities become strategic and for whom they are strategic. The creation of a software product goes through many phases. In it’s early stages the product needs to go through fast iterative changes. Prototypes and alpha builds are tactical. They test assumptions and seek evidence for traction. The best strategic hire you can make is a full-time product manager. Building a big product team before you have a product is financially irresponsible. Lean UX has taught us that going big out the gates is silly at best and fatal at worst. The argument that hiring a complete design and development team is an essential and strategic requirement is only relevant to the previous generation of software and tech creators. That argument holds no water in an economy that has high expectations of quality and low tolerance for failure.
The solution is not black or white. It is infinitely easier to build a product when you separate the evolution of that product into stages. Each stage needs a different set of resources and considerations. Early on in the process you want to be moving fast and keeping risk to a bare minimum. You do that by working with a strategic partner , not adding headcount to your payroll. As you grow you can bring more of those people costs onto the permanent payroll. When the time is right and you have traction in the market, you can hire a full-time design and development team.
Sharing the Load
My last point is about the sharing economy’s influence on this logic. If you live in a city, you’ll notice we are slowly moving towards becoming a sharing economy. We already share desks (co-working space), bikes (Hubway, Velo), homes (AirBnB), cars (Zipcar, Lyft), retail space (pop-up stores), education (Coursera, Kahn Academy) and labor (TaskRabbit). Getting help is a way of life for almost every business on the developed world, and yet the we hold onto the idea that innovation has to be an internal employee-owner activity. Sharing the design or development of a website with a strategic partner is advantageous in more ways than just price. It gives you access to cutting edge innovators without the hassle and opportunity cost of full-time labor costs.
Go ahead, start sharing.