Could you share any evidence that would demonstrate the productivity, quality of work, or the impact of the engagement?
We saw usage go up. People converted more. With the older UI, we couldn’t implement certain features because the UI was restrictive and didn’t allow for it. When we built this new UI, it had much more space, not in terms of literal space, but it had more pluggable bits that could be built on. Not only did it allow us to build new features, which then means that people converted more, but it also made our team’s and my life easier. When we wanted to add a new feature, it was much easier to include that into the UI, whereas before we were asking ourselves where are we going to put this.
Having said that, I think that is more as the result of the design, not so much of the implementation. The implemented code was maintainable and understandable. It made out developers lives easier, so there was less friction when touching the code. That also made us more productive. But I wouldn’t say that their implementation resulted in any user-facing improvement because I think it was more the design that did that.
There were some issues with the implementation, which was that sometimes it was a bit too literal. For example, the design didn’t have all the responsive views in the design. It was more a desktop view with no mobile view. For the first few rounds of code implementation, when you went down to smaller viewports for the browser window, it didn’t quite work. There was intervening I had to make, saying let’s use common sense in what kind of known practices in terms of how pages collapse into mobile view. There was a bit of friction there and took a few extra rounds, but they were pretty good about not charging that.
Those iterations delayed the project a little bit more than we would have wanted. Luckily, we were not too rigid about the deadline on the milestone date. We were only off by an extra week, which wasn’t a big deal for us. However, there were no issues once we went live because everything had been addressed beforehand by me because I reviewed the code.
How did RubyGarage perform from a project management standpoint?
Their communication was great. That was one of the things that I liked working with them in general. The designer and developer were always available, so I could always ask questions. The senior member and the general account manager were also super responsive. They were always quite consistent with whoever was on the project, meaning no turnover in resources. Their developers are high quality, meaning they followed best practices in terms of the code that they wrote. We did code reviews, and they were very good with code reviews with either engaging in the reviews or fixing things that I would say were not quite right. They were really engaging with that. Also, they were quite humble, which is hard to find in development. There was no ego involved. We exclusively used Slack for communication. Everyone was in the Slack channel so we could ping anyone.
What did you find most impressive about RubyGarage?
I found them to be very flexible. If things needed changing, or if I got something wrong, or if I needed a special circumstance or a way of working, they were particularly flexible which I liked. Even with billing, they were really flexible there. They would charge in dollars, but whenever I could not transfer dollars because I wanted to use an app to transfer money, they were pretty good in charging me in euros. Their developers are clearly talented. Maybe that’s not unique, but I found that to be a fact.
Are there any areas RubyGarage could improve?
In all of my experience with them, I had the best experience with the backend developers, but the most friction with their frontend team, even though their work was very good. That is more because of the literal way they might approach a project or an implementation of a design. That is my only thing really. I had issues with some of the junior developers, but I think that’s a normal junior developer thing. I do not think that is unique to them. But I do not think there is any general thing that I can really think of off the top of my head that they can improve.
What tips or recommendations could you share that might increase the likelihood of success with RubyGarage?
First of all, get a sense of the way that they communicate. It is quite general, but you should really do that before and see what kind of communication you are going to have with them ongoing. Then jump in and see if you can do any short-term work (one or two weeks) with them. I think that really is the best way to find out if you are going to work together, and I think that is what kept me with them, even if I had to educate a developer, junior or not. Just generally working with them was good, but I could only find that out by doing it.