So what's slowing our team down?

As a three-month-old startup, we ship fast. Thanks to modern AI tools like Codex and Claude Code (don't worry - we still write most of our infrastructure code by hand), we deliver new features to the open-source community and our clients at a rapid pace.

Like most engineer-driven companies, we rely heavily on automation. We have pipelines for version bumping, releases, publishing, and more. But most of these automations were designed for teams that move much slower than we do today.

Take version bumping as an example. Traditional versioning workflows treat commit messages as the source of truth. They assume you will reliably write Conventional Commit prefixes like feat, fix, or chore, every time. But that assumption breaks down at Photon. We ship fast and iterate constantly, so we often rely on an AI to draft commit messages. To be honest, the result is usually better than what we would have written by hand.

An even bigger pain point is releasing.

For every release, we need to publish a GitHub Release and push packages to registries. But a good release also needs proper release notes: what changed, what features were added, and whether there are any breaking changes.

When you’re releasing every two or three days, writing thoughtful release notes quickly becomes the bottleneck. It is repetitive, time-consuming, and surprisingly exhausting.

All of these issues may sound small, but together they slow us down, frustrate the team, and get in the way of what we care about most.

Introduce BuildSpace

Finally, someone on our team stood out and tried to solve the problem. That turned into BuildSpace.

BuildSpace is a library of reusable GitHub Actions that snap together like LEGO to form CI/CD pipelines. We call these build blocks - small, modular units you mix and match to fit your team's needs. If you'd rather skip the assembly, BuildSpace also offers pre-composed workflow templates ready for adoption.

What's more exciting are the AI-powered blocks. Using tools like Codex, we can build blocks that infer version bumps and draft release notes directly from code changes, making the workflow much more autonomous.

What’s in the Box

We built this initial set of blocks to solve Photon’s immediate CI/CD needs. As our stack grows, we’re steadily expanding the BuildSpace catalog to unlock more automation and flexibility.

The AI-Powered Difference

AI changed how we write code at Photon - and it's changing what CI/CD can do. BuildSpace currently includes two AI-powered blocks, with more on the way.

The first tackles the versioning problem. Instead of relying on commit prefixes, our block uses Codex to read the actual diff between the previous release and the current one, then infer the correct bump (patch, minor, or major) from the code changes themselves.

The second tackles release notes. Our block uses Codex to read the real code diff between releases and generate clear, human-readable notes instead of simple commit-message dumping.

Here's an example generated for enva:

## New Features
- Added a simple root GET endpoint that returns “OK” for quick health/uptime checks (abc1bb2). ✅

## Improvement
- Renamed the server binary/targets to `enva-server` in Docker/Nixpacks so build and start commands stay consistent (abc1bb2, 1789394).

## Bug Fixes
- Fixed the release workflow crate list typo so the crates array parses correctly (3f1fb5b).

---
**Version:** 1.1.2

## New Features
- Added a simple root GET endpoint that returns “OK” for quick health/uptime checks (abc1bb2). ✅

## Improvement
- Renamed the server binary/targets to `enva-server` in Docker/Nixpacks so build and start commands stay consistent (abc1bb2, 1789394).

## Bug Fixes
- Fixed the release workflow crate list typo so the crates array parses correctly (3f1fb5b).

---
**Version:** 1.1.2

Now Photo team can just ship the code. The AI handles the rest.

Workflows

For those who'd rather not assemble build blocks themselves - yes, we're that lazy - BuildSpace also ships pre-composed workflows that you can directly use in your own repo with simple configuration.

Rust Service Release

name: Release

on:
  push:
    branches: [main]

jobs:
  release:
    uses: photon-hq/buildspace/.github/workflows/rust-service-release.yaml@main
    permissions:
      contents: write
      pull-requests: read
    with:
      service-name: my-service
      binary-name: my-binary
      crates: '["crates/shared", "crates/client"]'
    secrets:
      OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
      CARGO_REGISTRY_TOKEN

name: Release

on:
  push:
    branches: [main]

jobs:
  release:
    uses: photon-hq/buildspace/.github/workflows/rust-service-release.yaml@main
    permissions:
      contents: write
      pull-requests: read
    with:
      service-name: my-service
      binary-name: my-binary
      crates: '["crates/shared", "crates/client"]'
    secrets:
      OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
      CARGO_REGISTRY_TOKEN

What happens:

1. The workflow will be triggered when you merge a PR with the release label.

2. AI determines the release version (e.g., 1.2.3).

3. AI generates release notes from your code changes.

4. Builds binaries for Linux, macOS, and Windows.

5. Syncs the version across all workspace crates.

6. Publishes to crates.io (dependencies first).

7. Creates a GitHub Release with attached binaries.

TypeScript Service Release

name: Release

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
    types: [opened, synchronize, labeled]

jobs:
  release:
    uses: photon-hq/buildspace/.github/workflows/typescript-service-release.yaml@main
    permissions:
      contents: write
      pull-requests: read
    with:
      service-name: my-package
      working-directory: "."
      build-command: "bun run build"
      npm-tag: latest
    secrets

name: Release

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
    types: [opened, synchronize, labeled]

jobs:
  release:
    uses: photon-hq/buildspace/.github/workflows/typescript-service-release.yaml@main
    permissions:
      contents: write
      pull-requests: read
    with:
      service-name: my-package
      working-directory: "."
      build-command: "bun run build"
      npm-tag: latest
    secrets

What happens:

1. The workflow will be triggered when you merge a PR with the release label.

2. AI determines version and generates notes.

3. Bumps package.json version and commits.

4. Creates GitHub Release.

5. Publishes to NPM registry with the specified tag.

What Changed

We built BuildSpace because we needed it. Here's what changed after adopting it internally.

We ship faster. Release cycles that used to take a full day now happen in minutes. Merge the PR, grab coffee, done.

Our clients actually read the release notes now. They've told us they appreciate knowing exactly what changed - no more cryptic commit dumps. Clear changelogs build trust.

The mental energy we used to spend on release logistics now goes toward building features. When you're moving fast, every bit of friction you eliminate compounds.

What's Next

BuildSpace is just getting started. The repo has room to grow far beyond releases.

Imagine the AI detects a breaking change in your code. It automatically notifies downstream consumers via Slack or email before they discover it the hard way. No more surprise breakages for your clients.

On the roadmap: more build blocks for additional languages and ecosystems. Integration with CI/CD platforms beyond GitHub Actions. Automated deprecation warnings and migration guides.

The goal is simple: let AI handle the tedious work at a quality level humans can't sustain, so you can focus on the code.

BuildSpace is open source. If you've got ideas for new build blocks or want to improve existing ones, we'd love your contributions. Open an issue, submit a PR, or just fork and experiment.

Less GitHub Actions. Less maintenance. Just Ship.

BuildSpace is built by Photon. Check out the repo to get started.