“Roses are red and violets are blue, balancr is cool and so are you”, that was one of many zingers we came up with while building balancr.
Since going live back in May, we recently took some time to reflect back on what went into launching our new API platform for tracking stored value from external sources.
Releasing balancr was an incredibly proud and satisfying moment for us all. Everyone involved gave it their all to ensure it was released on schedule. We also shared some funny moments and learnt loads in the process, which made it a great overall experience.
So today we would like to take you behind the scenes and give you a glimpse of how we got balancr ready for the world.
To get the ball rolling, we started off with a kick-off meeting. After that, we then had three bigger workshops with the core team during development.
The balancr team consisted of five developers, a graphics designer, and a Scrum master. During these workshops, our objective was to decide what features we would include in the first release of balancr. The guiding principle was to think what our customers needed balancr to do and how to keep it simple so you can integrate it within a day.
We followed the Lean Startup approach here, by focusing on the essential features that would make the product usable on launch day. During the final workshop, we included those colleagues not working on balancr to weigh in with their feedback and suggestions.
One of the key items on the agenda was deciding what we were going to call our new product. So we created a competition where the winner would get a case of beer to take back home with him — we are based in Germany after all 😉
While you already know the name we decided on, you probably wouldn’t have guessed that the second most popular name turned out to be “Goldstein”. After seeing this suggestion, we weren’t entirely sure anymore whether developers were the best people to ask for product names. But nevertheless, we were quite happy that the winner didn’t end being something like “Boaty McBoatface”.
Once we decided what features to include for our MVP, it was time to start executing. For this we came up with a strategic plan which was called doing things.
There are many project management methodologies to choose from. But with our extensive history using Scrum, we just stuck with it. We wanted to keep the team small and have as little overhead as possible, so we could focus on executing. From our experience developing software in the fintech world, the Waterfall model was never really an option for us since we have been working with Scrum for years already.
During the development process, it was important for us to be flexible and be able to react quickly to any feedback we received. This is why we went with Scrum, which also allowed us to make the bug fixing process far smoother.
Staying on Schedule
How did we stay on schedule? We drank 1043 Nespresso capsules for a total of 690 git commits during the
While the caffeine certainly helped us, we aren’t too sure whether more coffee would have led to more commits. Probably something to dig deep into for next time.
Nevertheless, we also had daily meetings to identify any challenges and bottlenecks we were facing. This was great, as it allowed us to overcome obstacles as soon as they arose and find a solution quickly together.
Every project experiences delays and the main thing that kept things moving forward was our talented team. Having the right mindset and being solution-orientated was essential for getting balancr ready for launch.
Like any project, we faced a couple of challenges such as building an infrastructure for hosting balancr on our systems.
Team cohesion was also something we focused on in the beginning. We wanted to ensure everyone was on the same page and working as one unit. We achieved this by giving everyone the opportunity to get to know the product and propose new ideas during the development process.
Since we didn’t have a dedicated QA team, we solved this by giving more responsibility to our developers for the quality of code they wrote. Whenever a bug popped up, it was up to our developers to report it. This approach worked out quite well, as it made everyone have more ownership throughout the process.
If there was one thing we would have done differently building balancr, it would have been starting the legal framework process earlier than we did. Even though Terms and Conditions are probably the last
We had to make sure our lawyers understood exactly what balancr would be doing for them prepare our Terms and Conditions.
Because our API platform can be used to track and manage the balances of any kind of stored value, there were several regulations we needed to comply with — especially when dealing with sensitive data
There was also a need to set up the legal framework for on-site installations and for use-cases which involved e-money management.
Most people would think that just copying and pasting the Terms and Conditions from other companies is enough. However we heard enough stories to advise against doing that. It’s always best to seek professional legal counsel and have your own lawyers develop Terms and Conditions specifically for you and your product to cover all bases.
Apps We Used
While building balancr, we relied on some great tools and apps to help us along the way. You may already know most them. But here’s a list of what we used, just in case you want to try them out for yourself and find something new:
- Code editors: IntelliJ, SpringSource Toolsuite
- Collaborative working: Jira, GitHub, Slack
- Database: MariaDB
- Backend: Maven, Flyway, Java, Cucumber, Swagger
- Frontend: Ember.js
We learned a great deal going from concept to launch, and we hope you were able to get something out of our experience too. Let us know if you have any questions or feedback by sending us a quick email at firstname.lastname@example.org.