A New Approach To A Common Request
My goal for this post is to share how Alpha Alias applies our project first model to the creation of business-critical web applications, and how it can provide more value than traditional methods.
Before I jump into the meat of this post, I’ll first provide definitions of ‘project first’ and ‘business critical’ for those who would like clarifications and context.
In my recent post, “What Is “Project First?“,” I describe the ‘project first’ practice in great detail. To summarize that article: “Simply put, ‘project first’ allows the project to define what, who, and how we execute. We define the project first, then select who will work on it and how that work will be done.”
It sounds like what every agency in the world should be doing, but in fact it’s the opposite. I go on to describe the differences in the article and I highly suggest giving it a read if your understanding of the project first model is still unclear.
What Is “Business-Critical?”
It might not be clear to everyone what is considered business-critical in the context of web applications so I’ll spend a moment painting a picture of what I mean when I use the term.
In today’s world it’s difficult to think of a business that can operate without leveraging some type of web application. It’s essential to have a website, regardless of a company’s industry, and any company that plans to market their business will find it difficult to ignore the direct access to potential customers social media can provide. While they are necessary to compete in most industries, and often vital to your company’s marketing efforts, these web applications are not business-critical.
Business-critical web applications are for companies whose digital presence is vital to the success of their business. Ecommerce websites, airline and hotel booking sites, stock or cryptocurrency investment portals, many SaaS businesses, and digital destinations created as the primary source of lead generation, are all types of business-critical web applications.
A Failure Of The Agency-First Approach
A few years ago I was working at a digital agency that was approached by a client whose website (business-critical for lead generation) was in need of a visual upgrade. The website was built on top of a completely custom application used to manage all of their products. There were about 15k products in the database.
The agency I worked for built WordPress sites and had created a proprietary product for use within the WordPress CMS. Naturally, the agency’s solution to the visual upgrade request was a complete migration of their technical stack to the proprietary WordPress solution and recreating the product management system the client was used to working with.
This action is what we call the ‘agency-first’ model. A client approaches the agency with a challenge, and the agency provides a solution based on what they know how to do.
The project first approach is to understand what the project needs and then provide a solution that brings the most value based on those goals. In this case it would have been to put the budget into UX/UI and talented front-end developers who could build a powerful new front end for the system the client was already using. You could do this with GatsbyJS or any other REACT app with ease.
Unfortunately, the reality turned out to be a mess. The budget went into building an API and integrating the product management system with WordPress, then building out custom features in the WordPress CMS. This activity took the project over budget and the client didn’t get everything they wanted from an interaction or visual perspective. It was a lot of unnecessary and wasteful work, and all because the project was run agency-first.
The issue with traditional digital agencies and their agency-first approach is that their fundamental operational model can’t offer the best possible value for a project. Every agency with a team of developers is only able to operate within the available skill sets of those developers. Even bigger agencies who have the ability to hire large numbers of developers will still try to drive internal efficiency by cutting corners with proprietary processes and products.