July 1st, 2016

Cases App: Technical Architecture and Decisions

By mary

Keeping context in mind is crucial when making technical decisions for a new product. If the product is intended for production use by a large number of people, decisions for the technology stack need to take scalability, performance, robustness, and security into account. But when the intention is to launch quickly and test product’s viability, the preference shifts towards flexibility to change, speed of development, and faster deployment cycles. We kept these factors in mind when making decisions for the Cases application.

At this stage, metrics are crucially important, as your decisions are informed based on usage and signal from the user. It’s crucial for the system to gather and deliver data that’s directly relevant and useful to the product decisions you’ll make at the end of the experiment: Kill, Pivot, or Persevere.

We wanted to build a platform for Health Professionals where they can present patient diagnostic cases, and respond to these cases in a short video format. Our hypothesis was that we believed a video platform with interesting and short video cases will provide a good learning experience and viewers will respond to the cases with video.

One option was to use a platform such as YouTube or Vine and create a flow that will use these platforms. We decided against it because the lack of control meant that we won’t be able to gather the data we needed to make a decision.

We rather decided to go for a custom built Ruby on Rails application. Ruby on Rails is known as a web framework that’s optimized for developer productivity. Productivity and speed of development is crucial to this stage where as a product maker, you’re optimizing to get back usage data as fast as possible. Also, my familiarity with Rails as a Ruby as a developer was important because that meant I can be productive developing an application in that framework.

Since it’s custom built, we have a lot of flexibility options on the data we gather. For example, we were able to gather each time the user logs in, and how many cases were viewed by each user. Gathering these metrics would have been challenging when trying to test the product with existing third-party products.

We also stayed away from iOS and Android as a platform of development choice for testing the Cases application. Even though we wanted to build the application primarily for mobile use, we decided against developing on iOS for the following reasons:

  • Developing an application on Android and iOS frameworks takes up more time than web based applications.
  • The deployment and customer acquisition methods require more technical knowledge for the customer.
  • It takes considerable time for Apple to approve the app into App Store.

Technical Architecture

These are the following pieces of the architecture that served up the Cases application:

Ruby on Rails Application

The Ruby on Rails application served as the most important piece of the architecture. This handled the backend, data persistence, emails, and front-end pieces. The database engine we used was PostgreSQL, an open source software known for its advanced features and robustness. It’s also preferred by Heroku, our cloud application hosting provider. We also used Ratchet CSS Framework, which provides pre-built stylesheets to mimic the experience of mobile apps on iOS and Android.


Videos are complicated to handle, because of encoding and the vast number of different input and output formats. While there are open source solutions such as FFmpeg that that can handle encoding, we wanted to make sure this piece is handled with as much reliability as possible. Our experiment would have drastically failed if for some reason, the encoding stopped working. We opted for Zencoder as a third-party paid service for encoding videos and creating image thumbnails. They charge $40/month for 1000 minutes of encoding. They have a REST API and a nifty Ruby gem that handles encoding easily. We also get information such as the duration of the video and responses from Zencoder.


To make sure we provide the best user experience possible, we needed a queue based background job processing service that can handle the dispatching and management of videos to Zencoder in a reliable way. Sidekiq fit this bill perfectly, it’s an efficient background job library for Ruby applications that’s built for concurrency and performance.

Amazon S3

Amazon S3 is a cloud storage solution by Amazon Web Services. Serving lots of large files reliably is what Amazon S3 is known for. We used it to upload the original files, save the encoded videos and image thumbnails. These files were later served by Carrierwave and Fog in the application.


We used Github to manage code source. Github is a web application built for the Git source control system, and has lots of collaboration features. For a lot of front-end fixes and copy changes, we used their pull request feature to incorporate changes directly from the other team members. This freed up time to focus on coding backend pieces.


As mentioned, we used Heroku as our hosting provider. Heroku is the easiest way to not only deploy Rails applications, but applications built on other frameworks and technologies as well. Since it was important to stay focused on testing the viability of the product, deferring the setup of a custom deployment server helped a lot. We were paying $14/month for each instance of the Cases App we launched. That was more than adequate for our needs. Also, deployment is just a one command away, which means no restarts, no configuration change, or sacrificing user experience by showing the maintenance page.


It’s fascinating how using proven engineering frameworks, robust open source software, and inexpensive but reliable cloud services, teams can build and launch products so quickly and cheaply, and test them out as real products on real people.

This is a guest post from Rizwan Reza, Principal Engineer at Neo and the MCOLi project.

Tags: Prototype, Technical


Please login or register to post a comment.