Over the last 13 years, we’ve partnered with dozens of companies in various industries to create, rebuild, and maintain Rails applications of all shapes and sizes. Through these varying projects, we’ve learned what information is helpful for potential development teams to know before beginning an outsourced Rails partnership.
Before you hire any external developers to build or maintain your Ruby on Rails application, here are six things to share with your potential dev partner about your project and business first. This will set you up for the most successful partnership going forward.
Non-Technical Things to Share
What business goals do you want to accomplish with this project?
An experienced Rails development partner can have a big impact on your business – as long as they understand what you’re trying to accomplish with your application.
When we begin a partnership with a new client, we take the time to understand their business model, how the specific application we might be working on contributes to their business, and what their typical users or customers look like. This information will shape future decisions we make within the application, whether it’s a JavaScript framework choice or a design decision.
Consider the following questions in relation to this app within your business:
- What is your long-term plan for maintaining this application?
- What is your budget for this project?
- What do you want your team to learn from working with an external team?
- How high of a priority is this project within your company – in budget and time?
If a potential partner is able to jump on your project and begin coding without some understanding of your business, you should take that with a grain of salt. It may be a quicker onboarding process in the beginning, but may ultimately lead to more "re-dos" down the line.
What deadlines do you need to hit?
Not every development partner moves at the same speed, so it’s important to select one that understands your internal deadlines and will work toward them. Of course, you’ll need to know about any looming deadlines when interviewing a potential outsourced development team.
Think down the line of your project in relation to your business – What times of the year are you busy? Do you attend any trade shows or conferences where you typically debut new features? Are you seeking outside investment any time soon? Are you planning any announcements in the future that depend upon certain application functionality?
It isn’t always realistic to know deadlines a year in advance within your business, but it’s helpful to share any that you know about in early conversations with potential dev teams.
How many stakeholders are involved in this project? How are they involved?
It should be no surprise that the more stakeholders are involved in a development project, the slower moving the project becomes. While it’s important to make sure the necessary people are in the loop about what’s happening, it also helps to know who needs to actually be involved in certain steps.
There should be a more hands-on contact (or two) on the client-side that will be responsible for approving tickets, responding to inquiries from the agency-side developers or project manager, and generally keeping things moving along day-to-day.
If there are higher level managers that need to know where the project is at from a more zoomed-out perspective, coordinate with your outsourced development team to agree on how this will happen. Can these additional stakeholders sit in on monthly demonstrations? Should they receive weekly or monthly budget updates from the agency’s PM?
The more organized your internal team is when working with your outside developers, the quicker your project will move along. In projects that we’ve seen that move slower than expected, confusion on stakeholder roles and lack of communication within the client’s team has historically been a factor.
Technical Things to Share
If it’s an existing Rails app, what’s your test coverage?
Are you operating on 80% or 8% test coverage on your Rails app? This statistic is important for any potential development partner to know.
For starters, test coverage will be key in estimating work on your application. Any reputable development team will build new testing into your application through continuous integration, which may involve going back and patching existing gaps in test coverage for a more stable app going forward. Taking over an app with less than stellar test coverage could double the time it takes to build new features.
Without substantial test coverage, it’s difficult to know if new features built into your Rails source code may break other existing pieces of code. Adequate test coverage is also a prerequisite for certain pieces of the development process like Ruby and Rails version upgrades.
When your app’s test coverage is already in good shape, any developers you hire to improve your application can build with confidence knowing that the tests have them covered.
This question is related to another one that your potential dev partner will likely ask – who worked on this application previously, and what's your relationship with this developer or team now? As a team that works on many legacy Rails applications, we always ask who has worked on an existing app previously – a freelance developer, internal team member, or another agency. It's also helpful to know your current relationship with that developer and whether the bridge is burned. In the case of an emergency within the app, it may be helpful to reach out to the previous developer for help.
How is your application documented so far?
What types of documentation do you have for your Ruby on Rails project? The extent of what's expected depends upon how long your app has been around.
For an existing Ruby on Rails application, how thorough is your documentation on the application so far? For example, do you have documentation on how to set up the app? In your early conversations with the team who will be working on your application, you'll likely field questions about the current state of the application's documentation. This is important for estimations on new feature builds within the app, as the longer it takes a developer to set up and become familiar with the app, the longer it will take to deliver on new ticket items.
For a new Rails application, how thorough is your project documentation for new features and the plan for the project? When talking to potential clients in the past, we’ve seen everything from a paragraph of copy to a dozen page document and a full JIRA board. There isn’t a right or wrong amount of documentation, but an application with less documentation may require more conversations at the beginning of the partnership to distinguish priorities and first to-dos, while more thorough documentation makes it easier to hit the ground running.
What technical choices have already been made, if any?
If you have any tech-savvy team members who have begun work on this project, what technical decisions have they already made for this application? This may be framework choice, hosting choice, or third-party integrations for the application that have already been purchased.
While it may be early enough in the product development that certain decisions can be changed, it’s important to share these choices with your potential development team. If you’ve chosen a less-popular framework, does your external development team have experience working in that framework? Have they integrated with your third-party tools before? Just because a development team is new to a certain tool doesn't mean that they're incapable of building with it, but it may take longer to get up to speed before you see deliverables.
If you're in the process of considering outsourcing your Rails application development to an external team, the questions above will help you select the right dev partner and begin the relationship on the most positive note.
And of course, if you're looking for a new development team to handle your Rails application, we'd love if you considered the Planet Argon team. Click below to schedule a quick, 25-minute chat to see if we might be a good fit.
