Our developments

Our own products are the most honest stress test

That is where you find out quite quickly whether good ideas also hold up as software.

Customer projects are important. Our own products are something else again. There is no excuse, no briefing and no third-party process to hide behind. You build, decide, get things wrong, learn and then have to live with the result yourself.

Request a project

Kronberg / Less, but better

Dieter Rams

„Designer-Dieter Rams“ by Vitsœ at English Wikipedia, 2010

Source: Wikimedia Commons · Licence: CC BY-SA 3.0 · Image credits

Editing: Changes: cut out (background removed), cropped, scaled. The edited version is under the same licence, CC BY-SA 3.0. Edited by Today is Life.

Dieter Rams asked a question that is astonishingly radical in a world full of features: does a product really need this? For him, good design didn’t mean adding as much as possible. A product should be understandable, useful and long-lasting, and shouldn’t make itself more important than its task. With AI we can now build more and more functions ever faster. The real art lies in leaving out the ones nobody needs. Less software. Better software.

Dieter Rams (1932–) Industrial designer and one of the most influential product designers of the 20th century

Why we build our own software

For us, our own products are not a nice side project for quieter weeks. They are where it becomes fairly soberly clear whether our ideas of good software actually work.

In a customer project you can solve many things cleanly and still argue that certain limits simply come from the environment. With our own products, that excuse falls away. Then you are responsible yourself for the architecture, the priorities, the user guidance, the maintainability, the pricing logic, the operation and all the small decisions that together determine whether a product is pleasant to use or just somehow exists.

That is exactly why we often learn especially much from our own products.

There you quickly see whether a data model is really up to it. Whether a process was elegantly conceived but awkwardly built. Whether an interface is clear or only seems logical internally. And whether technical decisions are still sensible when the project turns into real use, real dependencies and real responsibility.

I consider that a pretty good test. Because software is easy to claim. It is harder to put up with it yourself over a longer time.

Our developments are more than references. They are a lab for product thinking, architecture and the very practical question of how systems feel when people really have to work with them.

Our own products

Chronuu

A platform for digital legacy and life documentation. A subject that must be technically solvable but above all demands trust, clarity and very clean user guidance.

GymBit

Software for gyms and personal trainers. Bookings, workouts, members and billing sound manageable but in everyday use are pretty good training in process logic.

€34 – €74/month

HealthSync

A product around health data. Here you quickly notice that software has to do more than work: it has to carry responsibility, too.

MysteryMail

An email role-playing game over several days. Playful, yes. But technically a good example of how timing, dramaturgy, automation and stable state logic have to come together.

More developments

StreetHunt

Gamification for cities and events. Interesting when digital logic has to reach into real places and real movement.

Nachtbrief

Another product from our house. Projects like this are often exactly the ones where you learn most internally about tone, structure and product feel.

Postkartenwerk

An API-oriented service for personalised postcards. Digital products often get exciting when they dock onto something concrete.

DevConfig

A tool for development environments. More technical and inward-facing. It helps us apply our standards of productivity and maintainability to ourselves as well.