Terms of Service
This document establishes the mutual understanding required for any collaborative work. It outlines the boundaries, responsibilities, and protocols that ensure our projects remain focused and successful—treating every engagement as a curated artifact with defined dimensions.
Scope Definition
- 1 Clear deliverable specifications prevent scope creep
- 2 Milestone payments align with tangible progress
- 3 Revisions are scoped to protect project timelines
The Foundational Agreement
Engagement with Marklino.pro Studio begins with a signed Statement of Work (SOW). This document, complemented by this Terms of Service, forms the complete agreement. We operate on a milestone-based model. Payment schedules are tied to the delivery of specific, agreed-upon assets—code repositories, design files, or documentation.
Intellectual property for commissioned work is transferred upon final payment. This includes source code, design files, and any custom assets created for the project. Existing frameworks, libraries, or pre-built assets retain their original licensing terms, which will be clearly disclosed in the project proposal.
Confidentiality is paramount. Any project details, user data, or strategic information shared during collaboration remains under strict NDA. We do not use client project details in public case studies without explicit written permission, and any public-facing work is anonymized by default unless otherwise negotiated.
Operational Mechanics
Specific protocols that govern our day-to-day collaboration and delivery.
Revised Change Orders
Any request that significantly alters the original scope (beyond 10% of estimated time) will be documented in a Change Order. This includes new feature requests, art style overhauls, or platform additions. The Change Order outlines the additional work, cost, and timeline impact. Both parties must sign before work commences.
- Feature additions post-Kickoff: Requires new agreement.
- Minor polish iterations: Included up to 3 rounds per deliverable.
- Scope freeze 48 hours before each milestone review.
Example Scenario
Client: "Can we add a PvP mode to the core single-player gameplay?"
Process: This is a major scope shift. We will pause the current sprint, draft a Change Order with new estimates, and await sign-off before allocating resources.
Failure Modes & Calibration
Common friction points in indie game development and how our protocols are calibrated to mitigate them.
Ambiguous "Polish" Phase
Endless "final polish" loop where changes become subjective and scope inflates. One milestone becomes five.
Define "Done" with specific, checkable criteria: "UI scales to 3:4 and 16:9," "No texture pop-in on target devices." Polish rounds are capped at 3 per feature set.
Tech Stack Pivot
Mid-project switch from Unity to Unreal (or vice versa) due to a perceived feature gap, resetting all progress.
Tech stack selection is a Week-0 decision, locked in the SOW. We prototype the riskiest technical claim in the first 2 weeks before full commit.
Decision Paralysis
The "perfect" feature or art style is debated indefinitely, stalling momentum.
Use "B-Decision" philosophy: "Is this good enough to ship?" If yes, ship. Iterate post-launch based on real player data, not internal opinion.
Post-Mortem Amnesia
Successful project ends, but lessons learned are never documented, repeating mistakes in the next cycle.
A mandatory, one-page "Technical Post-Mortem" is delivered with the final files. It lists what worked, what broke, and what we'd do differently—becoming a living document.
Where to Start
These external resources inform our working agreement and are recommended for any project lead.
Ready to Define a Project?
Every great project begins with a clear agreement. Let's discuss your scope, timeline, and the protocols that will make it a success.
For Legal Inquiries
Marklino.pro Studio
Alexanderplatz 1
10178 Berlin, Germany
Phone: +49 30 12345678
Email: info@marklino.pro
Mon–Fri: 09:00–18:00 CET