chapter 5

Value-Based Pricing | Deciding How To Charge Your Clients

Today Ben Crudo Consulting is an eight man (and counting) development shop. We didn’t start out that way though. As our name would imply, you only used to get Ben Crudo when you hired us.

When I began consulting, I took any job available in order to increase the size of my portfolio and help build up my reputation. In an effort to keep prices down, I would bill strictly by the feature. I found that it was a lot easier to make a deal with someone based on the delivery of a feature, since that’s ultimately what the customer is interested in.

You have to be careful when making contracts with clients based on features though — this can be a double-edged sword. Things can easily go awry if you don’t scope out the requests in enough detail and ensure that the customer has the same understanding of the project as you. Since the customer is always right, you might be forced to repeat the implementation a few times to make them happy, which can be quite costly for you.

Things can easily go awry if you don’t scope out the requests in enough detail and ensure that the customer has the same understanding of the project as you.

To protect myself from scope creep and errors in estimation, I always provide a small range of costs in my proposals. Estimating the effort involved in completing a software project is extremely difficult in general, but it can be even more complicated if you’ve missed the mark with your implementation. Maintaining a little wiggle room with your pricing can make the difference between winning and losing on a contract.

Trust is hard to come by in the software consulting business. Developers are often compared to mechanics because they speak in cryptic foreign languages, like HTML, JavaScript and Ruby, about concepts lay people don’t understand. Making sure that you and your customer share a mutual understanding about what you’re going to develop is one of the most important things to do on a project.

As a matter of principle, no one likes to be told that they need to pay more for something they’ve already negotiated for. That’s why as a company policy we guarantee our clients that their bill will not change so long as the mandate remains the same. This means that as long as we are effective at eliciting requirements from our customers in the first place, we’ll be able to estimate the workloads effectively and keep them satisfied.

Unfortunately, like many things in life, this is much easier said than done. Gathering requirements for a software project is an extremely difficult task to complete accurately. To make things more difficult, often times customers aren’t able to articulate their needs precisely, making it even harder to craft a solution to suit their problem. Sadly for developers, software is so fickle that even the slightest change in requirements could spell a lot more work on a given task.

In the context of doing contracts on a set budget, the details really matter. Whatever you can do to make sure that the customer understands what you’re delivering, the better off you’ll be. I would suggest leveraging every tool at your disposal to clearly define the functionality you’ll be providing to the client. Wireframes, mock- ups, UML and user stories all play important roles in specking out a software project. Each document type you produce should describe a unique aspect of the project. This demonstrates to your clients that you have all of the bases covered and acts as a good start to your implementation and project plans. It can also come in handy when a customer comes back to you after six months with a signed proposal that you may have already forgotten about.

Whatever you can do to make sure that the customer understands what you’re delivering, the better off you’ll be.

Changing your pricing strategy from feature-based to project-based happens naturally over time. At first my projects were just single features, so it was relatively easy to price them out. Once the projects started increasing in size and complexity, customers demanded that we provide them with more comprehensive quotes. Unfortunately again for consultants, it’s much more difficult to estimate a larger project than a smaller one.

The number of deliverables you provide acts as a baseline for the number of potential mistakes you can make. As it turns out, experience is the best way to minimize the mistakes in estimation. Once you’ve done everything at least once, you learn to recognize the common pitfalls and will be much better at identifying sources of risk in your projects.

Apart from making every mistake at least once, it’s a good idea to have lots of documentation to guide you through the sales and development process. The bottom line is that the better you are at understanding your customer’s needs, and the more experienced you are at solving similar problems, the better you’ll be at costing your projects and making sure you come out ahead every time.

About the author

After completing a B.Eng in Software Engineering, Ben Crudo started building websites and apps on Shopify, and today he is one of the top Shopify Partners. Ben is the principal solution architect at a consulting firm that bears his name, and leads a team of software developers on dozens of projects annually.

Next chapter

6. The Contract | How to Draw Up a Client Contract

5 min

Grow your business with the Shopify Partner Program

Learn more