On this article we delve into the intricacies of Webflow project scoping, asserting that it goes beyond mere page count. It explores other factors like design, CMS approach, integrations, client training, and asset optimisation, while promoting a shift from "what to build" to "what problem are we solving", fostering more holistic, value-based solutions.
The number of pages a specific site has is a tangible metric Webflow professionals rely on when scoping there projects . It is clear why. This number can be quickly agreed upon with the client. Furthermore, it is really easy to present a proposal where the total is the page price multiplied by the number to be developed. You can even get fancy and establish two or three page prices depending on their complexity.
The problem with this approach is that neglects important aspect of building a Webflow site. And even more more problematic; it makes it a conversation about “what to build” rather than “what problem are we solving”.
Let me explain better with an example. The client shares with you a three page Figma file. Let’s establish two scenarios scenarios.
While the Figma file has the same number of pages for both scenarios, these two are radically different. Based on a price-per-page approach, both scenarios should be priced equally. But focusing in the context and the value of the solution provided to the client, the price for each of them can be very far away from each other.
Let’s list what aspects we should focus on when scoping a Webflow project. from a production point of view, there are several things beyond things count that we should consider.
You might be calling it something else. As Webflow keeps improving Components, we have the ability to give more power to our clients. We need to understand that building a custom component systems is a huge effort at the same time is super valuable for the independence of the people managing the site.
You should always take a CMS-first approach. This is of huge value for the final client to own their side, but also is a good effort to set it up right.
Integrating tools into a Webflow projects is common practice but rarely are clearly defined upfront. While most can be added with a copy/paste command, some others require extra configuration. Make sure to discuss on the following before the project starts
Are you training your clients and how do use their Webflow sites? How much effort are you putting in to it? Measure it and make it count when scoping
You can get help from the person designing the site, but normally is us Webflow developers who take the lead here.
Often forgotten and added in the last minute
Besides the previous listing of tangible deliverables, you should be considering the value you are bringing to the client. Often referred as value based pricing. While is hard to rely on full value-based pricing when delivering Webflow services, we can bring some concepts behind this model when scoping our projects. Here are some questions that will help you navigate better the sales conversations and have much more context when putting a price together.
As you can see, these are open-ended questions that will help you dig deeper on why a specific potential client is seeking your help. This questions are not set to stone. Are an example and you should define your own questions to get the most out of your sales interactions.
In conclusion, the journey to accurately scope a Webflow project extends far beyond the simple measure of page count. It's a comprehensive process that involves understanding the client's needs, the project's unique challenges, and the broader implications for the client's business strategy. By shifting the conversation from "what to build" to "what problem are we solving", we not only foster a more productive dialogue, but we also position ourselves to offer more holistic, value-based solutions.