"Any idiot can point out a problem. A leader is willing to do something about it!"
– Tony Robbins

This fin-tech startup built an iPad based cashier system as a proof of concept. Market validation came early, and the half-baked system were sold and installed at retail shops. Under load however, the system started to crash at the worst times. Even during payment transactions.

Out the gate startups and fin-tech companies have entirely different mindsets at play: startups are meant to move fast, break things and fix all problems later. Fin-tech companies meant to avoid breaking anything, at all cost.

Fin-tech is booming however, and it provides plenty opportunity for new businesses. New startups are popping up week by week to create a new digital bank, build a blockchain, to make money transfer a breeze. They don't mind the added difficulty with regulatory issues, the increased responsibility of handling sensitive data and money.

Technology helps startups create their prototypes and minimum viable products quickly, with all that's good or bad. It's great that the product can be tested early in real life - but early prototypes likely come with bugs and errors, with which the users have to live together with. And in fin-tech, a bug or crash can often bring regulatory issues, and mean the end of business.

When we joined the team in Berlin, Germany, the only developers were still the two people in an outsourced, remote team. There was no quality control, no real customer support, and the app updates and new features came ad-hoc, often untested. More and more retailers wanted to use the product, which required extra features such as accepting new payment providers, attach different types of printers or barcode readers. The team couldn't keep up with the rapid development cycles and the increased workload.

Immediately, we needed to bridge the resource gap: we added developers to the Berlin team and supported the CTO with hiring our replacement. We introduced continuous integration & delivery systems as well as coding best practices: we wrote rigorous tests for the core code base. After introducing a 24/7 monitoring system, weekly iterations and release cycles, internal testers could take over quality control. We've left after only three months, when the team's new additions could take over all development works – and the project was back on track.

We don't share names in these case studies – while we are proud of our clients and their stories, we respect their privacy and business. For references, please get in touch with us directly.