WordPress Services and My Pricing Strategy

Pricing has always been a painful topic for everyone, both clients and contractors/companies. Clients try to keep it as low as possible (normally) and contractors try to earn more (again, normally).

There are quite a few videos, books, tutorials and blog posts on the subject, and not as many people talking about that. Chris Lema is one of the most open people when it comes to pricing, and he’s helped me to negotiate on projects and find out the best possible way to discuss projects with serious customers who would like to build a given software and have a clear vision when it comes to their business planning (thanks Chris!).

The last guest post in his blog made me think for my pricing strategies and patterns that I apply, and few major issues I have. Since most of this is quite subjective and depends on different factors, such as:

  • your client and his/her approach
  • your selling skills
  • the type of project
  • the skills required
  • your background and references

and others, I’d like to point out a simple use case with three steps that I discuss with some of my clients.

So, overall we know the following: clients pay, therefore they wouldn’t like to pay more than needed to solve their problems. They need a service/product developed in a given amount of time.

What we discuss first is the very well known Project Management triangle. To achieve a high quality, there are three parameters: scope, cost and schedule. A client should ALWAYS sacrifice at least one of these to achieve the goals. So, if the timing is crucial, the scope should be reduced and/or the cost would be high. If the budget is too low, it would likely take quite some time and the scope would drastically be reduced. If the project is large, it would make sense to take longer and cost more.

I always ask clients for their budget. I’ve never been good at estimates since I try to work on new projects that include new libraries, APIs and much more that I hadn’t worked with so far (since I’m interested in adding more skills to my own skillset and don’t want to do the same project over and over again in the exact same pattern every single time). I have some rough numbers in my head, but I see budgets in the context of cars – the higher your budget, the better car would get. Otherwise you won’t take advantage of the latest car models or their extras (for automated parking or some heaters or anything included in the “full” model).

So, my pricing strategy that I share with my clients is the following. We have three possible scenarios:

  1. Lowest possible cost
  2. Reasonable and “likely to be enough” cost
  3. Tempting cost

My background with enterprise systems, languages and platforms allows me to specialize in a given niche and I do my best to deliver the highest quality when it comes to coding standards, scalability, security, extensibility, compatibility and more. Therefore, I prefer to work with fewer clients on larger project. Multitasking is your enemy if you build exotic algorithms and take care of millions of use cases, so you need to stay focused for a long time, do some testing (often TDD/BDD comes in place), plan, draw architecture plans, use design patterns, benchmark etc. In order for me to cover my costs though, I need to charge a lot for these projects, and it’s a deal breaker for smaller clients who would rather keep the cost low (referring to the project management triangle).

Therefore, revising again the three possible scenarios:

1) The lowest possible cost is the exact price that I would “guess” for the time I would need to solve the given problem in the exact same context provided by the client.

2) The reasonable cost applies to the same scenario, but it also adds up a few hours (or so) for some side cases that would probably come up, or some details that haven’t been discussed clearly.

3) The tempting cost would cover everything and, according to the initial estimate, would leave enough profit even after spending some time on edge cases and a reasonable amount of communication and testing.

See what I did there? The lowest possible cost is risky. Odds are that some issues would pop up during development, the client would have a few revisions, we’ll spend some time for emails and chats until we clear everything out. The highest cost however would provide me with enough billable time to expand the architecture, do some proper testing, communicate clearly and openly with the client, resolve everything until we reach to the point where both sides are happy.

In theory, the lowest cost is the best bet for clients, since they pay a few bucks compared to the third option. In practice, these solutions approach a given problem in a given context and any side use cases won’t be covered. All communication would be extra and would bring tension to the emails and chats, and likely some hacky “cowboy coding” snippets since the project is already past the budget.

Whenever I work with long-term clients from the third option layer, I take care of invisible issues that they haven’t thought about. I rent better servers, improve the user experience or scalability, hire better graphic designers for icons or logos in the admin panel. The end product is much better than the client planned for at the beginning. I wouldn’t be able to do that within the lowest budget, since it’s most likely that I’d go beyond the budget even without spending additional time on side goodies.

This is one of the reasons why it’s so hard to find good developers for fixing small problems or building very small blogs. The actual cost of the project expected by a client is pretty low, as the issues aren’t serious. However, in order for a side developer to get in, it would require him/her to get acquainted with the existing code base, resolve issues that wouldn’t happen otherwise (if another developer hadn’t introduced them before), not to mention the solid communication time and regressions due to blind fixes. Same goes for consulting gigs that require you to solve a site issue over Skype for an hour or two – how many ways can you think of that would lead to edge cases?

Clients have a hard time to assess how much revenue (direct or indirect) would a software solution bring to their business. A restaurant system saves time to waitresses and bartenders, and protects you from issues with billing and accounting. A small business blog would make your business more popular, and bring a few clients with time. The more you’re willing to invest in your solution, the better the solution would be and the more it would help your business.

8 thoughts on “WordPress Services and My Pricing Strategy”

  1. Kuba Mikita says: June 13, 2015 at 5:45 pm

    The problem is, as you noticed with clients who can’t imagine how good code quality will affect their websites in future. They expect “working quality” with (almost) zero cost.

    On the other hand starting any big project for serious client is much much harder.

  2. Mario Peshev says: June 15, 2015 at 1:20 pm

    Thanks for the comment Kuba!

    Lately I’ve started to recognize the need for step-by-step growth. It doesn’t make sense for a small business to start with something huge. It’s a natural way to evolve and incrementally grow value and build quality. That said, I don’t have a problem with starting businesses being unable to build something outstanding, but still being aware of the quality difference.

    What I disapprove is growing businesses that can’t find a difference between poor and high quality or invest tens of thousands in ads while asking for a $200 website.

  3. smithG says: June 7, 2016 at 9:03 am

    Excellent Post! But if you take code quality and turnaround time into consideration or to know more you can also go through the following link http://www.markuphq.com . MarkupHq Company follows easy steps to convert PSD to WordPress. We deliver 100% hand-coded, W3C validated, cross-browser compatible and pixel-perfect PSD to WordPress conversion services. Starting at just $89 for the homepage and 50% or more discount on each inner page.

Leave a Reply

Your email address will not be published. Required fields are marked *