I Built Pull Requests for a Team of One

Our first blog post — and a grant application — said Deep Ice runs on OpenProject. It doesn't any more. Here's why I swapped it out, and why I then spent a week building code review for a studio with exactly one developer.

In our first post, and in the paperwork for the Epic MegaGrant, I described the project as running on OpenProject. That was true when I wrote it. It isn't now.

I've moved the whole thing to Jira, bolted on a peer-review pipeline the earlier writeups never mentioned, and — this is the part that sounds daft said out loud — built a pull-request workflow for a team that currently consists of me.

Let me explain why that's less silly than it sounds.

Don't defend the tool you already picked

OpenProject was free and self-hosted, which is a siren song when you're bootstrapping a one-person studio. So I picked it, wrote it into a blog post, wrote it into a grant application, and committed.

Then I kept hitting the same wall. The workflow I actually wanted — custom statuses, gated transitions, a proper review step that a task couldn't skip — was either awkward to bend into shape or sat behind a tier I didn't want to pay for. I was spending more evenings fighting the tool than using it, and the tell-tale sign of a bad fit is when you start designing around the tool's limits instead of your problem.

The lesson I keep having to relearn: being the person who chose a tool is not a reason to keep it. Jira does the workflow I wanted, for free. Two paid apps closed the gaps that made me reach for OpenProject in the first place — TeamBoard ProScheduler for the scheduling and roadmap view, ClockWork Pro for time tracking. That's it. The migration cost me a weekend and a sync tool I won't bore you with, but "the thing I moved to is genuinely easier than the thing I defended in a grant application" is a good enough reason to move.

The part that needs justifying: code review, for myself

Here's where people's eyebrows go up. I built peer review. With Helix Swarm. To review my own commits.

Stay with me.

Deep Ice lives in Perforce, because game projects are mostly enormous binary files and Perforce is very good at those. Perforce organises work into streams — think branches. In my setup every sub-task gets its own stream. You do the work there, in isolation, exactly like a feature branch.

What you can't do is submit that work straight up to the task, the epic, or mainline. Server-side triggers refuse direct submits to those protected streams. There is no "just push to main." The only way up is through a review.

That review is a Swarm review opened against the sub-task's stream. And this is where it starts to feel familiar:

• Open the review, and a webhook flips the Jira issue to Review Requested.
• Ask for changes, and it moves to Revision Requested and lands back on the author.
• Approve it, and the webhook does the merge for you — it copies the stream up into its parent, deletes the now-spent sub-task stream, marks the Jira issue Done, and even bumps the project version when a whole task lands.

If that reads like a GitHub pull request — branch, PR, review, merge, delete the branch — that is exactly the point. GitHub spoiled all of us. Perforce, for all its strengths, doesn't hand you that loop. So I built it: a small webhook receiver sitting between Jira, Swarm and Perforce, translating "a human approved this" into "the change is in the parent now and the branch is gone." It replaced an earlier OpenProject version of the same idea — same job, new front end, and honestly a lot more capable now that Swarm is carrying the review half.

I'll be straight about one thing the grant and the earlier posts never mentioned: Helix Swarm wasn't part of the story back then. This whole review layer is new. If you read the old material and went looking for it, that's why you didn't find it.

Reviewing your own pull requests is not the weird part

Yes — right now I am the author and the reviewer, approving my own work. I know how that looks.

But the gate isn't for today's me. It's for the day there are two of us.

The old setup rested on a single quiet assumption: one developer, who holds the entire project in their head and can submit anywhere because there's nobody to collide with. That assumption is a trap with a fuse on it. The moment a second person arrives, "just submit to mainline" becomes "whose half-finished work is in the build right now, and which of us broke it?" — and everything grinds while you sort it out.

I'd rather not discover that on the day someone joins. So I'm paying the cost now, while it's cheap and the only person I can inconvenience by getting the workflow wrong is me. The rails are being laid for a team that doesn't exist yet — because if the MegaGrant comes through, or some other funding does, the worst possible onboarding is "give me a month to build a review process while you sit idle."

What I'd tell the version of me who wrote that first post

Three things.

Don't get attached to a tool because you already put its name in a document you can't edit. Switch when the better thing is genuinely better — and say so plainly, like this.

Build for the team you're planning for, not the team you have — but build it now, while you're the only one who breaks when you get it wrong. A workflow you designed under pressure, with a new hire watching the clock, is a worse workflow.

And be honest in public about what changed. The setup I described a few months ago is gone. What replaced it assumes, in its bones, that Deep Ice won't be a one-person project forever. If that day comes, the second developer won't be able to tell that the pull requests they're using were built for an audience of one.