Case Study: RadPad

Published 09/24/2018


Client Name



Real Estate

Problem Summary

RadPad is an end-to-end rental marketplace focused around people. Renters use RadPad to find a place, sign their lease and pay rent. Landlords use RadPad to list places, sign leases electronically and accept rents.

Jonathan Eppers, Tyler Galpin and Tim Watson founded RadPad in 2012 after attempting to find an apartment in Los Angeles proved to be a terrible experience.

Development began in July 2012 in Venice, California, and was released to friends on Facebook in October.

In January 2013, RadPad had reached over 10,000 downloads and was invited to join the startup accelerator Amplify.LA.

It was around this time that RadPad realized it had a scalability problem – both in terms of listings scraping and traffic through the app.

As a startup, RadPad needed an infrastructure that was highly available, redundant, secure and would automatically scale without human intervention.

And it needed to be done on a minimal budget.

Solution Summary

Gunner Technology proposed to move RadPad’s infrastructure to Heroku a Platform-as-a-Solution that was relatively easy to use and could be configured as part of the development process.


The biggest challenge was getting the memory footprint of the application down.

We inherited a Ruby on Rails application running Mongrels that consumed way more memory than the, at the time, allowable 512 mb on Heroku.

The app leaked like a sieve, too.

To combat this in the short term, we migrated to Unicorn application servers instead of Mongrel and used NewRelic to knock off some low-hanging fruit in terms of memory consumption.

We then wrote a script that would constantly monitor and kill Unicorn instances as they approached 100% memory usage.

Long term, we tracked down the leaks and optimized those as well.

Technical Approach

Here you will describe the software stack used in the project and why it is the best stack for the job. (Good Question for Gunner to answer)
Heroku allowed us to script deployments and easily clone the production environment for staging and demonstration purposes.

We could also run background dynos that would automatically increase in number to parse rental listings from various sources and replicate the data to our Postgres Database.

If, for example, there were thousands of listings to process, we could run 20 dynos and parse the listings in minutes and then scale back down to a single dyno.

This allowed us to keep cost low as we were only billed for the hours the dynos we running.

We did something similar on the front end to handle spikes in traffic which were occurring frequently as RadPad had begun to be featured in trade blogs and news media.

Project Management Approach

This was a trail-by-fire project as RadPad was an existing app with growing demand that needed fixing asap.

We attempted to run an agile approach, but ended up having to put out a lot of fires mid-sprint on the existing infrastructure while working on migrating to the new infrastructure.

We had at least one on-call engineer 24/7 who handled the fires while the other engineer worked on the stories in each one-week sprint.

Project Roles

Dary Merckens – Engineer

Cody Swann – Engineer

Proficiencies Used

  • agile
  • availability
  • AWS
  • AWS Availability Zones
  • AWS Regions
  • backend
  • Bug Sprint
  • Continuous Deployment
  • deploy
  • DevOps
  • disaster recovery
  • distributed service
  • Postgres
  • Feature Sprint
  • functional requirements
  • git
  • immutable
  • iteration
  • iterative
  • Ruby
  • Ruby on Rails
  • non-functional requirements
  • NoSQL
  • NOTS
  • production
  • Redundancy
  • research sprint
  • S3
  • scalability
  • serverless
  • sprint
  • technical requirements
  • the cloud
  • Tolerant
  • uptime
  • version control
  • Heroku

Lessons Learned

What did you learn from this project or when overcoming the challenges?
In this project, we learned the value of monitoring apps like New Relic and how invaluable they can be when trying to chase down memory issues.


After the migration, RadPad no longer had a scalability issue and managed 99.999% uptime.

Additionally, while usage increased over 1,000%, cost only increased by 32%.

Why Gunner Technology?

While at ESPN, Dary and Cody had migrated a large social network to Heroku when the platform was still young.

That gave us the expertise necessary for tackling this project while under fire.

Give us a try free for 30 days!

Don't take our word for it. New clients get to try our services free for 30 days.

We'll put together a team of analysts, developers and designers to partner with you and get to work.

To get started, just fill out the form below.

They show a passion for understanding our business objectives

They show a passion for understanding our business objectives

They get the job done on time and are quite adept at using open source technology, which saves us money. Gunner balances pragmatism and perfectionism, which is important to us. After using them for both short term and long term projects, we cannot give a higher recommendation

Sam Petteway - CEO

5348 Vegas Drive
Las Vegas, NV 89108
GSA: GS-35F-306GA | CAGE: 7Q6F5 | DUNS: 078818362
© 2020 Gunner Technology
Privacy Policy | Terms of Use