CUSTOM BROWSER GAMES FOR ONE AUDIENCE.

The client receives the commissioned game as a whole and a practical source handoff. The agreement states the precise legal form—often assignment, an exclusive license, or another structure suited to the project. We do not keep the finished game hostage to an ongoing service relationship.

We keep tools and know-how that were already ours: pre-existing code, general libraries, internal workflows, templates, and accumulated craft. We also keep generalized learning about how to make games well. That does not include the client’s confidential information, characters, history, data, custom art, or distinctive expression.

General techniques can enter our practice. If a project teaches us a better way to model a schedule, structure a decision, test a browser game, or write maintainable code, we will use that craft again. We do not copy the client’s world, proprietary content, private material, or recognizable expression into someone else’s game.

Only if the client wants it there and the agreement allows it. Private, internal, training, family, and community games can stay private.

Yes, as part of the production toolkit for coding, analysis, drafting, and iteration. The studio remains responsible for research, design judgment, testing, editing, and the delivered result. We do not treat confidential client material as public training content.

Yes. A source handoff and deployment notes are part of a commissioned delivery. We can also arrange hosting, but hosting is not required to keep using the game.

The game can be complete at launch. A Care Plan is optional for updates, small fixes, browser changes, and seasonal additions. There is no mandatory maintenance subscription.

Sometimes, with careful consent and clear limits. We will say no when simulation would trivialize harm, expose private material, or turn people into targets. A prototype can be a research instrument, but it is not permission by itself.

Each phase has named review points and one decision-maker on the client side. We show real browser builds early so feedback is about play, not imagined screens.

Then we stop with a useful answer. A prototype is allowed to disqualify a concept before the larger budget is committed.

Not as this practice. We build games with meaningful decisions, not points pasted over lead capture or manipulative engagement loops.

The target is keyboard and touch support, readable contrast, reduced-motion respect, no unnecessary permissions, and a browser link with no install. Exact requirements are named during scoping.

A typical standard game takes about twelve weeks. A focused prototype takes about three. Larger systems, research-heavy worlds, or seasonal content take longer.