Building My Own AI-Native Cloudflare Hosted Project Management Tool
Why I built an MCP-native project management tool on Cloudflare Workers.
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.
Everything state-bearing is a Cloudflare binding. There are no servers to patch and no containers to orchestrate. That collapses the operational surface to almost nothing: there’s no infrastructure to monitor, only the errors in my own business logic.
Being open source from day one matters here too. GitHub gives me free compute for CI and free hosting for releases, and open-sourcing the code is itself a distribution channel, bringing us to the next decision.
Distribution
To take advantage of the GitHub actions free tier I needed to separate the deployment and my own data from the business logic of the Projektor application. I decided to build and release Projektor as a self-contained release artifact that a deploy repo pulls and points at Cloudflare resources. That’s what makes an agent-driven deploy possible: an agent working from a template repo never has to touch Projektor’s source, just a config file and a deploy script. This config-driven approach seemed like the natural way to give users control of their data and not have to write any of their own code.
Drinking my own Champagne
… is an expression I much prefer to the phrase “dogfooding”.
I put together a quick implementation that did a bare minimum of task tracking and then immediately started to use it to track my own development tasks and bugs. As I’d already decided to use a config-driven approach for hosting this tool, I then needed to figure out how I wanted to configure CI/CD for updating my own deployment as well as to define the deployment experience for a generic user. That starts with a release pipeline that’s the same regardless of who’s consuming it:
From there, two different paths consume that same release. My own instance updates itself automatically:
The interesting path is the one for a new user. projektor-deploy-example ships a deploy-auto.sh script that a coding agent can run end to end:
Point an agent at the repo, tell it to deploy to your Cloudflare account, and it pins a specific release, writes a binding-only wrangler.toml with no resource IDs pasted anywhere, and lets Cloudflare’s automatic resource provisioning create the D1 database, KV namespace and R2 bucket by name on first deploy.
Imposing architecture and best practice
It’s not always possible to control entirely what an agent is doing even if you prompt it well. I’ve also written a static analysis tool named cofferdam to enforce architectural conventions and catch common code smells at build time. This cuts the iteration time for new code entering the repo, because I spend less time picking up implementation details. I’ll hopefully be writing about how I’m using cofferdam for various sorts of checks and guidance in the future.
Success criteria
Normally I’d size a total addressable market before committing real time to a project. I didn’t need to here, because Projektor was built for myself. The bar was narrower and more concrete: does it scale to my own use, and can it drop into the background of how I already plan and execute work? In concert with more autonomous agentic workflows I’ve significantly increased the amount of work I can deliver on my projects. I haven’t had to think about the tracker itself to get that — which is the actual test. It gets out of the way of the actual work.
The real value of tools like these lies in how they’re able to facilitate what I see as where the bulk of the work now lies when building things, the process of deciding what is valuable to work on and what success or failure criteria apply to delivering it. I can now run prompts like \goal implement this epic, raise tickets as you go for bugs or feature suggestions you identify and review with Opus every 4 tickets and I can leave my agents to deliver Epics worth of work whilst I go about my day. Projektor now gives Agents processes and tools to collaborate and de-risk work. It doesn’t solve problems associated with writing bad code (that’s a hard one) but it does help structure them and help measure the number of bugs raised against user stories as I go.
Conclusion
Building my own project-management software was fun. It was interesting thinking more about how I can improve my own Agentic workflows to be able to deliver higher quality software, faster. Cloudflare Workers didn’t have to be the stack for an agent-native tracker; it just turned out to be the one that let me stop thinking about infrastructure. Config-driven, agent-operable deploys didn’t have to be the distribution mechanism either; they just turned out to be the natural consequence of building for an audience of one and then open-sourcing the result (or figuring out how to leverage free resources to one’s advantage!) I now have a platform that invisibly sits behind my development processes and enables longer and more autonomous workflows.