Capability map / 06 streams
Game development company services tied to a real milestone.
Kioto supports internal studios with co-development, prototypes, engineering, art, QA and porting. The engagement is organized around what the next build must prove—not around a pre-packed menu of hours.
Find the ownership gap.
A discipline list is only the beginning. Each service page explains the production problem, useful outputs, fit signals and questions worth resolving before scope.
What can be known before an estimate?
A useful first conversation does not need a finished specification. It does need a target decision or milestone, a truthful account of the current build and access to the people who understand its constraints. Platform targets, engine and branch health, asset conditions, approval paths, security requirements and the expected hand-off all affect the shape of a credible plan.
When uncertainty is too high for a responsible production commitment, the right first scope may be an assessment or proof sprint. That work should produce evidence the team can use even if the larger engagement does not continue.
The method stays legible.
Different disciplines use different tools, but the contract between teams should remain visible.
Boundary
Named ownership, dependencies, exclusions and an accountable review path.
Proof
Acceptance criteria connected to observable build behaviour or production output.
Cadence
Reviewable increments that expose risk before it compounds into a milestone surprise.
Transfer
Source, context, known limits and maintainable ownership at the end of the stream.
How to scope external game development responsibly
Scope is not only a feature list. It is a production agreement about evidence, authority, dependencies and what happens when the build changes the answer.
Begin with the production outcome
“Add capacity” is a business need, but it does not tell a delivery team what to own. A stronger starting point names the outcome: a combat loop ready for a milestone review, a representative environment benchmark, a stable regression baseline, or a measured plan for a target platform. From that point, roles and tasks can be chosen because they contribute to the same result.
Separate known volume from open questions
Known volume can be estimated from specifications, samples and an agreed review path. Open questions need a different mechanism: technical assessment, prototype, benchmark or time-boxed discovery. Mixing the two usually produces a confident price with hidden assumptions. Keeping them visible lets the team commit firmly where evidence exists and create evidence where it does not.
Make dependencies part of the plan
External work still depends on internal decisions, build access, source assets, platform requirements and reviews from other disciplines. The scope should name those interfaces and the person accountable for each response. A schedule is credible only when the information and approvals it relies on have owners too.
Choose proof that matches the discipline
Gameplay can be reviewed in observable player behaviour and safe tuning surfaces. Art needs in-engine quality, source integrity and budget compliance. QA needs reproducible findings and a release-risk view. Porting needs representative hardware evidence. One generic “client approval” gate cannot describe all of those forms of completion.
Plan the end while the beginning is cheap
Decide which source, tools, build instructions, test evidence, asset provenance, configuration and known limitations must travel at hand-off. If the internal team will own the result, include the time it needs to review and operate that material. If the relationship may continue, define the decision gate for extension instead of allowing temporary work to become an indefinite dependency.
Bring enough context for a useful first response
A first brief can be short. Include the current production stage, the next external or internal review, target platforms, known engine and build conditions, the part of the work that is blocked, and the people available to review it. Mark assumptions as assumptions. A short, truthful description gives a studio more to work with than a long requirements document that hides uncertainty.
Also name any confidentiality, access or procurement step that can affect discovery. Constraints discussed early can shape a safer first scope instead of becoming avoidable delay after the delivery team is scheduled.
Not sure which service label fits?
Describe the production bottleneck. We can map it to a bounded first step without forcing the work into the wrong discipline.