Last updated · 14 February 2024

Why estimates

Let's clear something out first: we don't work with fixed budgets.

We work with flexible ranges of time, budget, and scope, but even then, those are just estimates. And, as the dictionary quite appropriately defines it, an estimate implies “roughly calculate or judge the value, number, quantity, or extent of,” or even “an approximate calculation…”

Having estimates as a base for any collaboration requires deep trust. We know that. We also know that jumping head-first without having a precise commitment towards budget can be daunting, especially when you don't yet trust us.

However, we have a lot of policies and processes in place to mitigate the “trust” factor, namely Communication, and yet more in-depth the How we collaborate page. In any case, our services agreement (found in Steps to get a project started) allows both parties to pull the plug should we never be able to bridge the trust gap. This never happened, but in case it does, we are all safeguarded.

Now, we will break down why we prefer estimates instead of fixed budgets.

The nature of it.

Even though our commitment with you is to attempt to deliver every project on time and on budget, you know as well as we do that product development and software projects are prone to changes in scope, unexpected occurrences related to strategy, technology, and a lot of iterations that can extend timelines and, as a consequence, budget.

Just like “Bertie Bott's Every Flavour Beans”, they involve unknowns and invisible complexities, only revealing their actual taste when a bite is taken. No matter how thorough a discovery phase may be, the real complexity of a project only gets uncovered once the actual work starts.

An estimate provides a flexible framework that can accommodate these uncertainties, unlike a fixed budget, which might be too rigid to adjust.

Flexibility is key.

We will never put a cap on flexibility, let alone on the wiggle room to pivot and adapt to user feedback and data. It is only normal that scopes change, features evolve, new ones arise, or requirements alter as a product matures.

Requirements are like the Hogwarts staircase: when you least expect it, they move and lead you to unexpected places with uncertain outcomes. Product development is much of the same: a bit of a magical, albeit sometimes confusing, adventure where flexibility and adaptability are key. You never know where you'll end up next.

Estimates allow for this flexibility, whereas fixed budgets can make it challenging to incorporate changes without renegotiating the entire deal. A fixed budget usually matches a fixed scope, which, from our experience, is quite porous.

Uncapped quality.

If you choose to work with us, you expect excellent quality. Our commitment to you is to never put a lid on delivering excellence, nor on the number of iterations, revisions, feedback sessions, or anything else that may put the continuous improvement of a product at risk.

With a fixed budget, a cap is often put on what can be delivered to fit such budget. It typically leads to a “good enough” approach — which we absolutely despise. Estimates, on the other hand, allow us to focus on delivering the best possible value and quality, adjusting when needed, within a reasonable range that is comfortable for both sides.

It's about having a Michelin Star meal rather than just filling up on fast food. Or, to keep it within the Harry Potter analogies, to be Hermione rather than Crabbe or Goyle.

Efficiency and decision-making done right.

As you can read within our Client selection criteria, we hold ourselves accountable when accountability is due.

When the budget isn't a given, and there's an inherent potential to rapidly escalate scopes out of proportion, it will force everyone to work efficiently and to ponder harder on their decisions. This will foster commitment, productivity, pride, transparency, and teamwork. All of these are values we preach at our Mission and values and that are so deeply engraved in our culture.

On the other hand, fixed budgets lead to relaxation from both sides. The client knows their budget is capped, so there's no need to provide feedback on time, be swift when making decisions, or be agile on jumping on calls. On the agency’s side, the same inertia may occur, leading to a progressive deterioration of this collaborative relationship.

Commitment.

Most fixed budgets also have an underlying estimation that is then translated into a price, marked up to compensate for revisions, derailings, and other misfortunes.

When these estimates go wrong, and the project takes longer to complete than expected, the budget is eclipsed, and the agency is left working without compensation. Some clients will say: “It's your problem. You should have estimated things better, then!” The problem is this isn't always the case because, as mentioned above, regardless of how thorough the discovery phase may be, agencies will only get a real sense of a project's complexity once they are knee-deep in it.

When this happens, the agency will be upset, work will be half-done and somewhat rushed because the budget is no longer there. Plus, a lot of corners will be cut because the commitment will be gone, too, and the relationship is doomed.

How many times have you heard stories about agencies that ghosted their clients after utilising all the budget? There are plenty of those out there.

Without ever disregarding our accountability and our commitment, which we take very seriously, estimates overcome this risk.

What you pay is what you get.

This has many different meanings. Let's list them, shall we?

Your budget is fixed on the lower side. You will likely get the lower side of the quality spectrum as well. The agency may have misunderstood or underestimated the project, leading to a budget deficiency, cutting corners, and leaving quality to match lower standards.

Your budget is fixed on the higher side. You are likely to spend more money than necessary based on what was actually delivered. There will never be a way to measure the ratio between expenditure and benefit, and you'll forever be second-guessing your choice.

You embrace the estimate mindset. You pay what you get. If more effort is put into your product, it will take longer to get done, you'll pay more. If things are trimmed or simplified, effort will get shortened, and you'll pay accordingly. But the key here is: what you pay is what you get. No more, no less.

Risk management.

Fixed budgets are like the Wizard's Chess: one wrong decision, and you're gone. Remember how Ron Weasley sacrificed his knight to win the game in "The Sorcerer's Stone"? We don't want to sacrifice anything by putting your product at risk.

With estimates, we can factor in potential risks more effectively, whereas fixed budgets offer less wiggle room for unexpected challenges, potentially leading to corners being cut to stay within budget, which can affect the quality of the final product.

And as you know from reading How we collaborate and our Playbook, quality is non-negotiable with us.

With estimates, if mistakes are made, or if changes in scope, strategy, technology, design, or any other unexpected misfortune happens, it is just part of the process, whereas with fixed budgets, it is a goddamn monstrous bump on the road. After everything that was been written above, the risk behind it is pretty self-explanatory, isn't it?

In summary, we work in estimates due to software projects' fluid and unpredictable nature. Estimates provide the flexibility and adaptability needed to navigate twists and turns, whilst ensuring that the final product is delivered within budget, with no compromise of quality, and within the expected value.