Author: Daniela Binatti
Founder, CTO @Pismo

I’ve been working in tech for the last 25 years. After a long journey climbing the corporate ladder, I co-founded Pismo 5 years ago.

Among the challenges of starting a company from scratch, such as ideation, prototypes, discussions, business plans (and more discussions), the freedom to choose the technology stack was the most fun part.

People ask me how and why we’ve chosen Pismo’s tech stack, but the truth is that it’s as much an art as it’s a science. The decision must consider the company’s stage and, more importantly, some aspects of the business that are must-haves.

Pismo

Our dream was ambitious from day one. We were convinced that we would unleash a new era of payments, delivering the most reliable, innovative, and comprehensive infrastructure for payments in the world.

That meant replacing 60-year-old legacy systems (most of them written in Cobol) with a set of microservices hosted in public clouds. We would provide services for large banks stuck in ancient systems that struggle to offer their customers new features.

A huge responsibility! As of 2018, those systems were still responsible for processing 80% of financial transactions. Although they were taking far too long to deliver modern products and features, they were very stable systems for fulfilling their intended role.

Pismo’s must-haves

Core processing is a highly sensitive service. A flawed bank statement is not the same as an ill-suited movie recommendation.

People can get a little upset by interruptions in their favorite streaming services. However, they will be infuriated by any instabilities in their chosen payment method when buying something.

We must guarantee security, availability, and scalability.

(A parenthesis on Pismo’s co-founders’ backgrounds: we’re a team of second-time entrepreneurs with a combined 80 years of payment processing experience. We’ve had the unique privilege of building a payments platform from scratch — twice!)

Most of the players in the payments industry look more like BPO companies than tech businesses. Under the hood, you can find not only tons of old lines of code but also lots of human interventions to keep systems up and running.

We were out to change all this! Our platform would have to be cloud-native, batchless, highly automated, distributed, and renewable (the last one to guarantee that we wouldn’t become museum pieces, but that can be a topic for another blog post).

Bootstrapping

In 2016, Pismo’s co-founders bootstrapped the company, so we didn’t have a team to operate infrastructure services. I was responsible for architecture and infrastructure, and Marcelo, one of my partners, was the software engineer in charge of the MVP.

Given the resources, we needed to make intelligent decisions about the tools, always keeping in mind the big picture and the desired architecture:

Public cloud provider (because I’m too old to pet on-premise servers again): AWS.

Programming languages: Groovy (and vertx.io) and Golang (because we need high throughput). Actually, by the time we were looking for seed investment, we built the MVP in Ruby but rewrote it in Groovy for production.

Databases: RDS, DynamoDB, Redis – We chose the databases carefully, considering the service’s scope and purpose.

Additional managed services: SQS, SNS, Lambda, Kinesis, and many others.

At some point, with a bigger and highly specialized team, we started managing some services internally. And, after a short period of deploying our services on Kubernetes, we have adopted Istio service mesh since version 1.0.

2021 and final thoughts

At this point, the stack is not the same anymore. We have a multi-cloud platform operating on top of AWS and GCP. We’re adopting a distributed database, and we’ve been using Kubernetes and Istio service mesh for a long time.

When choosing your tech stack, pay attention to the resources available and the outcome of your project — even if you take baby steps, at least you’ll head in the right direction. Try not to put into the equation problems that you will be able to handle in the future (when you have more resources and a bigger team), and, most importantly, have fun 🙂 .