Interview with the owner of MunchAway: an online food ordering application build with Ruby On Rails.
Interview with the owner of MunchAway: an online food ordering application build with Ruby On Rails.
I was working at the end of last year and the beginning of this year part time on a cool Ruby on Rails project. I recently contacted the owner of the project and asked him if I could interview him to share his thoughts on different aspects on the project in an interview to be posted on my blog. He shared openly his views on Ruby on Rails, on using a mix of consultants and employes, and on the project in general. I think you find will his answers informative.
Rob, the owner of lt2sys.com had a vision to make an online food ordering platform that can easily add online food ordering to Restaurants that already use an existing point of sale (basically the touch screens when you order your food at the restaurant). So Rob put together a team of consultants, employees and offshore Rails developers and created the application which has a front-end online ordering, a back-end system to configure new stores, and communication system that interacts with the point of sales. The development of the initial phase took several month and the system is now live serving many restaurants.
Interview with the Rob, the owner of lt2sys
Question: What made you choose Ruby on Rails to develop your solution?
Rob: I made a strategic decision to use what I perceived to be the best available web development technology available. This was difficult for me because by using Ruby on Rails, I was choosing a technology that I had no personal experience in using. I read many blogs and product reviews, and discussed this with my internal staff.
Question: Did you consider other technologies like .Net, Java, Php, Phyton?
Rob: Beside Ruby, the only other product that I considered besides Rails was .Net. We have a lot of .NET expertise inhouse, and I had some Java JSP experience. We had one developer in house with Ruby on Rails expertise.. I didn’t really consider Java because I wanted to use something that my internal team would be willing to use. That came down to Ruby or .NET We debated this for quite a while. I ultimately decided on Ruby because of my longterm frustrations of using Microsoft development products. Every new version of .NET requires more and more resources, the development tools take longer to use, and it seems that Microsoft is constantly changing the languages or key features that you come to rely on.
Question: Where do you see the strong/weak points of Rails?
Rob: My in-house developers and I have had a hard time adapting to development with Rails. This was a key goal of the project – to develop additional inhouse expertise in Rails. I was unable to find sufficient time, and one of my senior .Net developers grew frustrated with Rails and stopped developing with it (however he learned Ruby and continues to contribute with that expertise). On the plus side, for those that understand the Ruby on Rails framework, they do seem to develop new features quickly.
Question: Would you Rails for another project?
Rob: From a technology viewpoint, the answer is Yes, but from a business viewpoint I haven’t made a decision on that yet.
Question: What do you think of developing and running Rails applications for so many customers?
Rob: I took a big risk in utilizing Rails to develop this application. So far it’s working, but the actual performance of the application is just barely acceptable. We need to optimize the application for further expansion.
Question: You used a mix of consultants, employees and offshore resources for this project, can you elaborate on this choice?
Rob: After I had completed the project’s high level design specifications (40+ pages) and a detailed data model in a “platform neutral” fashion, I was in a position to determine how I wanted to develop the project. I knew that due to internal resource constraints that outsourcing was the only real alternative to getting the project done in a timely manner. So I approached the problem of finding outside resources and making a final choice between using Ruby on Rails or .NET more or less simultaneously. Cost was an issue; but also what concerned me was that since I was not providing an extremely detailed design and I didn’t have the right system architecture experience to personally architect an enterprise web application using either Rails or .NET, I wanted the initial developers to be very senior and highly experienced developers who could look at the big picture of systems design and put something together that would support a large number of simultaneous users. I also needed to transfer a lot of domain knowledge to them, so I decided that going offshore for the initial phase of development would entail a tremendous amount of brain damage at best and a highly risky proposition in any case. So I decided that finding the right developers to initially build the system the right way was in our best interest.
Question: How did you ensure proper workflow between the different teams?
Rob: The application has a consumer front end, an administrative console, and a communications component with the restaurant.. I put my Ruby on Rails experts on design of the Front End application, my internal Ruby on Rails expert on the Administrative console, and a 2nd internal resource on the communications component. As I had spec’d out the communications component in great detail this was easier to manager. My ruby on rails experts that were working on the consumer application reviewed the data model and reworked it to make it work better with ruby. I acted as project manager and worked to explain the domain knowledge to all parties and resolve design issues as they occurred. It was a very hands on approach.
Question: Did you have difficulties finding Rails consultants?
Rob: I did. There didn’t seem to be much of a pool locally. Because I needed to transfer a lot of domain knowledge I wanted to find people locally that could come into the office and work. I was able to find 2 very key people to do the Ruby on Rails development, but struggled to find a graphics designer that had experience with Ruby on Rails and Liquid. It seemed to be a very small community of people that actually knew how to work with the technology.
Question: How did you select an offshore service provider?
Rob: I did a number of web searches to find companies offshore that claimed to have experience. I emailed each and began a dialogue with the ones that responded. I had several conversations with each company. Some I dropped off the list because I frankly couldn’t understand what there were saying! Another company I dropped off because I had a conversation with their lead technology guy and he started dissing the technology choices and suggested they could do better. It seemed like a classic case of NIH. The problem with that was I was looking for a company to take over the project and do new development, not rewrite the product! I ultimately got down to two companies, both of which seemed acceptable. I choose one and gave them a project that I felt was low risk to start with. Even if they failed completely the product would not be in jeopardy. Fortunately they did a good job and over time have made several enhancements to the product.
Question: You choose a hosted environment, did you consider using your own servers?
Rob: No. That would require additional investment in IT management resources that frankly we don’t have.
Question: What do you think of Engineyard?
Rob: Engine Yard has been a great choice for us because they have acted as the IT department for MunchAway. It’s great that almost every time I call them a real person that knows something answers the phone!
Question: Did the project work as expect?
Rob: Performance is an issue for us. This is really the only issue, and I expect that we will be able to resolve it over time.
Question: Did you encounter issues?
Rob: The issue that we ran into was that we expected to provide an application that would be easily maintainable the graphics designers by our users. This has not been the case, in fact, we have had to retain a graphics designer with Ruby on Rails and Liquid expertise to help us in this area.
Question: What’s planned next for the application?
Rob: The consumer side of the application needs to be extended so that it can be easily used on IPhone and Blackberry devices.
Question: Is this you first online food ordering application you developed?
Rob: Not directly. We originally developed a middleware application that provides the ability for web developers to interface with Restaurant Point of Sale. This is in use with several different online ordering companies for several years. MunchAway connects to that middleware and provides the full online ordering solution for restaurants.
Question: What differentiates your platform from your competitors?
Rob: Technically, because our middleware application extracts the restaurant’s menu from the point of sale system, we can construct a customer’s web ordering system quickly and maintain it very easily. Also, many online ordering solutions do not integrate with the point of sale system at all; they use a fax machine or email as the delivery mechanism for the order. From a business standpoint we are unique in that we market the product through a well established point of sale dealer network which understands the restaurant customer base and this is a real value add.
Question: Why do you offer a subscription based solution rather than providing one off solutions for you customers?
Rob: SAAS makes sense for our customers as we offer the hosting service as well as ongoing product improvement to our entire customer base.
Question: How restaurants (locations) are now served with your platform?
Rob: At each restaurant we install our middleware application which acts as the conduit between the MunchAway website and the Restaurant Point of Sale System. The middleware extracts menus (which incorporates the business rules of ordering each item on the the POS)_and posts them to the MunchAway website; it also accepts orders from the website and posts them on the restaurant point of sale system. This is a major plus for the restaurant as this eliminates all the labor involved in reentering the order and insures no mistakes are made in the process.
Question: How quickly can you add a new customer/new locations?
Rob: 4 man hours to add the customer’s first location, which includes installing the software at the restaurant POS and applying the customer’s graphic look and feel to the MunchAway website. Locations 2 thru X take 1 hour each to setup.
Question: Can a customer change the look and feel of your solutions?
Rob: No. This was an original goal of the project, but this has not yet been achieved. We rely on a graphic designer with ruby on rails and liquid experience to make customer customizations as needed.
Daniel Wanja
HTML5, iOS and Ruby On Rails Nouvelles Solutions, Inc.
d@n-so.com
