Feedback pipelines
Ingest from every channel players use, deduplicate, and cluster into themes a person can act on without reading ten thousand messages.
A small studio where player feedback writes the next update.
Shiba Forever LLC is a micro studio. Players tell us what the game should be. Our harness turns that into working changes. A human reads every one before it ships.
1
live game, with players
100%
of changes human-reviewed
0
updates shipped unread
The loop
From what a player said to what a player plays.
Most studios treat player feedback as a research input: something read quarterly, argued about, and eventually turned into a roadmap. We treat it as the beginning of a build. The distance between a complaint and a patch is the thing we optimize.
-
01
Listen
Feedback is collected continuously from wherever players already are: in-game reports, store reviews, Discord, and session telemetry. It gets clustered by theme rather than by volume. A quiet signal from ten players who all quit at the same wall matters more than a loud one from a hundred who didn't.
-
02
Draft
The harness turns each cluster into a candidate change: a tuning pass, a reworked encounter, a new item, a bug fix. It writes the code, the content, and the test that demonstrates the change actually does what the feedback asked for. Nothing here is a suggestion document. Each draft is a real, runnable diff.
-
03
Review
A person reads every draft. We check three things: that the change is what players actually meant, that it fits the game we're trying to make, and that the test proving it is testing the right thing. Most drafts are rejected or sent back. That rejection rate is the point, not a failure of the system.
-
04
Ship
What survives review goes out as a real update, attributed back to the feedback that caused it. Players see their own words turn into patch notes, which reliably makes the next round of feedback sharper. The loop gets better because the players get better at using it.
Human review
Generated is not the same as shipped.
The automation writes changes. It does not decide that they are good. Every diff passes through a person who can reject it, and a test suite that runs before they ever see it.
We're specific about this because the failure mode is well known. A studio that lets a model ship directly to players gets volume, drift, and a game that slowly stops being about anything. The review step is what converts raw generation into an actual editorial position: a sense of which game we are making and which changes belong in it.
Automation earns us throughput. Review is what we spend it on.
The harness
Most of our engineering isn't game code.
The majority of the team's time goes into the harness: the tooling that lets a small team operate a live game the way a much larger one would. It is the studio's real product. The games are what it produces.
Evaluation suites
Tell us whether a generated change is good before a player sees it. Without this, review becomes the bottleneck and the whole loop stalls.
Automated playtesting
Environments that play the game far faster than humans can, so balance and progression regressions surface in minutes rather than after launch.
Review surfaces
One screen showing a change, the feedback that caused it, and its test results, so approving or rejecting takes minutes instead of an afternoon.
Release automation
Approved changes go out, get attributed to their source reports, and are watched for the signal that they worked, closing the loop back to step one.
Guardrails
Hard constraints the automation cannot cross on its own: economy limits, content boundaries, anything touching player data or money.
The studio
Small on purpose, and staying that way.
By micro studio we mean genuinely small. There is no bench of contractors waiting in the wings, no plan to become a hundred-person shop, no org chart waiting to be filled in. Small is a constraint we chose and intend to keep.
It's a useful constraint because it's unforgiving. Every process has to survive being run by one person on an ordinary Tuesday. Anything that only works with a dedicated owner, whether a triage rotation, a live-ops team, or a QA department, either gets built into the harness or doesn't exist. That forcing function is why the tooling is good.
It also keeps the loop honest. When the same people read the feedback, review the changes, and answer for the release, nothing gets lost in a handoff.
Work
We acquired Shiba Story Go, our first game.
Shiba Forever LLC has acquired the IP for Shiba Story Go, a free-to-play roguelite idle RPG on iOS and Android. You play a brave and slightly chaotic Shiba Inu through short, replayable runs shaped by branching choices, collectible gear, pets and mounts, and guild raids.
We chose it because it already has an active player base. Everything on this page depends on a steady supply of real feedback from people actually playing, and a live game supplies that from day one. A game we had just launched into an empty room would not.
So the loop starts with players who are already telling us what they want. That is the whole reason this is the right first title to run it on.
Shiba Story Go
Free to play on iOS and Android
Company
Shiba Forever LLC
Shiba Forever LLC is an independent game studio. We own, operate, and update Shiba Story Go, a free-to-play roguelite idle RPG available worldwide on iOS and Android. Our own engineering work is the harness described above: the feedback, evaluation, testing, and release tooling that lets a small team run a live game.
- Legal entity
- Shiba Forever LLC
- Founded
- July 2026
- Headquarters
-
8 The Green, Suite B
Dover, DE 19901
United States - Industry
- Mobile games, live operations, applied AI tooling
- Product
- Shiba Story Go, a roguelite idle RPG on iOS and Android
- Business model
- Free to play, with optional in-app purchases
- Contact
- hello@shibastorygo.com
- Policies
- Privacy Policy and Terms of Service