Myth of the Flat Fee

You made a deal with someone to build you a website. Best of all: you agreed on a flat fee! That's great, because you know you have a fixed budget. And you're getting everything you want, because that's what your vendor promised you. Guess what? It's not going to happen: your project will be more expensive than anticipated and/or will have less features. You fell for the Myth of the Flat Fee.

The Myth of the Flat Fee has most likely been around for centuries. You're definitely not the first one to fall prey to it. But why do clients keep falling for the Myth? Because you're looking for a sense of security when you're spending your budget on a web app. Vendors play along by providing this, albeit false, sense of security.

Any job we do at 80beans usually starts with a prospective client calling or mailing us with a request for proposal. Sometimes their information is detailed and well thought out, which gives us enough to work with to give a preliminary estimate. More often though it consists of one sheet of paper with a brief that comes down to "we would like a web app where visitors can keep track of X, with social media integration". We're then invited to ask questions, mostly being answered with something along the lines of "we don't really know yet" or "that's to be determined". That's fine. We love to work with you to find out what you want to achieve with your web app and how we can help you reach that goal.

But at this point you just want to know what it's going to cost you and if we can meet your deadline. After all, you have a certain budget you have to work with. And besides, the other development companies on the shortlist did offer you a proposal with a flat fee. If we want our proposal to be taken seriously, we should definitely name a price.

We then try to explain that we can't give an estimate, let alone a price, based on the supplied information. We'll invite you to first work with us so we know exactly what you want to achieve. Talk to us, join us in making wireframes/click demo's and writing user stories. You'll be surprised at the advancing insight you will develop while going through this process. There will be things you didn't think about, while some other essential features seem to be redundant. We can use the outcome of this process to base an estimate on, and it can be used by you to obtain more accurate proposals from others.

Every project consists of three attributes, also known as the "project triangle" or "triple constraint". There's scope: the features your app has. There's time: how long will it take to build your app. Finally there's cost. Changing one of those attributes will always have an effect on at least one other attribute. You might ask yourself: how can you determine the cost (and make sure it doesn't change) if the other attributes aren't entirely clear yet? You just nailed the core of the Myth.

So how can it be that those other companies can name a price after receiving your RFP? They can't. They're just guessing, based on the same limited amount of information we have to work with. Depending on how the scope of the project develops they will leverage other aspects. They will do so by engaging in Conflict Driven Development (CDD, a term coined by Thijs Cadier), either on purpose or because they genuinely assume they exactly know what you want.

During the initial phase of the project — when it becomes clear what you really want — they will say that's not how they interpreted the scope for some feature. Now you're faced with a few options. You can alter the scope so the cost remains exactly the same: the feature will be dropped, it will not be developed the way you wanted or you need to slim down the scope later on. Or you can decide to pay more to get what you wanted in the first place. There the flat fee goes out of the window. A few weeks later the same situation occurs. First there's a conflict, then there's choosing between building something you don't really want, or paying more.

In either case you won't be happy. All those conflicts drain energy, require a lot of project management and lead to a disappointing and/or unexpectedly expensive project. You have a very weak position in negotiations, since you already invested time and money in the project when the conflicts start occurring (or worse: a hard deadline is approaching). It's an investment you don't want to see go down the drain.

At 80beans we take a different approach. We understand that your budget is important to you and that you don't like surprises. Just tell us what your budget is and we will have a chat about what we can do within limits. Let's write user stories and prioritize them, so we know we start with the most important ones ("must have"). We're comfortable with guaranteeing that we can develop the stories you defined as "must have" within a certain budget. The other, less important stories will be developed last. That way you get all the essentials and a large part (or possibly all) of the rest of the stories. During the development process you can keep prioritizing the stories, making sure we build you a great app within budget. If too many stories become essential we might need to go over budget, but at least you know and can make an informed decision instead of being faced with a conflict.

Sometimes clients end up working with us after initially choosing another company. We then iterate on the work that has already been done. When we find out the price a client paid in the end, we're often confident we could have done at least the same job for the same amount of money. Without all the conflict and at a higher level of quality. The problem we often encounter is that prospective clients find out the hard way. We'd love to hear any suggestions on how we can improve our communication in making prospective clients understand early on.

Bottom line: we're not more expensive than others, just because we won't give you an estimate until we're confident that we understand your needs. We just choose to avoid conflict and build you a kick-ass web app.