Formulating an Early Startup Team

Author Bill Webster
Posted July 7, 2016

Deciding to start a new venture is an exciting time! Whether you’re formulating a new startup, designing a new product or providing a great new service, developing your team will make all the difference.


Working in a vacuum sucks

I learned this the hard way. Before I founded Zenvoy, I was working on a few other projects related to the technology industry.  I spent nearly a year of my life developing and testing a new method to solve a very old problem. I think as a designer it became easy to believe I had all the answers to a very complex process.  My overconfidence and lack of collaboration slowly undermined my ability to solve the increasing number of problems that needed addressing each day.  Perhaps even more disappointing, I had no one to share with or depend on during this process besides myself.  While a minority of founders can push the boulder up the hill on their own, I now know the odds of success grow exponentially when you work as part of a team.


Working in a Vacuum


How do you assemble an early cost effective team?

Recognize what skills you DON’T bring to the table and work backwards.  Yes, early in the life of any startup you will wear many hats, but recognize that multitasking usually leads to crappy quality and a dysfunctional social life.  Going it alone is not a long term solution.

If you’re a non-technical founder then mockups, prototypes and presentations will likely be your voice; find ways to pitch your ideas!  Don’t start at the VC level, instead look for hourly developers. These guys/gals can be a great way to flush out an early MVP.  Many great websites such as, and are fantastic resources for building out an early low-cost technical or design team. Again, use your mockups and presentation skills to clearly articulate your goals.  While many of these contractors are highly skilled, they usually will not fully understand the nuances of your product’s value proposition.  A few helpful hints when going this route:


  • Culture- Determine the amount of culture overlaps between your product and your developer. Many business models, products, and services just DON’T transcend cultures.  You probably don’t want someone building your MVP if they just don’t “get” why it should exist.


  • Location- This developer will most likely not be located down the street. Find someone in a time-zone where normal working hours overlap for at least an hour or two each day.


  • Previous Work- You will want to do some detective work. Find out what types of products the developer has completed in the past and what their specific role was. I’d even recommend calling the company that hired them. There is nothing more valuable than first-hand experience. This can save you tons of headaches in the future. Vet, vet, vet!


  • Communication- This is a biggy! If you find that a team member always prefers to instant message rather than chat voice-to-voice, you may have a problem. The success or failure of your venture will hinge in the team’s ability to clearly communicate and deliberate.  If one of your team members resists participation in the process, I guarantee it will end up costing you money in unnecessary follow-ups.


  • Cost- Yep, in general it will be nearly 3.8X as expensive to hire a developer within the U.S and Europe. While this added cost is usually well worth it, it should not detract you from exploring less expensive options. Remember the key issues above and you should be fine.


  • Short Term Employment Periods- This is a double-edge sword. Usually, if a developer needs a short term work contract you can assume they aren’t going to “go the distance” with you.  But, short term contracts do allow you to fill vital roles as they rear their head. The flexibility to grow or shrink your team rapidly can be a versatile tool.


  • Hire Slowly & Fire Quickly- This sounds a bit mean, but it is so VITALLY important to remove members of your team if they begin to show signs of sub-par work or disinterests. While you will inevitable become somewhat attached to your colleagues, it must be Company first.  Early in our development phase we held on to a few devs far too long. The results were months of delays and ultimately the need to circle back and redo large amounts of code.


By in large the tips listed above should keep you pointed in the right direction and out of trouble. In closing, I would say our experience developing a team from scratch has been fantastic, but not without its minor glitches.  Eventually your team will begin to fire on all cylinders making smart, proactive decisions that not only better the company, but enrich your own learning experience as a founder.

Let me hear your experiences with building early startup teams in the comments below! And remember to check us out Zenvoy for your networking needs!

Featured Customers

With organizations like yours using Zenvoy, we have made over millions of valuable introductions & counting!