We sat down with Jo Kochaniak, co-founder and Chief Technology Officer of GetUpside, to learn how her team turned a visionary idea into one of the App Store’s most popular personal finance apps.
The following conversation has been edited for length and clarity.
How did you end up co-founding GetUpside?
I worked at Opower, which was later acquired by Oracle. It was a real trailblazer for other product startups in the area. I had been there for about five years. It’s where I met Alex Kinnier and the other co-founders of GetUpside. Alex had been thinking about the idea for GetUpside ever since he was at Google.
Alex was ready to do something else, so he decided to start a company. He started talking to other people at Opower after work, including myself.
As soon as he explained it to me, I thought “Okay, this could be huge. This is great. I love this group of people and I’ve worked with them in the past.”
I told him I was in.
Did you always have an interest in early-stage companies and startups?
To be perfectly honest my initial response was, “Okay this sounds great, but I kind of wish you’d asked me this five years ago.” I was looking for a more stable, longer-term thing. But with this group, working with these people, I was very excited for the opportunity.
What is GetUpside?
The way I think about it is that we are connecting consumers with merchants. We guarantee an incremental profit for the merchants while helping consumers make everyday purchases at a lower price. Our mission is to make local communities stronger by connecting people to local places they may not have gone to if they hadn’t found them on the app.
How do you build an app like GetUpside?
We built GetUpside on AWS. When we started GetUpside, we had limited experience building a cloud-native application since we had our own data center at Opower. We chose AWS from the start because we wanted to be able to scale quickly if necessary. AWS has made it much easier to scale as our app usage has grown.
Our code is written in Java and Python. We chose Java because we were all familiar and comfortable with it. We weren’t trying to learn cool new technologies, or test out new programming languages. We wanted to build a business. Therefore, we chose a language we knew well and that is well supported. In addition, we knew that there are many engineers who know Java, so it would make hiring easier in the future.
We also chose Python for many of the same reasons — it’s a well-supported language with many users. Python is especially heavily used in the data science and machine learning communities, and our business is based on data science. So we wanted to pick a language that had libraries to support the things we needed, as well as one that would allow us to hire experienced data scientists in the future.
Our platform is built on a microservice architecture. Our microservices own specific data sets (e.g. all merchant data, all user data). We use the Dropwizard framework to speed up microservice development. We built microservices from the start since we saw at Opower that this type of architecture allowed the engineering team to move faster by decoupling different parts of the platform. This makes it easier for teams to develop independently, without interfering with one another.
For storage, we use MySQL and DynamoDB. Again, we chose MySQL because we were familiar with it, which made it faster for us to ship new features early on when we were still proving our business model. We took a gamble on DynamoDB, which we had never used before since we knew some of our datasets could grow very large in the future. We’ve been very happy with how well DynamoDB has scaled.
Another experiment for us was developing our Mobile UI Service on AWS Lambda and API Gateway, with a serverless architecture. The lambdas are written in Python. Our app only interacts with this service directly, and the lambdas coordinate with the backend Java microservices to retrieve data. We chose to do this since we wanted to be able to quickly iterate on the app experience, depending on user metrics and feedback. We knew that our core models and data would not change as often, so we wrote those microservices in Java. However, having Python lambdas for interacting with the app allowed us to quickly deploy and test changes to the user experience, allowing us to be more flexible.
You gave a talk at the DC Python Meetup about using Scikit-learn. Why did you choose Scikit-learn?
We had a machine learning problem to solve at GetUpside, and since we use Python heavily, I looked for a Python machine learning library. Scikit-learn is one of the best known Python ML libraries and has really great features and documentation. After using the library in production, I was excited to share my experience with the DC Python community.
What’s something at GetUpside that you’re excited about?
I’m excited about the possibilities for the business as we grow. We are expanding into new verticals — restaurants and groceries — this year, and gaining more and more users. We’re constantly trying out new ideas and technologies, so there’s never a dull moment.
How do you keep user data secure and private?
We’ve always developed with a security-first mindset, but we’re making that official this year as we get all the formal processes and procedures documented across the business to earn an ISO-27001 certification. We never sell user data, and we collect as little information as possible – only what’s necessary to do what we do.
You mentioned that last year, you migrated all your microservices over to Kubernetes. Why?
Yes, last year we had a big push to migrate all of our microservices over to Kubernetes – pretty much for the same reasons everyone else is on it.
At the time we were running our microservices in EC2. Whenever a lot of users logged on, we were running one microservice per instance per machine. Our costs could get really high when we had to scale up due to the high volume. But with Kubernetes, we can now run multiple services on a single instance, and our services scale automatically depending on traffic. Kubernetes also makes deployments easier since there’s no downtime. We can use rolling deployments to ensure a new version works as intended.
How is your engineering team broken up?
At GetUpside, we have scrum teams and use an agile development cycle. The teams are organized by product area but are pretty fluid. Our backend engineers can move from one team to another as needed depending on company priorities. Most of our engineers work on the backend and can fluently move around teams as needed, though we try not to change them too often.
Our mobile development team is separate and only works on the app.
We also have a merchant dashboard written in Angular 7, for merchants to see transactions taking place at their stations. Engineers working on that team tend to be more full-stack, with both frontend and backend experience.
Want to hear more from Jo Kochaniak? Check out this presentation to the DC Python Meetup!
Want to learn more about GetUpside? Check out their company page and blog to learn about their company culture, product, and more!
