… or as my team colleague Jezen put it so eloquently and true at the same time:

“35 Vaamo Stack Technologies that Vaguely Resemble Disney Princesses”

In earnest though: We’ve been working on the application that enables our customer to invest money and reach their financial goals, for quite some time now. And all the time while doing this people kept asking what our technology choice is and how this choice has been working out for us.

So I’m shedding some light on the first question and we’ll cover the second question in a future series of posts.


Our application is currently a “classic” web application, in the sense that most of the heavy lifting is happening on the server side.

Screenshot of mein.vaamo.de, that shows how a goal is

Server-side Technologies

Basically we have a Scala- and Play!-based application on the server, with some Akka sprinkled here and there for the offline processing parts. In production this part is running as a standalone application, via an embedded Netty server and behind an nginx-based reverse-proxy.

We use PostgreSQL as our only persistent data store right now, even though we use Event Sourcing extensively in our application, which in some circumstances lends itself nicely to non-relational data stores.

Client-side Technologies

On the client side we use Sass via the node-bindings to libsass as the obvious better way to work with CSS.

Our Javascript code is making heavy use of require.js to modularize our code-base. Jezen wrote a very nice overview on how to structure your modules in an easy yet scalable way. As the DOM manipulation library of our choice we currently use jQuery. We only use very small parts of it, so it might get replaced by a smaller library at some time.
For drawing the charts we use Flot. It was really great and served us well. It was ok to customize, but we somehow hit it’s limits already and as soon as we’re working on the graphs again, we’ll likely replace it with something based on D3.js.


Overall our tech stack is a nice mixture of proven technology and modern tools, that until now worked quite well for us.

As mentioned in the beginning of this post, we’ll continue sharing more details of our stack and architecture in the future.