It’s not just a good idea, but great products that make winners.
Basically, there is no great product without a great team.
You might invest your time in building a team, but for sure
there are plenty of things you might invest this time in
to make sure your company succeeds.
You’ve probably already checked the rates of the developers and compared that to the rates of the software houses in your area. Hiring a team looks like a good option for your budget. If you consider the per-hour developer rate, it does seem to be the case. But there’s more to it than that.
Recruitment, laptops, health Insurance, office space, paid leave – these are industry standards that you cannot compete without.
Still with us? We’ve barely touched on the topic.
One of the biggest costs you can pay is time.
Time that you need to invest in building knowledge, best practices, team culture or the processes. Here are the things you should consider before you decide to build a development team:
A developer rate for experienced developers won’t be lower than a software house’s.
Less experienced workers need to gain knowledge first. This means that it’s up to your team to invest time in their growth.
Domain knowledge needs to be acquired by new people joining the team.
A new person needs to learn the way the team develops the product, what servers the team uses, how to deploy a new version and what tools the team uses.
Hopefully, they’ll learn all of that quickly. But, they also might not consider these industry standards or important elements to learn, and they might decide to leave your team in favor of another better paid offer.
It requires a lot of time to make sure that what you have to offer is attractive to potential employees, unless you’re already a well-known brand.
All of that might take so much of your attention that you’ll spend more time focusing on that instead of building the product.
If you still consider this a good idea, I have one piece of advice. Find a leader. Someone who has enough experience and technical knowledge. Someone that you can build the team around. It won’t solve all the issues that I mentioned, but it will minimize the risk of the failure.
What other options do you have? I’ll cover that in the next edition.