Riddim Software Factory
How a request becomes shipped code at Riddim Software Factory.
Read the seven stations. Each one leaves a receipt.
Intake → Scope → Dispatch → Build → Review → Release candidate → Shipped
Worked example
Follow an active work order through every station.
Today's active work order is WEB-122 · epac public roadmap ledger. Each station below traces exactly what happened to that request.
Intake
request · epac-roadmap-001
A public feature request enters the factory. For this work order, users of epac asked for a public roadmap ledger — a transparent view of features currently in progress. The epac roadmap tool captures the raw signal with its original wording, support count, and submission date intact. The product owner reviews the signal against the current backlog and decides it has enough support and clear scope to enter the line. The raw signal exits this station as request · epac-roadmap-001: the first artifact in the chain.
Scope
linear · WEB-122
The validated signal enters Linear, which turns it into a bounded work item. Acceptance criteria, scope limits, risk notes, and a stop condition are written here before any agent runs. The Linear issue structure means the developer bot receives an unambiguous specification, not an open-ended request. Every downstream station — dispatch, build, review — builds against this contract. The scoped issue exits as linear · WEB-122. If the scope is wrong, this station is where to fix it.
Dispatch
symphony · run-epac-001
Symphony reads the Linear issue and starts an agent session. It selects the complexity tier, assigns the Claude model, provisions an isolated git worktree, and passes the issue spec to the developer bot as a start signal. The developer bot has no session memory — it reads the issue cold, with no context from prior runs. Symphony tracks the session and will relay review feedback or blockers back to Linear when the run ends. The dispatch record exits as symphony · run-epac-001.
Build
github · PR-421
Developer-bot — an autonomous agent running on Gas City, Riddim's agentic infrastructure — reads the issue spec and writes the implementation. It explores the codebase, writes code, runs the project's validator, and opens a pull request with its own commits, a CI run, and a transcript excerpt. The pull request is a reviewable artifact: any human can read the diff and inspect the evidence. The developer bot does not approve its own work. The PR exits as github · PR-421.
Review
ci · build-128
Reviewer-bot — a separate autonomous agent, not developer-bot — reads the pull request diff against the Linear acceptance criteria, runs the test suite, and either requests changes or approves the merge. The two agents do not share session state, so the review is a genuine independent pass. When the review passes, GitHub's automerge fires. Reviewer-bot posts a single consolidated review comment with its reasoning visible to any human who reads the PR. The review exit artifact is ci · build-128.
Release candidate
appstoreconnect · build-128
After the PR merges, the CI/CD pipeline on Gas City builds the app binary, signs it, and submits it to TestFlight. No release has happened yet — this station produces a prepared, internally-testable package. A human can install the build from TestFlight, verify the feature end-to-end, and confirm the build is ready for App Store Review. The release candidate exits this station as appstoreconnect · build-128: a signed build waiting at the gate.
Shipped
appstore · epac-current
The App Store release is a human decision. After the TestFlight build passes App Store Review, a human approves the release through App Store Connect. The release-gate state is human, on purpose. Once approved, the update reaches epac users and the App Store listing reflects the new version. The final artifact links back to the signal that entered at Intake: appstore · epac-current. Every station has left its receipt; the full chain is now readable.
The human gate
Why the App Store release stays human.
The autonomous pipeline runs from signal intake through code review, CI, and TestFlight submission without human action. The final distribution step — approving an App Store release — stays with a human who can see the complete picture: TestFlight feedback, support trends, and what else is in flight for the same app.
The release-gate state is human, on purpose.
App Store releases reach real users on real devices. Keeping the release gate human means one person reviews the full context before an update ships. This isn't a technical limitation of the pipeline — it's a deliberate choice about where autonomous execution stops and human judgment takes over.
Not agency work
The factory builds Riddim's own products, not client deliverables.
Riddim Software builds, ships, and operates its own products — epac, Sonnio, Reach, and the rest of the catalog. The factory runs to deliver software Riddim owns. There are no outside engagements, no client deliverables, and no consulting arrangements. The pipeline exists because Riddim needed a repeatable way to deliver its own products at a consistent cadence. If you are looking for a shop to build something for you, this is not that.
See it live
The floor is running now.
Watch the current work order move through stations in real time, or follow a completed order from signal to receipt.