Blockchain based projects hold a special place in our hearts; after all, we pride ourselves on working in innovative industries and there are few more innovative notions than this technology and the solutions it offers. That’s why when presented the opportunity to develop Centi, a contactless payment system based on BitcoinSV we jumped on it head-first. It’s been a great ride so far and while we’re looking forward to a long collaboration ahead, we’ve already wanted to take a reminiscent look back to see what we can learn and appreciate from our first (almost) year together. Hopefully, you'll gain a lot of insights into the collaboration between a software house and a blockchain startup from it. So, without further ado, here's our case study.

What is Centi & How come we work with them?

As previously mentioned, Centi is a contactless payment system that enables you to “make BitcoinSV payments via the Point of Sales Terminal”. The whole idea is based on the efficiency of blockchain technology and powered by BitcoinSV. It’s very convenient for both the end-customers as well as the merchants as an electronic cash payment system translates to zero possibility of data breaches (since the identity of the person making the payment isn’t known neither to Centi nor the merchant), no settlement times, chargebacks or disputes.

Centi differs from payment processors such as Visa or Mastercard in that it doesn’t actually “own” the money — only manages it on the users’ behalf. The solution is fully contactless (contrary to regular card payment, where you often have to enter your PIN code manually) which is even more important amidst the coronavirus pandemic in 2020 and the strong focus on proper hygiene it initiated. Also, there are no card issuance or yearly subscription costs (or any other hidden fees for that matter). 

So how come such an interesting and innovative blockchain-based project has reached out to us? In the best way possible — through a recommendation. About a year ago, we met a great entrepreneurial guy during TCConf (a cryptocurrencies conference) in the beautiful region of Transylvania, Romania. Apparently, he was quite impressed with us because he remembered Code Poets even six months later when a friend from his network, Bernhard, asked him for some guidance in choosing a software house for a new project. There were three other contestants for the job but our blockchain focus and previous experience with similar startups worked in our favor.

The start of our cooperation

Soon enough, I had a video call booked via our website. I answered a lot of Bernhard’s questions about the way we work and we’ve talked through his idea. The meeting was extensively summarized via email, where our CTO Kamil has joined the conversation to discuss more existing and potential technical issues in detail.

In order not to bore the Client with filing in briefs and the endless back-and-forth we’ve had another meeting during which we drew all the information necessary to prepare an estimation that was as precise as it could be at that moment. That was also the moment when we’ve categorized the features according to their priority, since it’s extremely important to determine which functionalities are necessary upfront for the MVP and which can wait for later

After the second meeting we had solid ideas for the following challenges:

  • Tech stack and architecture
  • Team size & composition
  • Workflow organization
  • Pricing model

Initially the Client chose the fixed price option but once he was convinced that we were capable of delivering tangible results within a set time frame, he switched to a time & material model, which allows for more flexibility. Upon signing the contract we went into further detail, specifying team members and their roles and getting everything ready for the day that would launch our joined efforts. Just before that we’ve organized a kick-off meeting with Bernhard during which everyone got the chance to introduce themselves, talk about their role in the process, get to know each other a little better and go through the project's goals. We’ve also made some administrative decisions regarding the length of the iteration, planned cyclical meetings, retrospective sessions and everything else that’s recommended in the SCRUM methodology. Another date set was a weekly short 1-on-1 between Bernhard and me which would give us a regular opportunity to share information about recent events and potential problems, look for solutions to any issues that arise, monitor satisfaction levels, give and receive feedback etc.

Tech issues


We’ve started with architecture design and selecting the proper technology stack. The key thing was not to make it overly complicated but at the same time possible to easily extend in the future, since we’re building an MVP for now. And even with the limited scope of the solution, we needed it to be powerful enough to handle a certain number of transactions and stay perfectly secure. After all, it has to do with money, data and transparency.

The decision to use Python for the backend was supported by the fact that it's by far the most popular programming language. Thanks to that, it’s relatively easier to find skilled developers (for us or for the Client — if he ever decides to build an in-house team). Python is also a good compromise between performance and the ease of writing code. It can boast a lot of ready to use, high-quality libraries and that makes it very stable (which is exactly what we needed) since the whole planet uses it (=looks for bugs). 

A downside of using Python for this project is that it’s not the most popular on the crypto and bitcoin platform, where it’s exceeded by eg. JavaScript. Python is however a very good compromise between JS and other languages such as C++ or Java whose rules are “more strict” but also more demanding time-wise (and time is obviously the most precious resource when developing a startup, especially on such a competitive market as decentralized fin-tech).

Even though Python isn’t the most popular language in crypto, it wasn’t a big deal for us because we've designed the architecture using many microservices. That way it’s easy to implement interfaces or new services in other languages, since microservices talk to each other using API (application programming interface) that’s language-agnostic. We didn’t escape JavaScript altogether though as we used it to write several services and interfaces to implement some specific parts.

Business side

When we were discussing the details and negotiating the contract with Centi they were at the beginning of their visibility on the market — the company wasn’t even registered yet (it was still at the incorporation stage). Those were the very first steps of the startup funded with the private equity of the two co-founders and we were lucky to get involved already at this point. Having had the development team up and running already also helped the Client with his efforts to get funding, but he hardly needed any help at all. :) We, on our part, were able to support him whenever any tech issues arose during the process.

The second business aspect of collaborating with Centi are international and local financial regulations that differ between Switzerland, the EU and other countries. We have to pay strong attention to that, especially that there are several kinds of users who’ll be associated with Centi:

  • The individual customer (who isn’t even necessarily/most likely aware he’s using Centi).
  • The merchant who’s selling a good to the individual customer (eg. a hot-dog booth at a festival).
  • POS (Point of Sale) terminal service providers.

So, even though it might be tempting to stick to coding, we need to take the bigger business picture into consideration when developing the product (and we actually prefer it that way).

Another opportunity to maintain the big picture top of mind as well as have direct access to the decision-maker are the regular 1-on-1’s between Bernhard and me. During these it’s easy to give and receive feedback regularly, check the moods and morale and react to any signs of crisis before it has the chance to even start developing. The pricing model we’ve agreed on (time & material) also allows for the flexibility and doesn’t hinder any difficult but necessary business decisions.

Having Bernhard as the Product Owner has been a great decision. Not only is he a very hands-on guy who likes being involved in the nitty gritty of the project, but he’s also really good at defining the priorities clearly which is an important part of working in the SCRUM methodology. Maintaining the right balance between staying present and, at the same time, not micromanaging people is a valuable skill. We’re lucky to have a PO who trusts our competences in the technical area.

Finally, it’s hard to forget the cost aspect, with Switzerland being among the most expensive countries. Especially in times of pandemic, when most of the IT industry works from home anyways, it makes total sense to get the benefits of outsourcing to a place where specialists are more affordable (and just as — if not more — qualified).

Project’s evolution

Right from the start, we knew there were three main pillars of the whole idea:

  1. Simple BitcoinSV payments for day-to-day goods and services.
  2. Events like summer festivals (and a mobile app that would come with them).
  3. Micropayments for online news and entertainment (like a paywall-protected singular article in New York Times).

It’s actually a very good practice to chop your projects into several parts. That way you can develop them according to the priorities and any internal or external deadlines you may have imposed on yourself. Bernhard, as the Product Owner, was fully aware of that and we’ve made the decision to start with the MVP which would be based on only one of the three pillars. Working this way gives you way more flexibility, eg. should any delays caused by factors independent of you occur, you have other parts of the project to work on (or perfect the documentation like we did, with which the Client was particularly happy). Moreover, there’s always space for pivoting with your overall strategy which is a great asset to have as a growing startup on a fast-paced and ever changing market.

It was during our September in-person workshops that the Client went into detail about the rest of the pillars. We got to work straight away and even though it wasn’t always easy-breezy as the year 2020 took a toll on everyone, we were able to close it with great results and a clear vision for 2021’s further developments. It only goes to show that any potential hardships can’t stop truly savvy businessmen: you have to learn to ride the opportunities as well as the threat waves.


Working hard or hardly working? Having some fun with Bernhard after the (brain)storm. Zurich, September 2020.

As a result of the workshop’s brainstorming and the new decisions that have been made, we’ve extended the dedicated team to account for the additional workload. Another HR change implemented was turning one of our blockchain experts Krzysiek into a CTO who offers Bernhard technical guidance as an essential part of running a startup. We’ve also pointed the Client in the direction of the right service providers from our network who’d take care of any other development needs he had outside of our main focus and expertise.

Summing up

Working with clients such as Centi is really energizing and motivating for our entire team. We consider this cooperation a model for great communication and cooperation between the tech and business sides of a startup. It goes to show how important it is to put a strong emphasis on the end-goals, even when talking code. Without an extensive knowledge of the circumstances we wouldn’t be able to make agile decisions regarding the project’s direction. Even though it emerged amidst a panicked and unstable world, Centi is growing strong and we’re getting ready to see it take the crypto world by storm any day now.

If you’d like to see what Ben, our Client, had to say about us in return, read the review he’s left us on Clutch.