When you approach us with an idea for a solution that you want to build, the first step in the process is often a feasibility study. During this study, we work together with you to get a comprehensive understanding of the project’s scope, requirements and costs before the actual work begins. Put simply, this is where we establish the framework for what needs to be done. As a result, it’s only after the feasibility study is completed that we can provide a realistic estimate of the expected cost of the project.
It’s important to note that before starting the feasibility study, we can provide some kind of a cost estimation, but it’s often quite a rough one. This estimate is typically a “starting from” cost, something you can see examples of in the article How much does it cost to develop software? These types of rough estimations often exclude many features that the customer needs and wants, and therefore represent a kind of baseline cost. It’s important to be aware that the investment in the software solution often ends up being higher.
When the feasibility study is completed and we know more about the project, we revise the estimate made at the very start to reflect the more defined scope.
The initial stages of the software development process can be compared to building a house. Have you ever heard of someone approaching a carpenter saying:
“I want to build a house, what will it cost?”
And getting the answer:
“Absolutely, 2.5 million SEK. Let’s get started right away.”
No? Didn’t think so. To even think about building a house, the carpenter must see a blueprint created by an architect. Moreover, you’ll need to answer a bunch of questions – not just from the carpenter, but from other experts as well. They need to know the size of the house, the choice of materials, what the plot of land looks like, the type of heating system you want, and much, much more. There are many things that you need to decide before the first shovel hits the ground – and before you can get a sense of what the total cost might be. And, by the way, have you ever heard of a construction project sticking to the original budget? No? Didn’t think so.
Of course, there are exceptions. But often, construction projects exceed both budget and timeline. And we won’t lie – relatively often, this is also the case in software development. To do our best to avoid this, we conduct a feasibility study, which includes the process of creating a quote.
A feasibility study is our first step when we start working on a new project and is essential for us to understand the scope. It’s conducted through interviews, workshops and by digging into the customer’s systems and codebases.
We see the feasibility study as a limited investment for our customers, where we minimize the risks in a project. We identify potential risks, product and project requirements, and investigate technical feasibility. This results in a foundation for decision-makers at the customer’s end, creating better conditions for making important decisions moving forward. After this, we have a clearer image of the investment required from you as a customer.
Throughout the feasibility study stage, we mainly focus on three questions:
This might sound like it has to do with our technical competence, but no – we can promise you we’ve already got that covered! When referring to technical feasibility, we mean whether it’s possible to develop the solution given the customer’s current setup. For example, we’ve been in situations where a customer wants data from a system that lacks an API, making data transfer impossible. In this case, the first step was to create an API instead of starting the intended project – something which directly affected the budget.
Much of the software we build is not only for our customers but also for their customers. Sometimes, it might only be for them. But since it’s our customer and not the end user who drives the project, it’s easy to miss valuable insights. Therefore, we try to see the final value the solution will provide from the end user’s perspective. This is often referred to as perceived usefulness and is a well-known concept in technology acceptance models.
In addition to perceived usefulness, we also look at perceived ease of use, something that affects the final value because it relates to how user-friendly the solution is perceived to be. A solution that users need, but find difficult to use, reduces motivation to use it, in the same way as a user-friendly solution with no clear value does.
To ensure we achieve both perceived usefulness and perceived ease of use, we discuss the solution’s content and project structure with both our customers as well as their users to develop the final design proposals.
Here, we look into whether the solution you want in your business fits with your business model. This can involve everything from revenue streams and customer segments to key resources and activities. With our trained eyes, we can also easily identify several opportunities you might not see yourself, for example data that can be used in various places where it previously hasn’t been used.
Thanks to the three questions above, we will know most of what we need to plan the upcoming project, including resources, risk management and requirements.
Other important questions to address in a feasibility study might include:
We will then break down the solution into smaller deliverables, each with its own estimate. Finally, we compile a requirements document that we review with you – all to ensure that we don’t overlook any important areas or details.
Developing software is an extensive project that requires a lot of preparatory work before the actual development work can begin. The information we gather and analyse during the feasibility study is needed to sketch out a solution and also determine whether the conditions for building the solution exist – or if this is something that we need to address with the customer first.
The quotation process is a natural outcome of the feasibility study as it allows us to better understand the project’s requirements and challenges. By mapping out the complexity of the project during the feasibility work, we can create a quote that attempts to reflect the real costs and commitments of the project. However, it’s important to remember that a lot can happen along the way in software development. Read more about why it is difficult to estimate the cost of software.
Block QuoteBack
