CASE FILE: MeisterTask

role
Staff Engineer
period
2018-2024
stack
Ruby on Rails, GraphQL, Kubernetes, MySQL
about
large production task-management system serving millions of users
url
meistertask.com

Summary

MeisterTask is a task-management product used by millions of people — Kanban boards, project dashboards, automations, integrations, the full suite. I joined Meister in 2018 as a backend engineer and stayed through 2024, eventually working at staff level across the platform.

MeisterTask was created in 2015, and my job was focused around adding to and and keeping it running. That means shipping features into a mature product with real users who depend on it daily, keeping an eye on monitoring and contiuous refactoring. There is no single dramatic launch to point to — the work was sustained, cross-functional, and cumulative.

MeisterTask Agenda view showing a kanban-style board with task cards sorted by priority
The MeisterTask Agenda — a personal kanban view that pulls tasks from across projects into priority columns.

On the backend I worked across the Rails application, the GraphQL API, background job infrastructure with Sidekiq, and the MySQL data layer. A significant chunk of the work was API design and evolution — MeisterTask serves native iOS, Android, and desktop clients alongside the web app, so the API surface is large and changes need to be careful.

I led the migration to Kubernetes, moving the production infrastructure from a more traditional setup into a containerised deployment. Alongside that I introduced OpenTelemetry-based observability, giving the team distributed tracing and structured telemetry across the stack for the first time.

MeisterTask Reports view showing a stacked bar chart of task creation over time with filters and a task list
Custom Reports — filterable charts and task lists for project analysis, built on the GraphQL API.

Beyond infrastructure, the work was product engineering. Building features, fixing performance problems, refactoring aging subsystems, reviewing code, mentoring engineers, and making the kind of small daily decisions that keep a large codebase habitable over years.

The product had paying teams, enterprise customers, and SLA expectations — the usual constraints of real production software where mistakes cost actual money and downtime is not theoretical.