Skip to content
PWR
← Showcase

Engineering case study · 2026-11-11

Prism Drop: a browser game from one sentence, on staging

The first build run end to end on PWR's staging environment: a Producer conversation, an approved plan, a team of agents, QA rejections and repairs, independent review, a delivered game and a feedback revision. Recorded in full, including the defects it exposed.

PWR Studio during the Prism Drop build: the customer's request, the Producer's replies, and a progress panel showing the team that was assembled and the spending so far.
PWR Studio on staging while the build was running. Unedited screenshot, cropped.

The task

Build me an original colorful browser-based peg-and-ball arcade game with satisfying physics, scoring, multiple levels and a playable preview.

What this run verified

  • A Producer conversation produced a specification and a plan, and revised the plan when the customer asked for a smaller first version.
  • The project and its workspace were created without a repository or a GitHub connection.
  • Approval required a spending limit, and a second organization could neither start nor approve this goal.
  • Implementation ran in the container sandbox; QA rejected work four times and it was repaired.
  • An independent reviewer checked each task, and a headless browser check passed at desktop and mobile sizes.
  • One feedback message became one follow-up task, which was implemented, checked and delivered.
  • Asked later how the game was coming along, the Producer answered from the project's records, and the answer matched them on all but one figure.

What it did not verify

  • The live preview inside Studio. The game was opened from the delivered files in a local browser.
  • Anything about general reliability: this is one run of one small game on a staging deployment.
  • Payment. The run was funded by a test allowance, not by a customer's plan or credits.
  • Whether the game is good. The checks were automated; nobody judged how it plays.
  • The cost against the provider's own bill. The recorded figure is about 18% under the list-price recomputation.

The numbers

Environment
PWR staging, a disposable test organization, a test allowance
Approved plan
Version 2: 2 milestones, 4 tasks
Spending limit approved
$9.00
Team assembled
Producer, Architect, Game specialist, QA, Independent Reviewer
Agent runs for the first build
27 (Producer 5, Architect 1, Game specialist 8, QA 9, Reviewer 4)
Findings
15 by QA and 6 by review; none left open
Start to delivery approval
About 12 minutes
Recorded cost of the first build
$2.11, including the planning conversation
Same usage at provider list prices
About $2.50
Delivered
19 files, 38 KB: source and a static bundle
Feedback revision
1 follow-up task, 6 runs, $0.90 recorded including two status answers; 22 files delivered

Source: the platform's own record of the run (docs/acceptance/evidence/2026-11-11-first-autonomous-build/ and docs/acceptance/evidence/2026-11-11-feedback-revision/ (README.md, conversation.md, browser-qa.json)).

What happened

  1. Request and plan

    One sentence from the customer. The Producer wrote a specification and a plan for a game it named Prism Drop, built on plain Canvas 2D because that is what PWR can build and test here.

  2. A smaller plan

    The customer asked for three levels and no sound or particle effects. The Producer cut the plan to 2 milestones and 4 tasks and said plainly that it had no measured history to estimate a cost from, so the limit would be the ceiling.

  3. Build

    The Architect recorded 8 technical decisions. The Game specialist implemented the four tasks in 8 runs inside the container sandbox.

  4. QA and review

    QA ran 9 times, rejecting one task once and another three times. The Independent Reviewer ran 4 times and left no blocking finding.

  5. Escalation

    The Producer had written a criterion for one task that only the later browser check could satisfy. QA spent three cycles on it before PWR escalated to the customer.

  6. Delivery

    The browser check passed, the customer accepted, and the work was committed to the managed repository.

  7. Revision

    Feedback asked for a snappier ball, a hit effect, a better score display and the right title everywhere. The Producer found the wrong title itself, noted that the hit effect reversed the earlier 'no particle effects' instruction, and planned one task. It passed QA and review in one cycle.

  8. What the run got wrong

    The delivered game's title screen said 'Peg Arcade' rather than 'Prism Drop' until the revision. The result panel said nobody had opened the build in a browser although the browser check had passed. The first status answer missed the follow-up work; that was fixed and the second answer was correct.

Screenshots

The customer's request for a smaller first version, the Producer's revised proposal, and the plan card showing the technology, 2 milestones and 4 tasks, and that there is no cost estimate, only the customer's limit.
The revised plan awaiting approval.
The project board with four task cards: three ready and one in progress, each assigned to the Gameplay Engineer.
The four tasks on the board during the build.
The delivered goal in PWR Studio: 4 of 4 tasks done, 2 of 2 milestones, and $2.11 of $9.00 used.
The delivered goal, with the spending against the approved limit.
The follow-up goal in PWR Studio, delivered, with the activity log of QA, browser check and delivery, and $0.36 used.
The feedback revision, delivered.
The first delivered build of Prism Drop: rows of coloured pegs, a launcher, a score of 115 and a combo multiplier.
The first delivered build.
The revised build of Prism Drop, showing the hit effect on pegs and the larger score display.
After the feedback revision.

Where a person stepped in

The result

The game was delivered into a private staging workspace, so there is no public link to play it yet. The screenshots above are of the delivered files.