Choosing the technology for your startup is not the easiest task. If you’ve chosen Ruby on Rails, then we want to congratulate you. You’ve made the right choice!
But before you start your project, we want to help you avoid some mistakes we made by ourselves. In this article, you will find useful life hacks on how to avoid these mistakes.
Mistake #1: Expecting immediate results with a new team supporting code from a previous company
It is common that a new developer will be unhappy with old code. This can happen even with ideal code and an ideal new programmer.
Even if the code is written using the best Rails practices, the new team needs time to get used to the new code. So be prepared for a slow start and be patient. At the same time, you should ask for daily reports to be assured that someone is really working on your tasks.
Mistake #2: Ignoring QA (Quality Assurance) testing
Typically QA work costs from two to five time cheaper than developer time. In the same amount of time, testing engineers can do QA work dramatically faster and better. Programmers are sometimes afraid to fully test their functionality. Also, it is not what they prefer to do or to do as professionally as QA testers. But at the end of a day, you need a HQ bug-free application to deliver satisfaction to your own clients. Which means you cannot afford to ignore the QA process.
Mistake #3: Not interviewing and getting the profile of a specific developer
You are not going to work with an entire company. The information provided in the company profile does not always tell the entire story. People who did past projects may have left the company, while new developers may have some additional special experience. You will likely work with a specific developer and probably a Project Manager, so be sure to meet them all and ask questions.
Mistake #4: Not asking for a trial period
After working together for two weeks you will understand whether or not the Ruby team is what you were looking for. If you end up having to cancel a project now or later, you will not have anything useful in either case. So it is best to arrange for a trial period with your new development company.
Mistake #5: Not sharing your business goals with the developer
It is no secret you are requesting Rails development to make money for yourself or your company. Developers, as any other people, like to understand why and what purpose they are doing their work. With a clear understanding of your business goals a good service company can not only choose the right priorities but can provide an additional valued experience that you may not expect.
Mistake #6: Working without contracts or, at the very least, a written agreement
When you start the work, it may seem clear to both parties what each one expects. In reality, however, many unexpected turns of events could occur in the course of your collaboration. We recommend you agree on the following things:
- how much time per day or week a given developer will work on the project
- if the developer on the project has to leave, how he or she will be replaced and who will cover the cost of orienting them on the project
- who will cover the cost of fixing bugs
- after the collaboration is finished, how new bugs will be handled
- if the developer will have a short-term or long-term vacation – how promptly will you will be notified
Mistake #7: Expecting that the developer will do everything on their own without clear feedback
In ideal circumstances, you will pay and get exactly what you want without having to expend any extra energy. With a non-professional team, you will need to expend an enormous amount of time and energy on micromanagement to get the necessary results. This is something you will want to avoid under any circumstances. At the same time, even working with a highly skilled and professional team, you should schedule at least a weekly (better, daily) review of the work performed and a prioritization of future tasks.
I hope the advice above will help you to have a better experience with your current and future Ruby on Rails development company.
