How to think when building disruptive fintech – the CTO perspective
This is the second part out of four with Quiddly’s CTO Mattias. In the first part we learned how his interest in tech, philosophy and psychology, has shaped him into the CTO he is today.
In this part we take a deep dive into what it takes to build disruptive B2B fintech like Quiddly’s solutions that span three different business areas: invoicing, debt collection and credits. So let’s flip on the VPN switch, brew a fresh cup of java (not JS), and once again enter the wonderful world of a CTO.
Buying or building
Many CTOs face the question of buying vs building. We ask Mattias how he approaches this when serving financial institutions with high demands on security, scalability and compliance.
In finance, security and compliance are always first order factors. Beyond that, I’m pragmatic, every case is different, and there’s no magic formula. I’ve built my fair share of tooling, some just for myself, and it can be fun and educational. But the cost in time is almost always higher than expected. And there’s also the opportunity cost, what valuable work are you not doing while building this?
So in addition to technical and functional considerations, the buy vs build decision depends on business and human factors: strategic importance, alignment with core functionality, staff workload, budget, timing relative to other projects, and the energy or interest of the team who would implement it.
When you weigh all the aspects together, most of the time only one option is clearly viable. If not, I prioritize by identifying which factors matter most and making the decision based on that.
What is the philosophy behind languages and frameworks
Since it is pretty rare to get the undivided attention of a CTO, we take the opportunity to fire away all the questions we often have but seldom get to pose. We ask Mattias what his philosophy is when choosing programming languages, frameworks and infrastructure for financial platforms. Are the choices obvious? Why? Are there alternatives that are often overlooked?
He explains that at Quiddly, the guiding principle is to keep things simple. The specific technology stack is less important than whether it meets the needs of the business and empowers the engineers.
When selecting a language or framework, two factors matter most:
- Recruitment: do engineers have the skills and desire to work with it
- Productivity: does it offer strong developer experience and long term maintainability
Introducing a new stack should only happen if there is a clear business or performance benefit. Otherwise, too much variation increases complexity and makes it harder for teams to maintain systems effectively.
Mattias elaborates that it does not mean language choices do not matter. For example, most of Quiddly’s platform is built in Python, which has many benefits, but a few components would be better served by statically typed languages for performance. In another area, when the cloud team needed new capabilities in infrastructure as code, they transitioned from Terraform to Pulumi, as it aligned with both functional needs and existing expertise.
Ultimately, our philosophy is to adopt technologies that balance business value, developer experience, and sustainability, rather than chasing trends.
Good architecture is not dogma – it is data, context, and trade-offs
We ask Mattias what architectural patterns he thinks scale best in our industry. Is it monolith, microservices, event driven or something hybrid?
We notice a subtle smile followed by a short inhale and, “Sorry to be boring, but it depends. And honestly, that’s the best possible answer. Anyone who claims a single architecture scales best in all cases is full of themselves.”
Mattias expands that every architectural pattern, whether monolith, microservices, event driven or hybrid, has its own strengths and weaknesses. What “scales best” depends entirely on the definition of scale, your technology stack and your team’s capabilities.
A holistic approach works best: first define what scale actually means for your use case, then look at real load test data to understand your bottlenecks. Combine that with an honest assessment of developer experience, and only then can you make an informed architectural decision. In short, good architecture is not dogma. It is data, context, and tradeoffs.
Quiddly is both complex and fascinating to design and maintain
Quiddly builds complex platforms for credits, invoicing and debt collection. We are curious about the challenges when it comes to designing the architecture and maintaining the systems.
Quiddly’s platform separates each customer at the infrastructure level, giving every tenant a dedicated environment.
Each customer brings unique configurations, usage patterns and business sizes, which makes scaling, flexibility and consistent performance a real engineering challenge. Balancing all of that while keeping costs under control is what makes these systems both complex and fascinating to design and maintain.
At Quiddly a model of complete separation of environments at the infrastructure level has been chosen between customers. That decision comes with clear security and compliance benefits, but it also enforces a kind of architectural discipline that serves well when dealing with multiple stakeholders who often have different requirements, trust boundaries and expectations.
At the same time, user interfaces and authorization are separated for banks, clients and debtors, while relying on the same core API. Each UI is specialized to show only the parts relevant to that stakeholder, which simplifies the experience without duplicating core functionality.
Balancing risk and innovation is the core challenge. Full separation may not be the fastest path to iterate, but it ensures that as we innovate, we do so within a framework of trust and control, which in fintech isn’t optional.
What does it take to balance security, risk and innovation
In the third part of the article series we take a plunge into the depths of technical security, risk and technical innovation with Mattias and ask how to balance it all.