A build loop means the people funding your work play your current build rather than watching a trailer. On PowerHub a backer with a paid pledge opens the latest build, leaves written feedback and a score, and it reaches you directly. Run it on a fixed day and a funding round becomes a standing playtest.
Ship something rough, on a day you keep
Pick a day and hold it. Friday works for most teams because the people playing have a weekend, and you have Monday to read what they said.
What goes out does not need to be presentable. Rough is fine, untextured is fine, one broken menu is fine if you say so. What is not fine is a build that cannot be started, because a backer who fails to launch it once will not try the next one. Test the link on a device that is not yours before you send it.
Ask one question per build
"What did you think" produces nothing usable. One specific question produces a stack of comparable answers:
Does level three read as unfair or just hard?
Did the touch controls feel right on your device, and which device?
Where did you stop, and what were you trying to do at that moment?
Put the question in the update that goes out with the build, not only on the campaign page. People answer the question in front of them.
The harsh feedback is the useful feedback, and you only get it from people who feel like participants rather than customers. Asking a narrow question is what makes that possible.
Read everything, and reply to most of it
Feedback on a build goes to you and to our operators, and it is attached to the campaign so it stays with the project rather than scattering across a chat server. Read all of it, including the entry that is one line and annoyed.
Reply to as much as you can, briefly. "Fixing this" is a complete reply. Playtesters who see their feedback reflected in an update turn into the people who bring you the next twenty, and playtesters whose notes disappear into silence stop writing them after the second build.
Change one thing, and say that you did
The loop only pays for itself if it closes. Each week, pick the change most clearly indicated by what came back, make it, and name it in the next update: this is what you told us, this is what changed.
One visible change beats five invisible ones. It is also the single best argument your campaign page can make to a reader who has not backed it yet, because it shows the loop working rather than describing it.
Decide what goes in the build, and what waits
A build that changes everything at once teaches you nothing, because you cannot attribute anything that comes back. Send the smallest change you actually want an opinion on, plus whatever else happened to land that week.
Two things are worth holding back. Anything half-implemented enough that every single person will report the same obvious bug, because that week's feedback becomes one note repeated twenty times. And anything you have already decided to change, because asking about it spends attention you will want next week.
Use the rating for the trend, not for the week
Campaigns carry a one-to-ten score, and an average only appears once enough people have given one. With a small group, one week's average is noise. The trend across a month, read next to what you changed, is not.
If the score moves after a specific change, that is worth knowing. If you cannot explain a move, ask about it in the next build's question rather than guessing.
Publish what the loop produced
Once a month, write up the loop itself rather than the build: how many people played, what the three most common notes were, what changed because of them, and what you decided not to change and why. That last part matters more than it looks, because a creator who explains a refusal reads as someone making decisions rather than taking orders.
It is also the most persuasive thing on your campaign page for somebody who has not backed it yet. A description of a feedback loop is a claim; a month of it, with the notes and the changes next to each other, is evidence.
Keep the cadence in the weeks when the build is bad
The temptation is to skip the week where nothing landed. Skipping is what ends the loop, because the cadence is the thing people trust, not any individual build.
Send it anyway, say what state it is in, and ask a smaller question. A week where the honest update is "this was a refactor, nothing visible changed, here is what is next" is a perfectly good update, and a campaign that goes quiet is one we may pause.
Questions
What if I have five backers?
Five people who have played the actual build will tell you more than a hundred store-page visitors. Run the same loop. The method does not change with the number, and the number tends to grow when the loop is visible.
Do I have to promise a build every week?
No, and it is better not to. PowerHub does not promise anything on a creator's behalf, and neither should your campaign page. Describe the cadence you intend to keep, and if a week slips, say so in an update.
Who can open the build?
Only people with a paid pledge on the campaign, plus you and our operators. It is not on the public campaign page, which is the point: the build is for the people funding the work. Setting the campaign up in the first place is covered in how to fund your studio's AI budget on PowerHub.
A pledge is a contribution to a creator's AI budget. It is not an investment, a purchase, a loan or a donation, and it buys no product.
