I am fortunate that the people at DispatchBot is nice enough to entertain my request. Their CTO, Brad Seefeld and I went back and forth a few times in email for this. I haven’t had the time to translate this in Malay. So here it is, my interview with Brad, in English…
Perhaps I will translate this to Malay later, or if I get myself a volunteer. 🙂
1 – Can you tell me about your background as in school, education, professional training?
I graduated with a Bachelors in Software Engineering from the University of Washington in 2009. Throughout school I did freelancing for some fairly basic web applications and e-commerce websites. After undergrad, I started working for a financial risk management company. I also applied to grad school and received my masters in Software Engineering in 2012. It was an evening program so I was able to work and go to school at the same time.
2 – Can you tell me about your previous career before working on DispatchBot?
Most of my professional experience has been in web applications. Previously, I worked for a company that would audit merchant websites for fraud, abuse or other illegal activity. If your website accepted Visa, MasterCard, or just about any major credit card, we were monitoring it to make sure the merchants were not doing anything too nefarious. I was the lead developer for one of the web teams. We would create portals where clients could review their merchants activities. Most of this was in Ruby, but we also had components in Java and PHP.
3 – What is your role in DispatchBot?
I am the co-founder and CTO of DispatchBot. I was the primary developer for most of the original development. Lately I have been involved with more of the client facing work, helping give demos and collecting feedback from existing customers. We heavily leverage our customers for which features get priority.
4 – So how did DispatchBot came about?
DispatchBot’s target audience is non-emergency medical transportation (NEMT) companies. As no (affordable) software solutions existed for small to mid sized companies in this industry, my partner and I saw an opportunity to deliver. This was in 2010. We developed a prototype in Java over a couple of months and put it on Google’s App Engine. After a few months of usage by our beta testers, it was apparent that we had something NEMT companies needed. Our product has undergone several major revisions and a rewrite since. Our development process is fairly simple; we rapid prototype features with a few of our clients and iterate until we get it right. Then we release to everyone. At some point during those iterations, we had created a real company with an application that many organizations depend on daily.
5 – Can you share with my reader what you used to develop this software and why you chose that?
We originally developed the application in Java and Google Web Toolkit (GWT) (started in March 2010). It was to be hosted on Google App Engine (GAE). We were originally drawn to GWT for its promise of cross-browser compatibility and a seamless development environment (being able to use Java on both the server and the client).
Our experience with GWT was rather different, however. If you have ever developed with GWT there is a fair amount of boilerplate code (although it has gotten much better). Some bugs were very difficult for us to track down since the compiled javascript code is not the easiest to map back to Java source. When RequestFactory came out, we upgraded but had many performance issues with the serialization layer. For large batches of objects, RequestFactory would take 25+ seconds on the server to serialize the payload. We were able to optimize much of that ourselves, but being able to rapidly prototype in this environment was not possible for us.
We originally chose GAE for its simple deployment. Scaling up was just a push of a button, right? We found GAE was able to handle peak loads fine, but we eventually migrated due its unreliability. The service would go down for hours at a time, which is not acceptable for our business. It was especially frustrating because there is very little you have control over in GAE. You basically just hope the Google engineers fix things quickly.
At the end of 2012, we decided to rewrite our application in Ruby on Rails and move to a VPS solution. Ruby on Rails had become one of the most popular frameworks to write web applications in. I had experience with RoR from some other projects. It was something we were familiar with and we knew we could do rapid prototypes with it. We picked jQuery on the front-end for the same reasons. This new system went live in March 2013.
Our front-end is backed by MySQL and Apache Solr 4.x. Solr is an open-source search service that I had used quite a bit in the past. It had the features we needed, is fast and is reliable. ElasticSearch was the other option, but Solr was chosen based on the fact that it was a known technology. We use Sunspot to allow Ruby to talk to the Solr service. We didn’t realize it at the time, but the facet features of Solr has been a huge success for our customers. Faceting allows the user to see all the unique values for a given field and search by that value. For example, our search page will show a list of all the statuses (with result counts next to each value). Clicking a status filters the results by that status.
Any heavy-lifting we do in background processes. We started out using Redis and Resque, but have recently switched to Sidekiq. Resque forks a new process for each job, whereas Sidekiq uses a thread. This simple change resulted in a 10x increase in throughput.
We spent a brief time with Linode before switching to AWS. AWS’s services have been great; just the right balance of abstraction (e.g., RDS) and control. We utilize AWS’s multi-zone features as well as multi-region via Route53. Most of our systems are distributed not primarily for performance but for fault tolerance.
6 – Can you share you marketed this software? Fully online? Offline as well? Tradeshows? Demos at client’s offices?
We market the software primarily through targeted online advertising. We also go to about two trade shows per year that cater to the NEMT (Non-Emergency Medical Transportation) industry. In June of 2012 we formed a Business Alliance with TomTom. TomTom is the world leader in personal and commercial GPS solutions. This alliance allows us to offer not only dispatching and scheduling, but real-time fleet tracking as well. We have joint marketing efforts with TomTom to advertise this integrated system.
7 – How do you manage customer support?
We manage customer support by phone and email. We use HelpScout for our email support and GrassHopper for our phone support. We are working on a more comprehensive self-serving support center, which will include video tutorials and articles. I believe our customer service is excellent, but its something we are always looking to improve.
8 – How many staffs do you have? Marketing? Support? Developers?
Our team is small but growing rapidly. Most of our work to date has been in development and IT, so the staff is skewed to that department. There are 5 developers, including myself. We have two support personnel and then my partner and I make up the business side. We have a strategic partnership with some consultants that help with leads and sales. By the end of the year, we are looking to increase the staff in support and sales to bring it more in line with the development department.
9 – Can you also tell me what is TOMTOM and what is the relation between TOMTOM and DispatchBot?
I mentioned some of this in the earlier question. TomTom is a mobile GPS provider. We formed a strategic alliance with their commercial line of fleet management solutions, Webfleet. Webfleet is a system of hardware and software that is installed into the vehicle. It can monitor the vehicle position, speed, turning force, braking force, idle time, and more. In addition, it allows DispatchBot to communicate with the vehicle in real-time. When a dispatcher assigns a trip to a vehicle, that trip is automatically sent to the driver. Information from the driver is automatically captured. For example, when the driver picks up the passenger, we can automatically capture the status change, the vehicle odometer and time of the event; all important information the dispatcher would have to otherwise manually collect from the driver at the end of the day.
When we integrated Webfleet with DispatchBot, we integrated it into the existing workflow. There is not a single action the user must take that they do not already take. This means that our customers can start to utilize the benefits of this system without any changes to their process.
10 – Mind telling my readers how are things doing so far with DispatchBot? Are you profitable yet?
I am proud of where DispatchBot is today. It was slow growing for the first couple of years, but 2013 has seen explosive growth. I feel this is likely due to our rewrite, at which point we introduced some important features and streamlined the workflow. Since the launch of the new version, our customer base has more than quadrupled and we are adding a healthy number of new customers every month. Our alliance with TomTom has also been fruitful as we have started to do more joint marketing ventures. Yes, we are profitable.
11 – You told me how the business came about. Can you share with me how you and your partner(s) started DispatchBot started financially — any angel investor(s), VC, loans or simply bootstrapping with your own money.
We didn’t use any outside funding. There was a very modest financial investment made in the beginning to help bootstrap. This funded a couple contractors for a few months as we got started. It was less than $10,000 a piece if I recall correctly. We were lucky enough to have two paying customers (acquaintances of my partners) as soon as we were able to produce a product. We ran the business very lean in the beginning. If we didn’t have money to run our ads for a week, then we didn’t run ads. Our main goal was to keep everything online and iterate on features as fast as possible. That said, what we could not afford to purchase or contract out, we invested our time. I spent a lot nights and weekends developing. I would get up really early to take customer calls in other timezones. It was a lot of work, but it was definitely worth it.
12 – Any advice for programmers getting into the SaaS business?
When starting a business, pick something you know. In my case, I had been freelancing in the industry for about 2-3 years and developed a fair bit of knowledge on how the dispatchers work and what their hassles are with existing systems. When you know the field, you can ask yourself the questions instead of relying on external customers. This only works to a certain point, of course. Nothing beats getting customer feedback, but customers are busy and you cannot rely on that 100% of the time.
Also, building the application is the easiest part. Either you have to possess a good set of business skills, or you need to partner with someone that does. For example, we rewrote our whole stack in about three months, and made some significant improvements and additional features over the old stack. I do not try to convince anyone that what we have built is especially technically challenging. But it took us over two years to build this business (to figure out the right feature set and get to a point of real profitability). There is so much more that goes into the business. I am an engineer so I enjoy the technical challenges and find them easier to deal with than the business ones. I think that will be the case for most developers and I would strongly encourage them to find someone that enjoys the business challenges as much as they enjoy the technical ones.