App development strategies from Swish's CTO Jeff Whelpley

Whelpley: In general, I'm a strong advocate of using managed services as much as possible for new products. Once you prove product-market fit and have demonstrated growth in usage, then you can start to make a decision as to whether the extra premium for managed services is worth the cost. The reason I take this approach is that a vast majority of product ideas don't work out. You spend a lot of time and effort creating the perfect architecture for software that eventually gets thrown in the trash. By using managed services, you can focus on what is more important in the earlier stages of your product (i.e. features and user experience).

Once a product is mature, you can make a more quantitative decision based on the current/expected physical infrastructure and human support costs of your product. In other words, is the managed service provider premium more or less than the cost of managing internally? The only tricky thing here to be aware of is that most companies don't count (or don't properly value) the cost of distraction. It isn't just about hiring one internal DevOps engineer to take over work from the managed service provider. The bigger issue is how as an organization, taking on too much infrastructure-related work, causes a productivity drain throughout the organization.

The one last thing I would mention on this topic is that all of what I am saying is assuming that the switching cost is relatively low. The litmus test for me is whether or not I feel confident that I could move everything from the managed service provider within a month if I wanted. As long as I believe this to be true, then it makes a lot of sense to get started with a managed service provider and use them as long as possible.

ADM: Perhaps relatedly, how does/should the size of the internal development team affect technology considerations?

Whelpley: It is true that size matters in this case because when your organization is large enough, there is a lot of value to build up your own internal DevOps team. However, even in that case, there is value to use managed services for quick experiments so that individual dev teams don't need to waste the time of other internal resources on projects that may or may not go anywhere.

ADM: What's your take on some of the most important open source technologies that can help app developers get off the ground quickly (and with relatively tight budgets)?

Whelpley: There are so many great open source libraries out there so I wouldn't be able to give any sort of comprehensive list, but here are some of the most helpful open source technologies that we have used and are relying heavily on today:

Angular: The recent updates to the Angular CLI makes it so easy to develop modern web apps.
Ionic: In my opinion, the best framework for creating a quality mobile app quickly.

ADM: What database engine and other backend technologies does the Swish app utilize, and how did you arrive at those decisions?

Whelpley: We currently use 3 databases:

MongoDB: Our system of record
ElasticSearch: For search queries
Firebase: For real-time data sync

We started off with MongoDB five years ago, right after we made the decision to try and use JavaScript as much as possible throughout our stack. The interface to Mongo is very JavaScript friendly so it was a natural fit. ElasticSearch and Firebase were introduced to solve specific problems that Mongo does not handle well (i.e. text search for ElasticSeach and real-time sync for Firebase).

ADM: What should developers look for when selecting a managed database?

Whelpley: In short: performance, reliability and a great support staff.

Some of this is hard to detect/measure up front. However, I have found that all three become obvious very quickly after you get started. So, my strategy is typically to accept the fact that I may need to try out several different managed service providers before I settle on the right one. Going back to one of my earlier statements, a necessary requirement for any managed service provider is that the cost of switching if you change your mind must be relatively low. Assuming that is the case, you should try out one service provider for a week and then switch to another week (or do both at the same time depending on the project). We landed on mLab as our Database-as-a-Service for MongoDB, which we originally found through its partnership with Heroku.

ADM: What sorts of tooling do you find are most valuable for managing application data/databases?

Whelpley: I am probably the wrong person to ask this because I love just using the command line and creating my own scripts to help perform a majority of management tasks. I know there is some really good MongoDB software out there for people that like GUIs (for example, Studio 3T).

ADM: Any particular technical lessons learned while creating GetHuman that were then applied to the development of Swish?

Whelpley: So many...where do I begin? OK, let me perhaps boil down everything to the one biggest lesson I have learned: build your app so that pieces (or the entire thing) can be easily thrown away and replaced.

Most developers (myself included) have a tendency to over-think and over-architect a system. The problem is that most of the time a majority of the assumptions we put into our system design are wrong and we don't realize they are wrong until the code is in production and real people are using it. So, it is much better to assume anything we build is temporary and someone else will replace it in the near future. This doesn't mean we are allowed to write crappy code. The quality standards should still be high. It's just that we need to be careful about creating too many internal dependencies that may be difficult to decouple in the future.

For example, with GetHuman I made the mistake of building a complex, custom rendering engine which was SEO friendly. This custom library worked well at first but became an albatross over time. Other open source libraries where created that provided superior functionality to our custom one, but our custom library was so intertwined throughout our codebase that it took us over a year of hard work to remove and replace this functionality.

ADM: For that matter, any lessons learned - through trial-and-error - building Swish?

Whelpley: As we were building Swish, we really embraced the Lean Analytics methodology for product development (http://leananalyticsbook.com/). There are some parts of this methodology that are likely familiar to most developers, but I found that the overall process prescribed by Lean Analytics has been perfect for what we are trying to do. One of the biggest principles of this methodology is that you should avoid building software as much as possible. Team members make hypotheses on how to improve the product, but then test a hypothesis before investing too much time or effort. When this way of thinking is fully embraced, it changes how you write code. Among other things, you push more code to production more quickly on shorter iteration cycles. Each change is made with a specific goal in mind that is measured and evaluated afterward.

We are actually halfway through a pretty significant redesign/upgrade of the entire Swish app, but instead of just building for three months and then launching, we have been pushing out daily beta releases that are tested and validated by a subset of our users. This approach is very new for me and is extremely exciting. I love getting feedback on a regular basis and it has very clearly helped us to focus on the "right" things that our users actually care about.

ADM: What other technical considerations are coming into play as you scale Swish?

Read more: https://swish.com/