Art Deco illustration of a founder coordinating Paperclip agents and cloud runner infrastructure

tl;dr;

I had an itch to run GitHub Actions on top of Google Cloud infrastructure with minimal overhead. I’ve decided to build a solution in public and document my journey. I plan to build this product exclusively through AI and document what is working and what doesn’t. I gave it access to my Cloudflare account with my credit card on file. So far it picked and bought me a domain https://runnerdock.com/, created an interest form, and configured emails so people receive confirmation of their interest.

This post covers my first 72 hours with Paperclip. It’s messy but it works.

Why I am doing this

I’ve stopped writing code since January 2025 as IDEs started to include agentic mode. With the arrival of Claude Code I’ve delivered more production changes in the last 13 months than at any time prior, despite having 20+ hours of meetings weekly and a large responsibility domain at my job at loveholidays. I love delivering value and I’ve been doing it assisted by Claude and Codex, but it was an incremental evolution from methods of the past.

I now want to see how far the right harness can take me in delivering value where I don’t limit my thinking to repositories, services, and teams. I want to see if I can build a real business with it.

The problem I want to solve with this business is self-hosted GitHub Actions using my existing Google Cloud infrastructure.

That is the reason I installed Paperclip.

What I connected

Base M4 Mac Mini:

  • Paperclip
  • Codex (as an app and CLI)
  • CEO as first agent
  • Cloudflare API token
  • Stripe API token

I don’t want to be in the way of Runner Dock’s progress. I don’t want to micromanage it. I am here to assist.

Paperclip task evidence showing the runnerdock.com domain purchase flow

Domain buying is not the hardest job in a startup, but it feels uncomfortable letting AI buy it on your behalf, meaning I am doing something right by pushing my own boundaries.

The current company shape

Here is the org chart from the local Paperclip UI.

Paperclip org chart showing CEO, CMO, CSO, CTO, QA, and UXDesigner agents

The hierarchy is intentionally boring. It is still on me to modify “system prompts” for each employee to forge desired behaviour.

The CEO owns the company direction. The CTO owns technical feasibility and implementation. The CSO owns strategy and monetisation. I am using the CMO role for market validation, positioning, outreach, and public narrative. QA and UXDesigner are present because onboarding and trust are not optional if the product asks for infrastructure access.

The work is already branching

This is the dashboard during the experiment.

Paperclip dashboard showing active agents, recent tasks, open tasks, and blocked work

At the time of this draft, Paperclip is tracking 58 tasks for the company:

  • 36 done
  • 4 todo
  • 2 in progress
  • 1 in review
  • 15 blocked

The blocked count is the most interesting number on that list.

A normal AI demo hides the blocker. It jumps from prompt to polished output. A real company spends most of its time discovering that something depends on credentials, pricing approval, a DNS decision, a product constraint, or a founder action. I see it daily in my job at loveholidays.

Paperclip makes that explicit. For example, the static site work can move only when Cloudflare token permissions are sorted. Billing work can move only when Stripe account ownership is confirmed. Paperclip makes it very visible and clear.

Tokens as salary equivalent

I also wanted to see usage accumulate by role.

Paperclip costs view showing token usage by agent role

The local cost dashboard currently shows zero dollar spend because this setup is using local subscription-backed Codex access rather than metered API billing. But the token counters are still useful. Across the active agents, the snapshot shows roughly:

  • 128.6M input tokens
  • 807k output tokens

I can put a price tag on achieved outputs and decide if we are getting more or less efficient with time.

The first upstream contribution

I also opened my first PR back to Paperclip while setting this up:

paperclipai/paperclip#5022: Add GPT-5.5 to Codex fallback models

That PR is small, but it is exactly the kind of thing I like about building with open tools. You use the system, hit a missing edge, fix it, and feed it back upstream.

Personal itch

Runner Dock is not an abstract AI-generated startup idea for me. At loveholidays, our infrastructure has executed 811,903 builds in the last 12 months. That is roughly 1,200 days of build capacity in a year, and some builder machines run with up to 32 CPUs.

Today I run actions-runner-controller on top of GKE. It works well, but it is not free operationally. We had to solve networking packet-size issues, install and maintain a lot of CRDs, build observability, handle incidents caused by GitHub and ARC version incompatibilities, design scale up and scale down logic, and keep tuning build performance. We increased reliability of our CI, and decreased build times by up to 50%.

I want to solve this problem selfishly for myself and see if others would be interested in the same solution.

The competitive bar is high

The market already has strong products. runs-on.com is polished, cheap, and very clearly solving a real problem.

runs-on.com product homepage showing GitHub Actions runner positioning

At roughly 300 euro per year, RunsOn is an easy purchase for many organisations.

runs-on.com usage proof point showing high job volume

I talked to the creator about Google Cloud parity. He was receptive, and I came away liking both the product and the person behind it. But Google Cloud is clearly not the main market for RunsOn today, and there is no clear ETA for first-class support.

namespace.so is also impressive. Its per-minute pricing is competitive with GitHub Actions, it offers high-end compute including M5 Max, and its caching features seem to be very potent.

namespace.so homepage showing high-performance CI compute

The adoption problem for our environment is migration cost. Using Namespace meant changing build scripts across 750+ repositories due to its unique caching mechanism - it will make our workflows “namespace.so” only - which will add a lot of developer friction when they forget to configure the correct runner in the new repo. I asked namespace.so for cache build steps that can support both platforms; the idea was received well, but it is not implemented yet.

namespace.so product detail showing advanced runner and caching features

The GitHub Actions market is very well supported - but Google Cloud self-hosted is left behind.

Why this should matter to AI entrepreneurs

If you are a solopreneur, no-code builder, or founder experimenting with AI, the temptation is to ask for the finished asset:

  • “Build me a landing page.”
  • “Write the code.”
  • “Create my pricing page.”
  • “Send outreach.”

Those are useful tasks, but they are not the company.

The company is the loop around those tasks:

  • What is the goal?
  • Who owns the next action?
  • What evidence changed the decision?
  • What is blocked?
  • What needs founder approval?
  • What can be delegated without waking the founder?
  • What should never be delegated?

Paperclip is interesting because it tries to model that loop directly.

It does not remove the founder. It changes the founder’s job. Instead of being the person who holds every thread in their head, the founder becomes the person who sets constraints, approves irreversible moves, and notices whether the company is compounding.

What happens next

  • Be public about what I am learning
  • Capture interest from others
  • Build Runner Dock with the agents to a point where it can execute non-critical builds
  • Keep iterating on features, performance, reliability and go-to-market

Currently, it is a very cheap experiment and a sneak peek into the future. It may also become a real business that will help organisations running on Google Cloud.