You are ready to start your new project. Maybe you even have already gathered a lot of data and have done extensive research. Your mind is now fully set on starting to build that product. But in the back of your head one pressing question remains.

‘How much will this project cost?’

The harsh truth is that we can’t tell you exactly, because it’s up to you. You just have to tell us what goals you have, name your price and we’ll go for it. We can build your product for (almost) any price.

How To Define Your Project

Now that we’ve got your attention and sort of promised to build you the product of your dreams for a budget you’ve set yourself… Let’s see how we can live up to that. We first need to zoom in on the pillars that define your project: goals and budget.

Goals

Goals say a lot about the minimal amount of time required to make the project a success. Of course, it’s helpful if you come to us with the goals already prepared. In that case we might already give you a ballpark (a range within which an amount or estimate is likely to be correct) of the costs. But in our experience it’s even better to set up or redefine these goals together, so we get to understand your challenges and get a better feeling of what you (and your users) are trying to achieve.

We then convert these goals to user stories. A user story is a short and simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of your product. We write them down like this:

As a (type of user), I want (some goal) so that (some reason).

User stories are often written on sticky notes and arranged on our glass walls in the meeting room. They help to shift focus from writing features to discussing them. In fact, these discussions are more important than whatever text is written.

We keep user stories intentionally abstract so that we can choose the most suitable solution based on the available time (thus budget) we have. User stories can become more detailed if you want something to be solved in a specific way. Sometimes we then have to split the user story into multiple smaller ones or state requirements.

Note we can give you an estimate of the minimal time our team requires if your goals are clearly formulated. Though, we still can’t tell you exactly how much time the project will take, because we can spend hours, days or even weeks on a set of goals.

Budget

That’s where your budget comes in and it’s exactly the reason why it’s important to give us an indication of the amount you’re willing to spend. Basically, your budget defines what can be done with the goals we have in mind. A bigger budget means covering more user stories, a higher quality of deliverables and/or a lengthier process. We can fit the realisation of the project within your budget by making conforming changes to the scope.

Getting a better idea of the intended budget guides us to an estimate tailored to your spending limit. This estimate is based on the following facets; user stories, refinement and approach.

User Stories

Perhaps the most influential for our estimate is the amount of stories we’re going to cover. This also means it’s the easiest way to reduce costs. Removing stories from the scope dramatically reduces the amount of time, thus saves money. It is precisely for this reason that we’re quite critical as to what the MVP (Minimal Viable Product) must include in order to achieve the most important goals.

MVP Product Development

We build MVP’s so that we have a working product throughout the whole product development process. To clarify this we often use the visualisation above. We can help you decide which vehicle you need appropriate to the steps you want to take with your project. Because when your goal is to bring you from A to B, we might build you a bicycle or car. That bike would be cheaper to produce and maintain, but would it offer the same level of comfort and experience as the car? We can even provide you with a rough price estimate if the goals are clear enough (as we know how much a bike or car typically costs).

Refinement

The more time we spend on a user story, the more we can experiment, iterate and optimise. Spending a few hours or spending days, the quality of the outcome will be different. This might sound a little bit vague and probably it’s hard to imagine the differences between these outcomes in advance. So let’s try explaining it using an example.

For instance, take this user story:

As a (website visitor), I want to (reach out to the company) so that (I can ask them questions about their product).

We can complete this user story in various ways. In the simplest variant, we might just display contact information at the bottom of a page. This probably would suffice, but if we spend more time on it, we’re able to create a contact form to provide a little bit more guidance to the user. In the most extensive variant, we’d also add a section that gives answers to the most frequently asked questions, so some users won’t even need to reach out anymore. All these solutions will ultimately let the user reach his goal, but one does it more elegantly and efficiently than the other. The way we execute things should perfectly align with your available budget.

Approach

As a last resort, we could also change the way we work and adjust or shorten our process. For example, when you have a lot of knowledge available within your company, we might be able to cut some research time. How well do you know your users? Is Hotjar data available? Is Google Analytics up and running? Have there been user tests before?

It is also possible to opt for fewer (extensive) feedback rounds or no validation of the design at all by skipping user tests, but this could have nasty consequences. It could easily result in a multiplication of the initial estimate. Imagine what happens when we’ve spent all of our budget building a product no one understands or no one would like to use. Fixing something like that in a very late stage will cost you dearly. We, therefore, only would cut in our approach if we have the feeling you already collected a lot of data and conducted enough research.

Working agile to get the most out of it

So, how do we organise your project as flexible as possible and make sure you’ll be spending your budget on valuable things efficiently? The answer to this is an agile way of working, in which we use a variable scope. Agile is a time-boxed, iterative approach to software development that builds software incrementally from the start of the project. Every sprint we’ll select a few user stories we’ll be working on and at the end of these sprints they will be delivered as features within the product. Because we know the limit of your budget, we know exactly how many sprints we can run. Together we can define the scope and get a pretty good idea of what user stories will get delivered and to what extent.

We hear you raising a question, as we’ve heard it many times before. “How do I know what I will get at the end of the process?” Well, you don’t. Not exactly. It’s called agile for a reason. We can give you a pretty good indication of what you’ll get (especially once the project has started), but we all should get used to a mindset of being open to change. When we learn things while we build the product (and we will), an agile process will make it possible to change course and allows us to make changes to the scope. This workflow requires our teams to talk to each other a lot about these kinds of things. So yes, we might end somewhere else than expected, but it would probably be for the best.

This is in stark contrast with the more traditional ‘waterfall’ approach where the scope is already set, but the time and costs are not. Estimating projects using this approach, often leads to bigger numbers on the quote. This is because we have to set everything in stone. We assume that every single feature will take us plenty of time. For all features we’ll estimate we’ll be needing a couple of iterations. Basically we overestimate a lot, because there’s no margin for error.

It’s all about the money

So, there’s no real answer when it comes to pricing your project, other than setting it yourself. Think of the budget as furnishing your house, we can do this for a minimal budget and that’s fine. You’ll be able to live in a fashionable home, but if you prefer more comfort and designed solutions we’d need more time thus more budget. Open up the money tap and we could build you an entire new wing or even build you a new villa.

Be smart about how you want to spend your budget. Reducing the scope will result in a smaller investment in the short term, but might affect your return-of-investment value over a longer period.

To conclude everything said: with an agile way of working, you’re always in control of both budget and scope.