Building My Own AI-Native Cloudflare Hosted Project Management Tool | Tom Dickson's blogSkip to content6 Aug 2026<br>Building My Own AI-Native Cloudflare Hosted Project Management Tool<br>Why I built an MCP-native project management tool on Cloudflare Workers.<br>cloudflare-workersmcpai-agentssoftware-architectureself-hosted

I run several AI agents for my own projects at once, and none of the project management tools I tried could keep up. So I built my own: Projektor, an MCP-native issue tracker and wiki that runs entirely on Cloudflare Workers.

This post walks through the decisions that got it there: the problem I was solving, the stack I picked for it, how it ships to my own instance and to anyone else’s, and the processes and tools that impose and improve quality.

The idea

Git-native trackers such as beads are too primitive for coordinating several agents across a codebase (or multiple repos) at once. Jira is expensive, slow and built for humans filling in forms, not agents claiming work programmatically. Other open-source trackers either bring a complicated stack of their own or simply weren’t designed with agent swarms in mind. None of that is a knock on any one tool — they’re solving the problems their creators designed them for. I needed something I could deploy in a way that scales to my own use, and could keep adapting as my own workflow changed. I also found it very frustrating to have to adapt my own workflows to those of other providers, which provided a significant amount of motivation as well!

I decided to use the existing concepts of tickets (e.g. tasks/stories), epics, sprints and story points as these remain useful concepts even when using more agentic development. Tasks still describe the smallest most useful unit of work and epics still act to group tasks into units of work by theme or for a larger feature. Sprints allow prioritisation or bucketing of work by time and then complexity points still theoretically help understand how much time or resources might be required to deliver a specific item of work.

The idea was to create an issue tracker built for agents, not a human PM tool with an API attached afterwards. Tickets carry their own acceptance criteria and a verification command, because an agent claiming a ticket has no tribal knowledge to draw on. The claim path enforces work-in-progress limits itself, rather than leaving that to operator discipline. Agents claim the files they touch, so multiple agents can coordinate without colliding and then there is a wiki for project context management outside of a specific repo. It’s also very possible to work in worktrees too, but that doesn’t always have to happen.

Now that spawning ten agents against a backlog costs one prompt, that guard rail has to be structural. Every state transition gets a timestamp, so I can measure cycle time and throughput and use these numbers to benchmark how “healthy” a given project is given it’s particular nuances. For example, across 484 completed issues on Projektor’s own backlog, the median lead time (ready → done) is about 40 minutes and median cycle time (claimed → done) is about 2.2 hours, with a p90 cycle time of roughly 31 hours — a small number of issues sit far longer than the median, which is exactly the kind of signal that tells me where to look next.

The solution

I picked Cloudflare Workers with Hono, D1, KV and R2. Deliberately simple, and effective precisely because of that - especially when combined with their generous free tiers. There is definitely a high degree of vendor lock in, but Cloudflare Workers are open source, and to be honest pointing at object storage or a database won’t be that hard of a migration. These are problems I can solve when the need arises.

MCP (JSON-RPC over HTTP) is the primary interface. So far I have 110 tools across 21 domains covering issues, wiki, sprints, groups and more. I’ll see what I end up using the most and then how I can further refine how tools are exposed for various purposes. I’m still working through what new possibilities are unlocked from the new 2026-07-28 MCP Specification specification.

Bearer token + X-Workspace-Slug\"]\n human[\"Browser SPACloudflare Access cookie\"]\n end\n\n subgraph edge[\"Cloudflare edge\"]\n access[\"Cloudflare Access (SSO / Zero Trust)\"]\n subgraph worker[\"projektor-api — single Hono Worker\"]\n mw[\"rateLimit → auth → workspace middleware\"]\n mcp[\"MCP endpointPOST /mcp/:workspaceId110 tools / 21 domains\"]\n rest[\"REST routesissues, wiki, projects, groups, sprints…~134 endpoints\"]\n cron[\"Cron 03:00 UTCwiki trash purge\"]\n end\n web[\"apps/web: Astro + Preact islandsserved via [assets]\"]\n end\n\n subgraph data[\"Cloudflare data\"]\n d1[(\"D1: issues, wiki, tokens, activity\")]\n kv[(\"KV: access certs, email cache\")]\n r2[(\"R2: attachments\")]\n end\n\n agent -->|\"Bearer + workspace header\"| mw\n human --> access --> mw\n human --> web\n mw --> mcp\n mw --> rest\n mcp --> d1\n rest --> d1\n mcp --> r2\n...