The original text of this article can be found at:
https://eastcoastproduct.com/blog/how-we-price-digital-product-design-development
Stop me if you’ve heard this one before: recently, we sent a proposal for a project over to a prospective client to get their feedback. After speaking with them and determining their needs, and after consulting the initial functional requests they’d put together, we drafted a project timeline, a rough progression of activities, and the team members we’d need for each phase. This gave us a cost estimate which was included with the timeline for the prospect’s review and (hopefully) approval.
If you’ve done any project pricing before, you probably know what happened next. We got a request to detail out, line by line, exactly why it cost so much and where each dollar was going. This isn’t really possible when pricing works the way we and other successful agencies do it, and I’m going to explain why.
Why can’t we do line item pricing?
We can’t tell you what each piece of your app will cost because the complexity of a software product isn’t in the individual pieces of functionality, it’s in the relationship each piece has with every other piece. As you add functionality, complexity increases in a nonlinear fashion. It isn’t even possible to define what a “standard” login process requires because additional functionality might make your login more or less complex. And once you factor in the need to understand and respond to unique human behavior discovered during the design process, it gets even more complex. So, we can’t make a list of what each piece of functionality costs in the final total.
Instead, we start pricing with a basic formula for time and materials. In the case of the work we do, that mostly means time. East Coast Product bills by the week, and a week of time for any individual on our team costs $X. If a particular project needs 3 people then we’re going to charge $X×3 for each week. Each person on your project is only working on your project, and should be the same designer or dev that’s been working on your project so far. Simple, right?
Planning out project phases
Let’s look at the beginning of a project. Depending on how well-defined your problem is, we may do a simple discovery phase for 1 week with every member of the team and a primary client contact. During discovery, we get familiar with all the requirements and their priorities, define success metrics, and put a clearer structure around how we’ll make our milestones. If your problem is thorny and ill-defined then we’ll want to run a design sprint to learn more. Maybe that’s one of our designers facilitating for a week with just your core project team, or maybe there’s a good reason to add our devs into the mix, or for us to bring in additional bodies for the idea generation phase because your team is small and we want to optimize for good results. This will vary from project to project.
There are probably several other phases we’ll want to map out. We have a rough idea of the order we’ll go in, and inclusion of these phases will be based on what information you bring to the table as a client and how well it’s been validated. For example, we’ll want to map out how individual pages of your app relate to each other. To do this we need to understand the mental model of a user for your task. Maybe this mental model is simple enough that we can guess what it should be up front and build a quick prototype to test it with users, with a high degree of confidence that we’ll just be validating our original assumption. That could only take a week, with just the designer and the lead developer involved so they can figure out routing for the app’s backend. Or maybe you have a task that currently doesn’t have a reliable mental model, with multiple user roles. This could take several weeks, with an extra designer involved to assist the primary designer.
Many projects will look something like this:
- Discovery/research
- High-level navigation prototyping/app routing
- Prototyping more detailed user tasks
- Building primary app views and starting user tests
- Creating a visual identity and design system
- Building any detailed custom functionality
- ???
- Bug testing/visual polishing
The beginning and end can be mapped out pretty confidently based on what information the prospect comes to us with. We can figure out how to fill in any gaps and create the time to fill them. Steps 4-7 are where things get fuzzy and we need to rely on our past experience and judgement.
Complexity = $$$
When we first start to understand project requirements, we’ll relate those requirements to something we’ve done in the past. A project may feel like a $160k project because it resembles a project we built for around that amount. That feel is based primarily on the desired outcomes for users, and how the different functionality that creates those outcomes will relate to the rest of the app. Basing that on past projects of similar estimated complexity helps us make more accurate guesses.
But prospects don’t care what a project feels like, and who can blame them? You can’t budget and forecast based on someone else’s feelings. We get that, but people need a ballpark to work with when we start talking, so that’s how we get there. If we did a similar project for $160k then the range we open with might be $140k-$180k. Over time we’ll figure out how to make that number more precise.
To do that we need to figure out what information we’re missing, what assumptions are being made and how dangerous they might be if proven wrong, what the users are like, etc. The first several phases are mapped out around answering those questions. Then we reach the middle, where things are fuzzy.
We started out relying on our cost estimate based on that original ballpark pricing from a past project. But as we move through the beginning phases and understand the project better our idea of the price will improve. The project may get more or less complex. That’s why we do weekly check-ins and bill on a bi-weekly basis. Our clients stay on top of the process the whole way through. They always know what progress we’ve made, what we expect to do next, and whether our estimate has increased or decreased. They always have an opportunity to pump the brakes, or to adjust planned functionality and scheduling to accommodate new information.
A dirty secret
And that last paragraph is where the dirty secret of this type of work is exposed. It’s impossible to precisely tell a prospect what their project will cost before we’ve started it. But how do you know that the “fuzzy” middle of the project isn’t just an opportunity to jack the price up once we’ve started work?
That’s where trust has to come into the equation. We build trust by scoping and planning the entire project together, by demonstrating that we’re professionals, and by providing references from people who have worked with us through this process in the past. Proposals are created together to establish a mutually beneficial outcome. We can establish options that will meet a prospect’s goals in different ways based on demonstrating what happens when we price for more and more priorities from their list. And prospects can watch their estimate tighten up as they get used to working with us and see how we refine the workload to best accomplish their desired outcomes with their available budget. If certain tasks end up taking longer than we initially expected we work together to adjust priorities so we can stay within the original timeline and budget or add time if necessary. If we’re moving more quickly than we expected, we can return that to a prospect either by finishing earlier or spending more time testing and polishing.
The members of our team have experience across hundreds of successful software projects and we’ve distilled this process from their collective experience. If you’d like to find out what a successful project could look like for you, get in touch.