How we quote technology

When I was a younger developer, working freelance, I found out very quickly that my clients were not comfortable with simply paying me hourly until the project was done — almost everyone would ask for a fixed fee, so that they could budget around the project. Of course, this makes the most sense for the client; how could you sign off on a project who’s cost could vary by thousands, even if it only exceeds a timeline estimate by a week?

I started “eyeballing” a project as a number of hours, and trying to stick to it. This wasn’t scientific: often I’d be agreeing without signing a full SOW or seeing designs, meaning that if a client wanted to add features to the scope mid-project, I’d often have to agree just simply to keep the relationship in good standing — and eat the cost of the extra additions.

After a year or so of guesstimating, there was only one thing clear — I could not estimate development hours directly with any level of realism & precision.

In order to get work, I had two choices: I’d either have to eat the cost of an underquoted project, or try and maximize a client’s budget for the sake of padding. Neither approach sat right with me, both ethically, and business-wise: quoting without consistency makes it impossible to project profit (and hire appropriately).

One thing I noticed in my time working in the agency world was that whenever we tried to estimate hours as a team, we were almost always hugely wrong (luckily these were internal timeline estimates).

However, when we broke our workload into agile story points, and compared it against our team’s burndown rate, we were radically more accurate in shipping projects on time.

We found that by simply estimating abstract story points (and translating them back to time after the fact) made our estimates honest & realistic!

Dividing the total story points by our burndown rate allowed us to arrive at a timeline, and multiplying that timeline by our weekly rate meant we arrived at a cost & timeline that felt grounded in logic.

Over time, and with further analysis, we learnt a few lessons to help protect the budget & ensure the project launched with the appropriate level of polish:

Every proposal we prepare includes a link to our story point Google Sheet. Often we find it’s a little too complicated for the client to absorb on first blush, but when an opportunity to negotiate arrives, we’re able to work with the client to make the project cheaper by trimming unnecessary features.

Another nuance we noticed early on was that when a client signs off on a project, they can often take certain additions for granted. For example — adding a mailchimp signin, or a terms & conditions page. Left unchecked, it can mean death by one thousand papercuts — unaccounted hours always translate to lost profit.

The effect of laying out every fine-grained effort out in the open means that those lil’ features that are often swept under the rug until last minute are forced out into the open. This has the added effect of providing more scope clarity & setting client expectations.

Unit economics continues to be my favorite phrase in the consulting business model. In its simplest form, it means that given all of your expenses, a developer who works for a single hour should make a certain amount of profit during that hour.

In the case of composable costing, we know that a developer who completes a single story point will create profit after payroll, rent, and other necessary expenses.

Building strong unit economics starts on the micro scale — but when you’re confident in that “atomic unit”, you can build it up to comprise a large scale project, and provided you were diligent, you’ll have confidence that it’s at least as profitable as your single unit.

Knowing how our unit economics play out makes projecting profit & taking on big expenses (like hiring) much easier to plan around!

As we’ve completed more and more projects, you’ll be able to “hone in” on your burndown rate, and understand places you can optimize for a better shared success for our client and ourselves.

You’ll also learn where the parts of your estimates fall short, and be able to tweak & adjust your math over time.

There’s one big risk we take on when working to composable costing: in actuality, we must hit our burndown rate, or better.

Sanctuary Computer lives & dies by our burndown rate. In the case we can’t achieve our rate on average, over the course of the project, it slides off of our initial timeline. As soon as our project starts sliding to the right, we start eating profit. This can be risky business — by using a burndown rate, you’re essentially gambling on your teams’ ability to carefully make the “right” micro decisions, and ultimately get the work done with precision & efficiency.

However — the counterpoint to that risk is sweet — if our burndown rate is higher than the one we quoted with, we made extra profit — additional to the expected profit shown in our unit economics.

If you’d like to start using Composable Costing, simply copy this document into your own Google Drive, and scope out your project!

Wanna talk more?

Please reach out at hugh@sanctuary.computer / isabel@sanctuary.computer — we’re friendly and open and would love to chat in greater detail on some of the specifics here.

Ultimately, we believe that large, full service agencies are becoming less appealing to clients out there, and instead, we’re hoping to encourage a world where nimble, specialist companies work together to carefully create intimate & unique work for clients, at realistic prices.

Related posts:

When you hear the word “torrent”, it usually refers to a file (computer file) that contains some information. A torrent file usually comes with the extension .torrent. That file does not contain the…