Building software in a FinTech startup
Be fast but reliable. And be faithful to your mission.
When we began our work at Conio 3 years ago, we were just 2 software engineers with an ambitious product to build and tight deadlines. At first, starting from scratch surely has the advantage of not having to rely on an existing codebase written by others which you do not fully understand. You also feel empowered: “everyone else is doing it wrong, we have an unrepeatable chance to build it the right way”.
In the “classic” engineering world there are plenty of examples: for instance, the Golden Gate Bridge of San Francisco, which began its marvelous construction after over 10 years of continuously revised design. Or the supersonic Concorde, which underwent 5 years of planning and design by teams in multiple nations before even starting to build the prototype.
These are examples of a top-down approach to engineering.
Engineering in a software startup
Dream big, but also be ready to face a harsh reality. This was our situation at Conio: a couple of software engineers, tight deadlines to show continuous progress to investors, and a constant perception to be behind your competitors. You don’t have the luxury to spend years to design a perfect product and only then build it. Also because, in an ever-changing environment, you don’t even know what “perfect” actually is.
That’s why you start to build software products that aspire to be Hyperloop-like, but that are often early last century railway-like. And, iteration over iteration, fixes over fixes, incremental improvements over incremental improvements, will eventually become the product you are proud of and the market likes.
This in an example of a bottom-up approach to engineering.
Our way
Neither approach is flawless. With a top-down approach you may reduce faults down the line, but it could take several years to release your product, at which point the market may have already moved on (farewell Zune). With a bottom-up approach you release your product faster, but it could be extremely challenging to improve its core infrastructure later on if market demand picks up (and that’s been the case of several popular cryptocurrency exchanges in 2017)
From the get-go, at Conio we decided for a hybrid approach to software engineering. This allowed us to ship products fast, and receive precious customers feedback.
Things were not perfect at the beginning. Design was Spartan, APIs were not optimized, upgrades to the underlying servers could require multiple days. However, everything was functional and — above all — whenever we built key architectural components, we always had in mind how our mission and how to improve them later down the road without having to do major re-engineering work.
One example is our key management system, the very core of the Conio products. It would have been easier to build a single-key wallet, but much harder to improve and a major a risk for many people: in these solutions, if you happen to lose your single key, you lose access to your Bitcoins. That’s a terrible situation that we at Conio have never been willing to accept for our customers. Therefore, when we laid down the foundations of our infrastructure, we decided to go for the more challenging route and establish our multiple key system along with emergency recovery solutions. And we’re very proud of what we have achieved.
Building reliable software, especially when dealing with money, is extremely hard. You need to address in careful details what’s mission critical for your product (e.g. in our case, key management) and what instead you can update at a later stage as company and product evolve. About this, in the next article I’ll describe our transition from a monolithic codebase to a microservice-based architecture. I hope this will help you in your decisions.
