What to Know About Your Project when Hiring a Development Studio
What to Know About Your Project when Hiring a Development Studio
So, you’ve decided to hire an external team of software engineers to deliver your project. In this article, I’ll tell you what you should know and prepare before starting the cooperation with a development studio to ensure the success of your business idea.
(If you’re still not sure whether hiring software developers externally is the right choice for your business, or you don’t know what does the cooperation entail, check out my previous article.)
Who are your users?
Once you have a business idea, you should research the market you’re trying to enter; what are the existing solutions your potential target group uses, what are the accessible statistics about the users, and is there anyone in the market that would be willing to share their knowledge with you? Our design studio Utilo is diving more into a subject of user research in this article.
A quite common mistake startups make, is that they focus on their idea and completely forget about the users. After all, specific people require specific features of your solution—a parenting app will be used slightly differently by dads and moms.
Unique Value Proposition
You have a business concept, and you know your target group. Now you have to think what’s the main value you’re bringing to the users and what are the key functions of your solution that will allow you to give it to them. Usually, it’s helpful to narrow your concept down to smaller pieces. There are existing frameworks that can help you define and utilize your Unique Value Proposition: business model canvas, value proposition canvas, and so on.
Overall, while discovering your UVP, try to answer the question, “Why would this user be interested in my solution?”. Thanks to a clearly defined product value you can trim your solution down to what’s really important in the first stage of production, aka the MVP (more on that later).
Functional and non-functional requirements
Once you have a clearly defined concept of your business, its value proposition, and know your target group, you can start working on your project requirements. Generally, we identify so-called functional and non-functional requirements.
Functional requirements apply to the functions of the solution—what kind of action can a user perform with the solution, for eg. an app, like logging in, checking a purchase, changing settings etc.
Non-functional requirements define how these features work—e.g. security, liability, scalability, performance, a type of device or system the software should work on.
There are many different ways of presenting these requirements: an old-school list, functional mock-ups, requirements specification (SRS) document etc.
Once you have all the requirements for the project established, a development studio can estimate the possible workflow and the skill-set needed to deliver software that fulfills your business’s purpose.
To quote or not to quote
If you’re in conversations with more than one agency, trying to settle on the best one, you’re going to end up comparing different estimations. This might get challenging since it’s likely that each vendor is going to price the scope of work differently.
So, why is one vendor pricing it for 20 thousand and the other for 200 thousand dollars? First of all, their hourly rate can differ a lot—you’ll most likely encounter varying rates in Eastern Europe, Western Europe, or the US, and you might think there’s no obvious reason for that. What usually makes up the rates is a complex blend of experience, portfolio, seniority of staff, salaries, the general cost of business, and many other factors. In my experience, however, it’s not only the hourly rate making up the final quote, it’s also how the studio approached the estimations.
One way of doing an estimation is to define how much time each function is going to take to get done, which then gets represented in a price. I know this kind of estimation might get misleading at times since it’s hard to verify the general quality and honesty of it. Clients often want to know the final budget, which is understandable. However, with bigger projects, preparing a precise estimate that will be reflected in the actual work is nearly impossible, especially when it comes to software development.
The other way—which I prefer—is not to focus on the final destination but rather on the process. Your project can be divided into smaller chunks—usually, only a small number of functions is necessary for the MVP, and the rest can be left for later.
Thinking of what exactly can and should be delivered in, for example, 3 months, is a much safer choice for your project and your cooperation with the tech partner. Worst-case scenario, the product’s release will be delayed by a month, not a year. This enables iterative progress that also lies at the foundation of the Scrum methodology. Instead of getting a “closed code blackbox” at the end of the project, when it’s either practically impossible or, at least, very time-consuming and expensive to change anything, developers can respond to the changing environment of the market and your project in real-time. Thanks to this setup, your development studio will HAVE to do well so that you want to keep working with them after each stage of the project.
How much is it going to cost me?
In our world, the most common answer to this question is “it depends”. And, well, it truly does.
The factors can be, for instance, internal—depending on your team’s expertise and the state of your business overall. How much do you know about your market and project? How big is your scope of work? Do you know what are the product’s functional and non-functional requirements already? How many experts from the development studio you need to hire? What’s your timeline?
When it comes to external factors, apart from the state of your market, it also matters what kind of tech partner you’re working with. What level of expertise does a development studio have? Where are they based? How many experts can they spare for your project? Does the project require a niche set of skills?
All this will somewhat influence the price.
Defining your MVP
MVP (Minimum Viable Product) is a product that delivers a base value you want to give your end-user. By definition, it should be tightly targeted at people who are natural recipients of your solution. MVP saves you from the risk of overspending on something that might not be received well in the market. If you fail fast, you can iterate fast—and that’s the possibility MVP gives you. It allows you to understand your risks better, listen to the feedback of your user base and create a solution that responds to their actual needs. You should think about what is the smallest piece of software that is capable of delivering the core value to the target group. Only once your MVP concept is done, you get a clearer view on what to do next with your project—what functions to extend and how to carry on cooperation with the development studio.
There are some risks, of course. MVP is not always a good option, especially in the highly competitive markets. Creating an MVP for a busy market might not attract many users, which is why it’s so important to research it thoroughly and check if there’s a place for your product. If the space is limited, you can always think about how you can deliver a certain business value better than your competition or what’s a unique factor you can offer the users besides what they already have.
Research the market, find the unique value of your business, decide on what’s important for your project right now. Start slow, see how it works, test it with the users, iterate, check again, and keep moving forward. This kind of process saves you from losing money and ensures smooth cooperation with your tech partner, allowing you to build a professional relationship as you go. An experienced development studio will walk you through all the milestones and apply its best practices, so you don’t have to face these challenges on your own.
Of course, none of these tips may work, if you need to deliver a product fast before your competitor does, you’ve got tons of cash, and you are open for an aggressive spend (keeping in mind that this involves a high risk). After all, starting slow and safe is not always the way. As I said before: it all depends :)
If you have a project idea in mind or don’t know how to hire an external team of software engineers—get in touch. I’ll be happy to answer all your questions.
Business Development Lead