MonkeyTribe - CRM

Projektübersicht

Das MonkeyTribe Projekt ist aktuell in Entwicklung und es muss sich noch zeigen, wie weit ich dieses Projekt treibe und ob ein Produkt daraus wird. Deshalb ist dieser Post ein Einblick in die aktuelle Entwicklung eines Projektes im Status: WIP (Work In Progress).

MonkeyTribe ist als moderne, minimalistische und gleichwohl effiziente und innovative CRM-Lösung konzipiert. Neben typischen Basisfunktionalitäten eines typischen CRM-Systems sind in MonkeyTribe einige spezielle Aspekte berücksichtigt, die sich durch die Zielgruppe ergeben: Selbstständige, Freelancer und kleine Teams. Für mich ist es besonders interessant, diese Zielgruppe zu berücksichtigen, da ich 1. in dieser Gruppe bin und 2. ich hier eine interessante Perspektive im Rahmen der Produktentwicklung sehe.

MonkeyTribe CRM soll wenig ablenken bzw. nicht ’nerven’, es soll Komplexität reduzieren und nicht neue schaffen.

Die meisten CRM-Systeme zielen auf die Bedarfe von mittleren oder großen Unternehmen ab. Hierdurch entstehen mitunter wilde Anforderungsprofile, phantastische Preismodelle und Abhängigkeiten zu Prozessen und Anbietern. Mich würde aber interessieren, ob man dieses Terrain nicht völlig anders denken kann. Ob man z.B. nicht minimalistischere, nützliche und günstigere CRM-Lösungen entwickeln kann, die dabei helfen, Komplexität zu reduzieren.

Feature-Kandidaten (Basisfunktionen)

• Leichtgewichtiges Kontaktmanagement
• (Integrierte) Projektplanung und Ressourcenverwaltung
• Funnelmanagement
• Kollaborationsfunktionen für Teams und Individuen
• Erweiterbares Datenmodell (in Teilen)
• Automatisierung und konfigurierbare Templates
• Minimalistisches UI Design
• Konfigurierbare Views und Layouts
• API und CLI
• tbd: Selbsthosting möglich

Technischer Ansatz

Die Plattform basiert auf einem modernen Tech-Stack:

• App auf Basis von NuxtJS und TypeScript
• Auf Shadcn UI basiertes Layout für konsistentes und minimales Design ohne Friction
• Temporär: Supabase in der MVP Stage, wobei hier insbes. in der frühen Phase von der Authentifizierung und Row-Level Security profitiert werden soll
• Drizzle ORM für typsichere Datenbankoperationen und -Abstraktion von der konkreten Datenbank
• Containerisierung via Docker für einfaches und wiederholbares Deployment

Ausblick

Das MonkeyTribe Projekt macht Laune und aktuell werde ich es noch in der Pipeline behalten.

In der aktuellen CRM-Landschaft fehlt es mir persönlich an einer minimalistischen und innovativen CRM-Lösung, die ich selbst gerne nutzen würde. Viele Ansätze sind mir zu Land & Expand-mäßig verbastelt, zu komplex und zu teuer in Abacht der Core-Funktionen.

Deshalb baue ich mir das Wunsch-CRM vermutlich lieber selbst und halte hier auf dem Laufenden. Da das MonkeyTribe CRM allerdings ein Kandidat im MonkeyLab-Product-Funnel, kann ich noch nicht garantieren, dass ein öffentliches Produkt daraus wird. Ergo: Stay tuned!

UPDATE 2026 - MonkeyTribe 2.0

Zur Einordnung: das ‘ursprüngliche’ MonkeyTribe (1) wurde weiterentwickelt. Es beinhaltet inzwischen viele Funktionen, die (sagen wir: tendentiell) auf Solo-Selbstständige zugeschnitten sind und deshalb auch von KI (inbes. powered by lokalen LLM-Funktionen) Gebrauch machen, um Arbeitsabläufe effizienter zu gestalten.

Es beinhaltet sogar einen kompletten E-Mail Client, der den Fokus auf wichtige Dinge legt und vorsondiert, todos extrahiert … sowas eben. Daneben ist es zu einem (immer noch minimalen, aber bereits) umfänglichen Tool angewachsen, mit dem eine Oberfläche anstelle von 30 Tools genutzt werden könnten. Dies ist durch die Ausrichtung folgerichtig, entfernt sich aber von der sehr minimalistischen DNA leider. Es ist zu einem Tool mutiert, was die häufigen Dinge zu 80% gut beherrschen soll, damit man als Selbsständiger vieles in Kombination versammelt und so auch weniger Daten-Fragmentierung oder Abhängigkeit schafft. Denn klar - bei MonkeyTribe 1 geht es um Souveränität und das Abstellen dessen, was nervt.

Doch dann: Kein Fork, aber ein frecher Namensklau

Der Name des einstigen CRM-Minimalisten gefiel mir noch sehr viel besser für ein anderes Projekt.

Deshalb habe ich den Namen einfach geklaut und auf ein Folgeprojekt geklebt: MonkeyTribe 2

Die Idee hinter dem neuen MonkeyTribe ist konzeptuell und inhaltlich anders. Technisch handelt es sich dabei ebenfalls um ein ganz anderes Projekt. Zwar gibt es auch ein paar Überlappungen (Nuxt, TypeScript …), aber es hat eine komplexere Architektur, die in einem Monorepo angelegt ist und zielt auf andere Dinge ab. Die Struktur sah initial grob so aus:

.
├── apps/
│   ├── web/                  # Nuxt 4 + Vue 3 + shadcn-vue frontend (SPEC-0013)
│   └── api/                  # Fastify control-plane API (Drizzle + Postgres)
│
├── packages/
│   ├── shared/               # Domain types, Zod schemas, helpers (SPEC-0002, SPEC-0003, SPEC-0006)
│   └── ui/                   # Shared UI primitives & wrappers around shadcn-vue
│
├── services/
│   ├── worker/               # BullMQ consumer; control-plane callbacks (legacy) + agent-token RunEvent sink (TASK-13)
│   └── adapters/
│       ├── llm-gateway/      # LLM gateway (Ollama default; Mistral / STACKIT optional) — SPEC-0021
│       ├── mcp/              # MCP tool server (SPEC-0028, ADR-0015, TASK-25)
│       └── <integration>/    # Adapters (ACP, tools, external APIs)
│
├── infra/
│   └── docker/
│       ├── docker-compose.yml       # Infra: Postgres + Redis (project name monkeytribe)
│       ├── docker-compose.with-llm.yml  # Optional Ollama for SPEC-0021 smoke tests
│       └── README.md
│
├── docs/                     # Specs, ADRs, planning, research, architecture, glossary
├── .cursor/                  # Agent rules, skills, onboarding
├── package.json              # Root scripts (lint, test, build, format, typecheck)
├── pnpm-workspace.yaml       # Workspace definition (apps/*, packages/*, services/*)
└── tsconfig.base.json

Man kann wirklich sagen, geblieben ist nur der Arbeitstitel:

MonkeyTribe 2.0

Der Kern von MonkeyTribe 2.0 zielt darauf ab, die Arbeit zwischen Menschen und Agenten tiefer zu untersuchen. Es geht um die Frage, wie man Agenten sinnvoll in menschliche Arbeitsabläufe integrieren kann und umgekehrt — welche Unterstützung es braucht, um Teams effizient und qualitativ ergiebig mit Agenten arbeiten zu lassen. Das ist — bei tieferer Betrachtung — ein sehr weites Feld. Man kommt weder um HR- bzw. organisationstheoretische Überlegungen noch um Agenten-Realitäten drumherum. Meine These (flappsig formuliert): Hybride Teams sollten sich am Menschen orientieren, benötigen aber trotzdem ein neuartiges, ganzheitliche Prozess-Design und -Denken. Die Ermangelung daran ist sicher sehr häufig eines der fundamentalen Probleme in der Transformation von Organisationen. Allerdings ist dies keine echte Tool-Frage, sondern nur eine Frage, die sich auch auf Tool-Design niederschlagen würde.

Insofern ist die Challenge (samt Kontext) bei MonkeyTribe 2 komplex und noch ein erbarmungsloser Versuch mich mit der Materie in den Ring zu stellen.

Die hippe und Marketing-freundlichere Variante könnte ja so vertont sein:

Mit MonkeyTribe 2.0 kann man menschliche, nicht-menschliche (agentische) und hybride Teams organisieren und geteilte Aktivitätsflüsse zur Optimierung von Kollaboration von Mensch und Maschine transformativ gestalten.

Allerdings: Angesichts der komplexen (konzeptuellen) Natur des Projekts betrachte ich MonkeyTribe 2.0 zum jetzigen Zeitpunkt als reines MonkeyLab Research -Projekt, in dem es um Vertiefung von Domänenkompetenz und das Testen von Konzepten geht, nicht aber um einen kommerziell verwertbaren Quick Win. Deshalb bleibt die Zukunft des PoC auch erst einmal ungewiss.

Ich kann mich somit dem letzten Satz vor dem Update von 2026 nur anschließen und sagen: MonkeyTribe bleibt spannend - Stay tuned!