Our original post on pricing divergence is one of our most popular posts ever. In that piece, we highlighted some of the factors that drive web projects' pricing based on the type of entity your developer is a part of. An agency, freelancer, or large-scale enterprise group all obviously have different business models, overhead costs, and processes that can affect their pricing.
This post, however, is going to look at pricing divergence from another angle. There are two types of web projects – the short, quick and easy, which pay less attention to compliance, validation, accessibility, and the like, and the comprehensive, holistic approach, which is concerned with those items above and then some. When I meet a new client for an introductory call, I often talk about budgets and timeframes as quickly as possible. The reason isn't that I'm looking for some sort of edge or maximizing my revenue. It's because I'm curious what category the client is in. If you've had a call like that with me, you'll know this line because you've already heard it: There are literally hundreds of ways we can complete a project.
As I mentioned in referring to our previous post, the agency or developer certainly can affect cost. But the methodologies and areas of focus in completing your project matter even more. This week, we want to focus on specific feature requests that result in additional production time for design and development projects. Since this list can be ever-changing, we're focusing on the issues of importance right now, in 2021.
Most significant Cost Differential: Build vs. Buy
One of the most enormous cost differentials we see is when the build versus buy debate is in play on a particular project. Typically, we see this when a project's use cases are more complex than what off-the-shelf software can handle. A good determining factor in making the decision is usually trying to understand if the software's customizations would either make it unstable or make it untenable from the perspective of future updates and upgrades. When those factors become issues and a client determines that a custom build is the better option, the cost can significantly increase.
We've written before on the subject of build versus buy and the limitations of off-the-shelf software. As I've always said, there is a time and a place to license or buy, and the same goes for building. The value a good agency or developer brings is helping you make the calculation of what route forward makes sense. In many cases, the maintenance required to upkeep a complicated off-the-shelf scenario would end up costing over time the same as a custom-built solution that had fewer ongoing concerns. This is a formula that must be carefully considered if you are engaging in a debate about which direction you should pursue.
Prototyping & UI/UX Details
The avenue you take to arrive at a completed design can dramatically impact overall pricing. Companies can choose to simply design interfaces and then approve based on whatever criteria they internally care about on the low end. Frequently that merely is how visually appealing the design is. I've seen this process play out at the mom-and-pop business up the street all the way up to corporations with ticker symbols you'd recognize. And that's fine if they are okay with it.
But UI/UX can get so much more complicated. User studies, persona development, analytics research, wireframing, UX testing, revision… And in some cases, completely functional prototypes. These all add up. This is how a website with twenty unique templates can cost an enterprise organization $500,000, and the same footprint can cost a small business $25,000. I'm not making any recommendations about what is right or wrong in your case, but merely pointing out the obvious and reinforcing what I said in the intro: there are literally hundreds of ways these projects can be completed.
Compliance Requirements
We have written frequently about compliance with the various standards in place today. Most recently, we've covered CCPA, and before that, GDPR. That among the various other standards such as PCI (more on that in a bit) and HIPAA all add up to serious matters that require consideration. The general rule is that the more compliance you seek to address, the more things will end up costing in terms of development, design, and administration time. Luckily, many small to medium businesses are carved out in terms of compliance. Specifically, if you look into the details of CCPA enforcement, you can see that it explicitly excludes companies below a certain scale. It is essential to understand what you must and must not comply with. But, as you realize you will require some of these standards to be met, be aware that they will be a factor in driving up the cost of a web project.
Accessibility
Accessibility has, through the years, become a primary pillar of our service offerings here at NP Group. Within that time, we've studied how we can, from a cost-effective way, introduce accessibility as a service that doesn't break the bank. Overall, we feel that the most budget-friendly way to achieve compliance is to design for it from the first day you begin your project. However, that still does mean additional effort goes into design and development to achieve compliance. As such, strict adherence to standards such as WCAG 2.1, at a AA level, will be a cost differential when completing your project. This is because of a few reasons. First, more work will be required during design and development. Secondly, internal audits would need to be conducted, and finally, any remaining issues would need to be addressed. While that process is somewhat similar to doing an audit and remediation later, during the initial design of a website or application it is much more efficient and takes a fraction of the time and effort. Despite that, however, it does add to the bottom line pricing of a web project.
Security
Security standards matter, and typically these mean you will incur two kinds of costs. The first will be up-front costs spent hardening your software and securing it to industry standards. From there, you're also likely to incur ongoing charges to maintain a secure infrastructure and react or respond to any issues as they arise.
Security is a spectrum. Smaller businesses may rely on their host and developer to keep things reasonably safe. But larger companies, or companies whose clients mandate additional security levels, will often be subject to more stringent requirements. Because of this, the cost to secure your site can vary dramatically. A WordPress plugin to detect threats and a host with automated updates may suffice on the low end. On the high end, you are looking at coding changes, infrastructure security, monitoring and response, and of course, a series of documented policies that outline your security procedures.
DevOps
A significant price differentiation area often comes from the mechanisms in place to manage development procedures for an application or website. DevOps can best be described as a series of practices that involve both developers and IT operations. Thus the name "DevOps." It isn't unusual for smaller agencies or freelancers to have no approach to this at all. They just build something, deploy it, and then are on their way.
Larger agencies, who work with more sophisticated clients, have a series of stages and procedures to handle the entire lifecycle of development, testing, deployment, and monitoring. Much like security, there is a spectrum here, and depending upon where you fall, it can affect pricing considerably.
These days, most small to medium businesses without InfoSec requirements would benefit from a rudimentary DevOps scenario. This means code repositories or source code management tools, procedures around testing, and further deployment procedures that account for approvals, rollbacks in the case of issues, and so on. On the other hand, Larger organizations will spend much time onboarding developers to their procedures, which will add to the project's overall budget, as the new team is acclimated to the process and the policies.
Performance
Performance was always a factor for clients – no one wants a site that loads slowly. Today, however, Google is taking it to the next level, requiring sites to focus on user-perceived "speed" and require a more in-depth look at how a site is built. These new standards are known as the "Core web vitals" and are a series of performance indicators that judge a website's performance. And trust me, to pass these tests, you have to dig quite deeply into your site's structure, coding, and even server infrastructure.
Compliance with these new vitals has been announced as a new ranking factor, to be considered sometime in May of 2021. Webmasters will have to comply to stay in Google's good graces. At this point, I don't have an educated estimate as to how many sites comply, but I'd guess that more than 90% do not. I haven't run across many sites that pass the PageSpeed Insights test. As such, this will be an area of opportunity for those who wish to compete organically in the short term. But, concerning this post, development for Core Web Vitals is a time-consuming task. It requires a more stringent development methodology and a ton of testing to achieve. All of this translates to time, which, as you already know, increases budgets.
Third-Party Integrations
I'd say that at this point, almost every project we complete has some level of third-party integrations. This means utilizing a product or service that makes sense for your needs and integrates seamlessly into the project you are building. For the most part, today, that happens via API connectivity. In the past, we had to get much more craft in these scenarios. Even today, we have to revert back to our old tricks – just not as often.
API integrations and the time required can vary based on three factors. The first factor is the most obvious – what's the depth of the integration. This means how much work integrating will need to be performed. Ideally, this is scoped and specified before a project begins development.
The next two points are based on our experience having done hundreds of integrations. Is the system we are integrating well documented? Almost every platform these days promises an API. However, do they document it, and is the documentation current? I'm always amazed at how bad some APIs are when we first dig into them, even from larger organizations that promise them as a selling point. A poorly documented API means much more time to work with – especially if the system is doing a lousy job giving us verbose responses to our requests.
Finally, is there a human being or quality support methodology for a developer to reach out to? Even the best-documented API often can require some assistance, and it's always better to know there is a person we can speak with rather than left to guess or try our own fixes.
Wrapping Up
In writing this post, I also thought of about ten other items that would make sense. But I believe the items mentioned above are the most timely factors, things that you will be forced to think about if undergoing a project this year or next. The key to ensuring you are getting a fair price and comparing your options is to ensure that you are very clear about how you wish to accomplish the above. Sadly, many agencies today aren't even mentioning all of these items in their proposals, which should cause you to pause and consider if they are capable of completing a project successfully, with your best long-term interests in mind.