A Study of Pricing and Billing Models for the Web

When Brightball first started out, it was a small, two man operation.  Barrett and I had very similar ideas about how programming should be done, so we set out to offer our services to assorted design firms.  Initially, we had great relationships with three firms who sent us the majority of their custom web projects. We did the work, sent out invoices and life was good.

Then we got stiffed on a project for the first time and some cold realities set in (not by the design firm but by one of their clients).  You see, only a crazy person nobody gets into business because they want to deal with billing and collections.  People generally feel like they have something of quality to offer and want to do it for a living. You never expect that you're going to spend over a month of your time working on a project only to get the shaft. 

When it happened, we started talking to a lot of successful business people that we knew to get a feel for their experiences.  We did research into web companies, programming companies, and consultants' billing policies. 

At the end of the day, what we found was a series of trade offs.  Everyone had a different solution in place for their particular business approach to the web.  We found that one common policy was to require that projects be hosted on company owned servers so that they had the ability to pull the plug on a site if a bill wasn't paid after 4-6 months.  Others used deposit structures to make sure at least a portion of a bill was paid in a timely manner. Additional procedures involved charging huge hourly rates so that if even a quarter of the bill was paid, costs were covered.  It struck us as very surprising that this problem was such a major issue for so many people and was seemingly, without a good solution.

We have since attempted several different structures. Because we already offered hosting for performance and support reasons, the "pull the plug" option seemed like a good idea.  Then the second time we didn't get paid for a project, we weren't willing to follow through.  It felt unprofessional and that approach to billing has since gone out the window.

That experience sparked a complete revaluation of what we do and the challenges involved with it.  We are not selling a product like a CMS or a creative process such as a design that may have a flat rate regardless of the time involved.  As programmers, we're doing architecture and construction.  Designing systems and then building them.  Depending on how complicated the system architecture is it can take a lot of time and a long term commitment. 

Salaried employees seemed like the most logical comparison for the need at hand.  Hourly costs could get prohibitive depending on the size of a project so we decided to draw up an equivalent "salary" plan that would allow our clients to sign us to an annual contract for a certain number of hours per month at a dramatically lower rate.  With an annual commitment we'd then be able to make accurate budget projections to hire additional programmers on salary.

Business owners, the vast majority of our clients, LOVED it.  Budget wise, it was easier for them to manage month to month costs and they would be able to get a dramatically lower rate.  There was only one problem, the commitment part.  With an annual contract we may have given ourselves the ability to do more accurate budget projections, but our clients had no such luxury.  Suddenly, we discovered that there was a great desire to sign on but there was a huge concern about the ups and downs of business.  What if they needed to put a project on hold?  What if one month was slow?  Clients needed an out. Then there was the other side of the coin if we offered an out: if we've hired additional personnel based on those contracts, how do we tell them there are no longer funds available to pay for their job?

The salary approach did not survive and as it turned out there were a number of other reasons.  Specifically, if we needed to bring in contractors to handle a specialty aspect of a project then we either had to get them to agree to monthly payments OR have our clients pay those costs immediately while we were paid on salary.  Most contractors didn't like the monthly payment idea and the whole thing was getting far too confusing for clients.  We had to have a four page document to explain our pricing structure.

So we set out to do more research.  In reality, what we do can only  be done on an hourly basis.  Programming time is needed in spurts.  It can't be quoted because it's highly variable.  In fact, if a programmer is giving you a flat quote you're more than likely paying for 4 or 5 times as much as you would have at an hourly rate because they have buffered for that variance. Complex projects are the ones where good programmers are necessary and the bigger the project, the more cost prohibitive hourly contract rates can become.

Then there was another major issue, growth.  We were surprised to find out that this was a problem which none of the business men and women we'd spoken to had accounted for.  Namely, as a business grows, it hires people.  If an employee performs work and we bill for their time, we're responsible for making sure that employee gets paid for their time promptly.  Somehow, that fact never registers when you're still a smaller operation. As a freelancer, you can personally make the decision to live with bills that aren't paid until 120 days after the work is performed.  As an employer, you can't.

To put that situation in another light, if we have 20 projects going on in parallel that means that we have to carry enough money in our bank account to cover the costs of every person working on every single project within the month, for every month until all of the bills are paid.  The only way that can happen under standard hourly-then-invoice practices is to  have labor that is incredibly inexpensive so that profit margins are huge OR to become a bank.  Neither are easily accomplished with highly qualified people.

The only solution, as it turns out, is to work on retainer.  We did some more research, and the businesses that have been extremely successful in our field nationally have been working on retainer for years.  It's prevalent across the board anytime single, large transactions occur.  When you check into a hospital, they get your insurance information first because your insurance policy IS the retainer.  If you hire an attorney for a case, they generally work on retainer.

Retainer pricing solves a number of issues:

1. Funds are always available to pay employees for their work.

2. Clients can always request that work be suspended to have the retainer returned, so there is no long term commitment.

3. Low rates can still be provided because the profit margin on a person's time doesn't need to create a buffer for future volume.

4. Any number of projects can proceed in parallel rather than in sequence as long as the man power is available.

5. Client relationships avoid the potential strain that collection calls or threats to turn off a website would create.

An additional bonus to retainer pricing is that it fits perfectly within an Agile programming process which breaks projects into smaller, releasable phases.  Retainers can be provided per phase, which allows clients to review and work with their investment prior to moving forward with the next phase.

It sure would be helpful if somebody wrote an article about this stuff....