As I mentioned in my last post on co-shoring, most firms these days are using some form of co-shoring and not even realizng it. Now a growing group of startups are starting to built with some form of co-shoring. And each option – has its own set of pros and cons such as :
- Using staffing sites such as ODeck/99Designs/Freelancer
- Pros: Easy to find and access, nice tracking software for insuring trust
- Cons: Transient people, they are not focused or concerned with your startups needs
- Complete offshore development firms based in India, South America, Eastern Europe or Asia
- Pros: A single firm dedicated to your needs, additional resources available if your startup scales or your project needs help, may have common code that can be shared
- Cons: They are focused on their financial success over your companies / they are encouraged to take on more clients / your engineers are managed not by you and can get pulled onto other projects
- Local development shops (i.e. the local NYC DevShop) that internally use remote development partners to lower costs
- Pros: A single firm dedicated to your needs, additional resources available if your startup scales or your project needs help, may have common code that can be shared
- Cons: They are focused on their financial success over your companies / they are encouraged to take on more clients / your engineers are managed not by you and can get pulled onto other projects
- 1:1 Engineering individuals located in offshore or out of city locations working directly with your startup
- Pros: An individual working directly with you
- Cons: Requires more understanding of technical needs/requirements, requires management
Whatever options startups use, we’re finding that many firms should follow these best practices:
- Don’t ever bet your entire initial funding on your first MVP – Development is a difficult process, don’t expect the v1.0 of your product to get you there. Surprise can arise in the engineering process. Microsoft Windows Vista took years over the intended development time, and needed a huge “reset” before they were able to release. Airline Planes take off with more fuel then they need to reach their destination, expect the same with any initial product you plan to build from inception.
- Write a good functional specification – Make sure every last detail is in there. Even if your requirements change, don’t worry your specification can change too. Think of your specification as the living document for your MVP.
- Make sure all IP is yours – Don’t sign any contracts that make you hostage to ownership of your IP – for most startups, their IP is their single most valuable asset
- Find engineering partners that are invested in your success and not your checkbook – Many engineering partners refuse to take equity, but that doesn’t mean you shouldn’t look for engineers that are invested in your success. Look for engineers that are willing to put in the extra mile to see your product reach your goal. Ask questions about how they plan for their code to be improved over the lifetime of the product. Ask questions about how they might be involved with your startup after the MVP. If possible try to match your success with their success, such as offering a long-term relationship with your startup, should you succeed.
- Keep reliable communication – Your remote developer should communicate reliably on a daily basis. We recommend regular SCRUM weekly calls or even daily voice calls with your remote team ensuring they are focused on your tasks. But be careful not to randomize your engineering team with frequent post-MVP tasks and/or BizDev questions. Establish mutually agreeable communication.
- Document all work – We find Wikis to work well, but make sure that you product can continue being built regardless of who is building it. How does the software get deployed? Write a wiki. What technical debt is present in the MVP? Document this. How do you update the database? Place an article on the Wiki.
- Get the source code from day one and all code work should be shown daily – A developer should never hold back on the development work on day one. If they are hiding their code, it’s a strong chance that they are behind schedule, working on other projects, wasting time lost in confusion, or delivering low-quality work.
- Match local engineering partners and domain experts with your offshore team – This probably the crucial point that we argue for in Ab Dev Labs. Find partners who can help review the offshore team’s work and provide you with a in depth understanding of what work is being delivered. If someone is writing code, have another developer local to your startup review it. If someone is designing, have them work with a local designer who may understand your business needs.
- Set goals and milestones – Make sure to set goals and milestones along the way. Your team should be able to hit milestones and keep their project velocity.
- Use project/bug tracking software – Use software such as Pivotal Tracker, Github, Asana, Jira or other common tools to ensure that you are tracking all project work in real-time
Like or follow us to continue and get the latest updates for AB Dev Labs!