This is the latest in our “Inside the Stack” series featuring Underdog.io customers. This week, we hear from Peter Berg, the CTO at TheSquareFoot. Peter and his team have made one engineering hire through Underdog.io. TheSquareFoot recently closed a $2 million seed round and has openings on its technical, product, and business teams.
TheSquareFoot is a next generation, technology fueled commercial real estate brokerage serving the space needs of businesses across the country (a $30 billion/year industry). Our technology enables businesses to search for space all across the country, facilitates interaction between brokers and clients throughout the leasing process, and automates time-consuming and tedious tasks previously performed by humans.
We use Ruby on our backend and CoffeeScript, Sass, and Haml on our frontend. The underlying themes behind these choices are programmer productivity, ease of use, and flexibility.
Our application is built on Ruby on Rails which we chose back in 2012 because of its mature ecosystem and RAD orientation.
We use PostgreSQL for permanent storage and Redis for transient data (e.g. caching and queued jobs). We chose PostgreSQL over MySQL for its extensibility, and over MongoDB because of its relative maturity and popularity (in 2012).
Currently our application layer is deployed on Heroku, a decision we made early on to expedite our launch. The rest of our server infrastructure lives on AWS leveraging RDS, Route53, ElastiCache, and S3. We just recently began migrating components of our application to Docker, which we will ultimately use to transition our application layer from Heroku to EC2. This will give us greater control over the internals of our production environment.
We are most excited about the internal application we are building to help increase the efficiency of our brokers. Right now our brokers are closing about 2-3 times the amount of deals than a traditional broker, and our goal is for this application to push them into the 4-5x territory. This is a challenge from a front-end, back-end, devops, and product perspective that will require us to leverage expertise from every member of our development team to solve – and some members of our broker team as well.
From a front-end perspective, we need to make sure the application is highly performant across web and mobile platforms, as well as extremely easy and intuitive to use. The application will only help our brokers if they’re actually able to use it.
In terms of product, it’s essential that our feature set is narrow and dovetails with the needs of our broker team. To accomplish this we’ve established regular meetings between our brokers and developers to make sure that we’re of a single mind when it comes to the form and function of the application.
From a back-end perspective, our goal is to support all of this functionality with a minimally complex and yet powerful network of objects. Laying such a foundation will ensure testability and maintainability, as well as make iterating on the application as easy as possible.
Another huge piece of the application is going to be what we’ve called the tourbot – a robot that our brokers communicate with over email. The robot lives outside of our application layer and thus has posed some interesting questions as to where within our server infrastructure it ought reside.
Thanks to Peter and the whole TheSquareFoot team for a great post. Visit thesquarefoot.com for more information about the company and to see their open positions.
