What to Consider When Hiring an Offshore Rails Dev Team
Reading time: ~ 4 minutes
There’s a broad range of partnership options for companies seeking help from an outsourced Rails development team. One option that has grown in popularity over the last few years is the offshore development team.
Being in the Rails industry for 13 years, we’ve recently seen an uptick in Ruby on Rails teams in certain pockets of the world, particularly Eastern Europe, India, and South America.
These developers are sometimes contracted by US-based agencies to charge a lower rate than their competition. I’ve come across dev companies with a California office address when, in reality, only their sales or business development teams are stationed there. The developers working with clients are all based in a lower cost part of the world.
(Tip: You can always take a peek at the company’s employees on LinkedIn for insight!)
It’s a crowded market of Rails agencies out there, and, for many companies, price is the primary deciding factor in picking a team. Offshore developers in certain regions require lower wages than American developers as a result of lower cost of living.
Are offshore developers any less talented than US-based teams? Of course not. Programming doesn’t discriminate based on language or location. You can find talented developers in any obscure corner of the world making their own little mark on the internet.
But partnering with an offshore development team for an important project comes with some considerations. It’s unrealistic to expect cheap, high-quality dev work on a short timeline. We’ve heard anecdotes of outsourcing horror stories from clients, and there has also been research done on the hidden costs of offshore development that reveal the other side of the story.
Below are some considerations to make, and questions to ask your team, before partnering with an offshore development provider.
Response time rate
Do you expect or need a less than one day response time rate? This can prove to be difficult when your development team’s working schedule is 8-12 hours ahead of yours.
We’ve even spoken with companies on the East Coast who didn’t want to work with us, a dev team on the West Coast, due to time zone differences and the pressure of needing certain items ASAP. And we get that!
When you aren’t on a matched schedule with your developers, items are bound to take longer. You may want to have conversations at 4 pm on a Friday or first thing Monday morning for quick-turnaround items. There may be situations where a time zone difference is a pro – you can send changes at the end of your day and have feedback ready when you arrive the next day. It’s all about your priorities and working habits.
You also have to be conscientious of when you communicate. With a team in Europe, you may be able to slightly adjust your schedule to have direct communication first thing in the morning. But if you’re constantly missing each other when attempting to communicate directly, it can become problematic.
Project management assistance
Many agencies (ours included) have project managers on staff to facilitate efficient development on projects. While you’re able to communicate directly to developers, you also have a project or account manager available to keep track of the overall health of the project plan and relationship.
When working with an offshore development team, you’re likely to communicate directly with developers without that additional assistance. If you aren’t able to independently keep a high-level view of your application, this can be problematic.
Language barriers and cultural differences
It’s no secret that every culture communicates differently. A quick Google search for research done on cultural differences in outsourcing generates a lot of results. There have been dozens of studies done about the impact of culture between teams.
Respect and disagreement are presented very differently in different parts of the world. If you’re going to partner with people of a different culture, you have to understand that they may communicate differently than you, and vice versa.
Questions to ask to help you decide
How is your documentation?
One key to a successful relationship with an outsourced dev team is thorough documentation. If these developers are inheriting an existing project, documentation will be key to their success. This is especially key with offshore developers who are less likely to have that face to face (or video call) communication with a client.
Are you willing to spend more time managing?
This depends on your feelings on the “time is money” argument. But then again...money is money too. If you’re short on money but not on time, an outsourced development team can be a good option for your project. You’ll likely need to spend more time managing the project, reviewing work, and arranging demos.
Are your project requirements clear?
When you’re routinely having calls with your development team, it’s easier to work through project requirements as they come up. That face time makes it easier to translate to-dos into what you really want to see done.
Do you have a plan to verify the quality of development work?
When you’re paying for low-cost development work, it’s helpful to have some system in place for verifying the quality of the work you receive. If you have a developer in-house who can check work, that’s one way of doing it. Another option is to pay for a third-party code audit to check in at some point in the development process and ensure the app you receive is stable and secure.
Are you looking for a long-term partner, or do you just need an MVP?
An offshore development team can be a cost-effective option for a company looking to build a lean minimum viable product. A bootstrapped, lean MVP won’t need to necessarily scale with your company for years, it may just be needed in the short term to verify product-market fit.
If you are seeking a long-term partner to work on your project, an offshore partnership may not be sustainable for your team over time due to the time requirements of the partnership.
Have you partnered with an offshore development team on a project? What lessons did you learn from this relationship, and what advice would you give a company weighing this decision?
Tags: