Skip to main content
BlueForge
StrategyMay 29, 20263 min read

The Month We Built Nothing Anyone Could Use

Kristian Mandrup

Founder & CEO

May was our quietest month of the year, and it was not an accident. Our build-and-deploy repository produced seven commits across the whole month. The package registry produced one, a chore. On the product side, one landing page.

Rather than skip past that in a retrospective, it is worth writing down what the month was for — because a month with nothing to demo is either a month of invisible progress or a month of drift, and we can now tell the two apart.

What we were building

The month's real work was infrastructure as code: a Pulumi monorepo with four stacks. One for the compute layer — servers, DNS records, compose stacks, databases as typed resources rather than instructions in a document. One for self-hosted git. One for the hosting layer's Redis and Postgres. One for the control plane and its database. Plus a worker template for compute nodes and a pipeline that previews on a pull request and deploys on merge.

Two decisions in it were deliberate and both have held up. Databases are provisioned over SSH commands with no port exposed — the plan is applied from outside, and the database is never listening to the internet waiting for a client. And compose stacks can carry registry credentials, so a private image is a normal case rather than an exception to work around.

The first real conflict

The very next commit after the infrastructure landed is the one I would keep if I could only keep one: a database port moved from 5434 to 5435 because it was conflicting with another product on the same host.

That is the first time the fleet's actual constraint announced itself. Not CPU, not disk, not billing — port allocation on a shared host, where two apps that each work perfectly cannot both be right. Every serious operational problem we have had since is a descendant of that one: this is the shape of a platform whose difficulty is not in any single application but in how they share a machine.

Self-hosted git, client-first

At the end of the month, forge-git was created — and its first commit is not a website. It is a CLI command that SSHes to the Gitea host and asks its admin CLI to mint a personal access token. The second commit is the scaffold, and it is the only other commit in the month.

The ordering is worth noting because it inverted what we expected. We assumed the web application would be the thing and the tooling would follow. In practice the first need was a way to get a credential onto a machine, and the product grew out of that. By mid-June the instance was hosting forge-git itself, which is the point at which a tool you built starts being on the critical path for its own development.

The honest accounting

A month like May costs something, and it is not zero: the product surfaces went stale, the marketing site kept describing systems that had moved, and nobody outside the studio had anything new to look at. We paid for that in autumn, in a backlog of copy and imagery that no longer matched reality.

What it bought was the ability to deploy anything at all, repeatably, with a preview before a merge. Every post on this blog from June onward is downstream of a month that produced no product post. That is a trade we would make again, with one change: writing down what a quiet month is for, while it is happening, rather than reconstructing it afterwards.

Stay in the Loop

Get early access to our products and be the first to know when we launch.

Join the Waiting List