What developers should bring to a publishing conversation—and what to ask in return

Start with the experience, then the evidence

Indovia’s website invites developers to submit a prototype or a live game. That gives the conversation a concrete starting point: something that can be played, understood and discussed. Indovia company overview

For a prototype, explain the core action and the feeling it is designed to create. What does the player do repeatedly? How does the challenge develop? What is already represented in the build, and what is still an intention?

For a live game, separate measured behaviour from estimates. Describe the period covered, the audience included and measurement limitations. A small but clearly explained dataset is more useful than a large number whose meaning is uncertain.

Bring the question you cannot yet answer

A submission becomes more distinctive when it contains a specific problem. Perhaps the team is unsure how to communicate the mechanic. Perhaps players respond well to the opening but progress unevenly later. Perhaps an expansion opportunity exists, but the team lacks a reliable way to evaluate it.

These are illustrative situations, not claims about current submissions to Indovia. They show how a conversation can move toward a question that a publisher and developer can work on together.

It is equally useful to explain constraints. What can the team change quickly? What requires a larger development cycle? Which assets and data are available? Which aspects of the experience are central to the game’s identity?

Ask how decisions will be made

The developer should be able to ask what the next stage involves. What evidence will be reviewed? Who is responsible for the next action? How will the team distinguish a product question from an acquisition question? What happens if the evidence is mixed?

Commercial and ownership questions deserve explicit discussion in the eventual agreement. This article does not describe standard Indovia contract terms or promise a particular structure. Its practical point is that a working relationship should be understandable before either side assumes the other is responsible for a decision.

A useful outcome can be a clearer next step

Not every first conversation needs to end with a deal. It can establish that the build needs a clearer demonstration, that a measurement gap must be addressed, or that the two sides are asking different questions. Those are useful outcomes when explained plainly.

A developer-friendly publishing story should make this work visible. It should explain what the publisher is looking at and why, without unsupported promises about performance or speed.

For Indovia, this is an opportunity to communicate the company through the quality of its questions. Bring the game, explain the experience you are building and identify the decision you most want help making. The next conversation can then begin with substance.