Elternkraft: the origins of Dispatch

Dispatch was not planned as a product. It started as a helper for a real project with a real deadline: Elternkraft, a mobile app for expectant and new parents. This article covers what we built, how the team worked, and which parts of that way of working ended up in Dispatch.

The project#

Elternkraft is made by Elternkraft GmbH in Berlin. It supports couples through pregnancy and the first years with a child. Two AI companions share a family context. Constanze accompanies the mother and Charles the father. The app also has a shared family area, a feed for moments and tasks, and small everyday helpers such as a contraction timer, a breastfeeding tracker and a meal planner. The data is processed on servers in Frankfurt. The app says clearly that it gives coaching and orientation, not medical advice.

The team had three people: the CEO as product owner, a part-time interaction designer, and me as the only developer. We met once a week. There was no QA department, no project manager and no second developer, so Claude Code had to take on a lot of that work.

The timeline#

• 30 March 2026: first commit to the app repository.
• 2 April: the first internal release, v1.0.0 Basic Chat.
• 4 April: Andrej Karpathy publishes his LLM Wiki gist. We were still discussing which AI tools to use, and the gist settled it.
• 15 April: the project wiki gets its index.md and its append-only log.md, set up the way the gist describes.
• 11 August: v1.4.5 goes live in the App Store and on Google Play. That was 134 days after the first commit.

The launch version was the project's 18th release, and Claude wrote the release note for every one of them.

The wiki became the backbone#

We set up the wiki as an Obsidian vault on Google Drive and linked it into the code repository. The whole team could read and edit it in Obsidian, and the coding agent could read and edit it as plain Markdown. Requirements, UX notes, engineering docs, legal texts, meeting notes and release notes all lived in the same place.

The ticket tracker, Asana, was connected over MCP and followed the wiki. The rule was simple: the wiki decides and the tracker follows. It sounds bureaucratic, but it was the reason the agent had enough context to get things right on the first attempt.

Today the Elternkraft wiki holds more than 500 notes:

• 114 user stories and 40 bug tickets
• 71 Architecture Decision Records
• 21 release notes
• about 50 generated reports, such as MVP gap analyses, inconsistency checks, industry news digests and production user reports
• a log with more than 480 entries of what the agent changed and why

Almost none of it was written by hand. Claude did the bookkeeping, and we made the decisions.

Refinement moved into the chat#

Meeting once a week meant that open questions could hold up a ticket for days. So we connected Slack as well. Refinement of a ticket now starts with a Slack post in which Claude lists the ticket's open questions. The team answers in the thread when they have time. After a day or two Claude sums up the thread, writes the answers into the ticket and counts the questions that are still open.

That count became the badge on the card. Amber means there are still open questions and green means the ticket can go into development. The CEO and the designer no longer had to read a ticket to see whether it was blocked. They could see it on the board.

Decisions got written down#

During development, Claude started to pull Architecture Decision Records out of the tickets. I had used ADRs in earlier projects, but this time the agent asked for them. Reading every old ticket to work out which decisions were still in force was too much work. The ADRs became the project's rules, including the ones that say we deliberately do not do X.

We also froze a ticket's contract once code had been built against it. After the freeze, new information is added as a dated note and nothing is rewritten. Otherwise nobody could later tell whether the code was wrong or the spec had changed.

Meetings fed back into the tickets#

The biggest surprise was the meeting notetaker. Gemini's own summaries of our Google Meet calls were only somewhat useful, because Gemini did not know the project. When Claude imported the full transcript into the wiki, it could link each topic to a ticket ID, fold the decisions into the affected tickets and collect the action items, grouped by person.

It could even correct the transcript. In one session the recording tool put all of one speaker's words under another person's name. Claude noticed because the dialogue did not make sense that way, and it fixed the attribution in the meeting note.

A board on top of the wiki#

By early summer the process worked, but it only existed as notes and commands. I wanted to see the tickets as a Kanban board, start the next skill from a card instead of typing it, and plan releases by dragging cards onto a version. So I built an Obsidian plugin for our own vault. That plugin became Dispatch.

Every step of the process became a skill that you start from a chip on a card:

/create-ticket → /refine → /implementation-plan → /develop → /test-plan → /release

Around these steps, /meeting prepares the agenda and turns the transcript into a report. A weekly maintenance run checks the backend for drift and writes the reports listed above.

The real test: the project without its developer#

I left Elternkraft at the beginning of September because of the budget. Before leaving, I asked Claude to write a handover note. It listed every credential, gate and machine-local path that depended on me, and every claim in it pointed to the file and line it came from. I also went through my agent's private memory files and moved the notes that would help others into the wiki.

On 1 September I introduced Dispatch to the CEO and the designer. We agreed on an interim split: the CEO takes a ticket through refinement to Ready for Dev, and the designer starts development from there.

Three releases have shipped since then: v1.4.7 on 10 September, v1.4.9 on 18 September and v1.5.0 on 24 September. They added dark mode, partner invitations, partner challenges, a meal planner and a reworked chat. The CEO, Rouwen Hirth, now runs development with Claude through the board's chips, and there is no developer on the team.

The wiki still records every step. Its latest log entries show a ticket that was refined, planned, built and moved to Ready for Build on the same day.

What we learned#

• The bottleneck is the clerical work, not the code. Once the agent writes the code, what holds a ticket up is unanswered questions, stale specs and decisions nobody wrote down. The LLM Wiki keeps those up to date.
• Refinement belongs where the team already talks. Connecting Slack was a late addition, and it was the step that made the whole workflow function.
• Write the important documents yourself. The agent maintains the wiki well, but the vision, the priorities and the decisions have to come from people.
• A wiki pays off as soon as there is a team. A solo developer on one app can manage without it. With meetings, stakeholders and outside communication, the wiki becomes the shared memory.

If you want to try this way of working in your own project, Dispatch 101 describes the workflow step by step.