Own-business case study · Reaction Racing
From a product issue to a reviewable release.
Reaction Racing is a reaction-based racing game. Its development work is coordinated through a custom dashboard that links incoming requests, development cycles, agent execution, testing and owner decisions.
A working example from OCI founder Philippe Theunissen’s own business. The implemented workflow shows how an agentic development team can work inside a process that management can inspect and steer.
- Project: Reaction Racing
- Focus: product development and maintenance
- Status: deployed workflow, continuing development
The implemented operating model
The work moves. You steer.
A simplified diagram of the workflow—not a live dashboard or a performance chart.
- 01
Capture
Record a bug, feature or maintenance issue with its context.
ManagementChoose what matters for the product.
- 02
Initiate
Place the request in a development cycle with a retained scope.
ManagementStart the work and resolve priorities.
- 03
Implement
Agents inspect, build, check and report progress against the request.
ManagementReview genuine blockers or product choices.
- 04
Test
Provide the exact candidate and preserve the test attempt and feedback.
ManagementAccept the result or request rework.
- 05
Deliver
Keep target-specific release and verification evidence linked to the work.
ManagementConfirm release scope and direct the next cycle.
The operational challenge
A game evolves through feedback, bugs, improvements and releases across connected systems. The coordination problem is keeping the original request, implementation, test candidate and owner feedback together. Adding more coding prompts does not solve that handoff.
What was built
The dashboard has dedicated Inbox, Backlog, Cycles, Testing and Releases areas. Requests retain stable identities and their revision history. Work cycles connect selected requests to agent implementation and progress reports. Testing records point to exact candidates, with retained feedback when the owner asks for rework.
- A structured intake for product requests and issue reports.
- Development cycles with visible progress and a retained work history.
- Testing and release records distinct from implementation status.
What this changes in practice
Management has a place to initiate work, inspect progress and test the delivered result. Agents can work from the recorded request and report evidence back to the same process. When feedback arrives, it remains attached to the work rather than becoming an isolated chat instruction.
Where people still lead
The owner sets product priorities and makes acceptance or rework decisions. Tests, deployment receipts and live verification are evidence; they are not substitutes for a product decision. Web, backend and native delivery can have different release paths. This case describes the implemented development workflow, not a claim that the entire game business is autonomous.
What we can substantiate
The published product and dashboard implementation demonstrate a connected development process. We are not publishing an audited time-saving percentage, revenue uplift or return-on-investment figure. A future measured comparison should track accepted cycle time, rework and production defects against a documented baseline.