Milestones are clearly defined deliverables or outcomes as part of a project. A “project” can be anything - for example, a custom AI system, a gameplay feature, or a technical tool. This “project” will then be split into multiple milestones, each representing a concrete step toward completion.

I take full responsibility for each milestone’s implementation, including planning, coding, and testing, so you don’t need to provide technical direction – the work is fully handled on my end.

Each milestone has a fixed scope and a fixed price. While a milestone is typically equivalent to roughly one focused development day (8 hours), it is not billed as a daily rate and not tied to a calendar schedule. This is backed by a formal work contract (Werkvertrag), so the price is tied to the deliverable, not the hours worked. Milestones are scheduled flexibly based on scope, availability, and project needs. Workshops operate the same way, with the schedule being flexible and not tied to consecutive days.

Once a milestone is agreed upon, the price stays the same – even if it ends up taking more time or effort than expected on my end.

For more information, see the Terms & Conditions for full contractual details.

It’s important to come prepared – but don’t worry, you don’t need a finished design document or a polished project plan. At minimum, it helps if you have a rough outline or notes about what you want to achieve. Think of it like homework: a starting point for our discussion.

Bring energy and an open mind, because I’m going to ask a lot of questions – and I mean a lot, down to the tiniest details. This ensures we’re on the same page and we know exactly what we want to create. The more prepared you are, the smoother the workshop will go and the more accurate the resulting project plan and pricing will be.

The workshop happens in writing, so every discussion and thought is documented. This ensures nothing is forgotten, provides a clear record for both of us, and makes it easier for me to review our conversation and plan the project accurately.

Remember: everything we discuss in the workshop directly impacts how I execute your project and how much it will cost. Taking a bit of time beforehand to think things through will save us both time and make the final outcome much stronger.

The license lets you use the work exclusively for one specific game project. That means only you get this license, no one else will be granted the same rights, and it covers the main game plus any DLCs, expansions, or updates tied to it. You’re free to modify and monetize the work within that project.

The license is perpetual (it doesn’t expire) and royalty-free, there are no renewals or ongoing payments required.

If you want to use the work in other projects, like sequels, ports, remasters, or new games, you’ll need to get a separate license and pay a reuse fee. This fee is 10% of the total you originally paid for the licensed work, reflecting that the new project will generate revenue and build upon the original work.

If you do want full rights to the work, that is also possible. In that case, the price would be 3× the base rate per milestone. For example, a single milestone would cost €1,770 instead of €590. If you start with a restricted license, you can upgrade later by paying only the difference between the restricted and full rights price.

This higher price reflects that transferring full rights removes my claim to any future revenue from the project, allowing you to freely monetize or extend it as you wish. It also prevents me from reusing general tools or solutions developed during the project, which are part of my business model and will impact efficiency and may impact revenue, since each project is complex and unique.

A restricted license is usually all you need because it’s exclusive to you and your project and only limited in scope. It’s also the more affordable option if your budget is tight. A full rights transfer would only be necessary, e.g., if you want to sell the work as an asset, sublicense it, or claim full ownership and use it however you like. If you don’t care about owning it outright, a restricted license is all you need.

Think of it a bit like leasing a car. You get to use it for your own trips (your project), and you can even use it to make money (commercial use). The only thing you can’t do is rent it out to others or sell it on to a dealership (that would be sublicensing or redistribution).

Full ownership, on the other hand, should be seen as an investment, not a necessity. Start with a restricted license to test and validate the work in your project. If it proves successful to the point where you can see the value of full ownership, upgrading to full rights allows you to invest in ownership with confidence only when it is truly worth it.

Beyond the voluntary warranty period I offer on top of the statutory 2-year warranty, I’ll be available at no extra charge for any questions or clarifications you have. I’m here to ensure everything works smoothly and that you feel confident using what I delivered. Support does not end when the project ends, and your project’s success matters to me.

The main reason is long-term reliability and support. I don’t own or control third-party tools, so I can’t guarantee they’ll stay compatible or supported throughout your project – especially by the time you launch your game. By minimizing their use, I help reduce technical debt, which is the potential future cost and extra work caused by choosing a quick, easy, or less robust solution now instead of a better, more sustainable approach, and avoid future headaches. It also means I can fully stand behind everything I build.

Another important factor is that most third-party tools and assets are designed for general use, not for the specific needs of your project. To support many different scenarios, they often include a large number of features you may never need. Those unused features still add complexity and can become a maintenance burden over time.

Engine updates and deprecated features can further complicate things. If a third-party tool relies on functionality that changes or is removed, you may be forced to update or replace it. Removing such tools is rarely trivial and can lead to cascading issues across your codebase. Even updating them can reintroduce features or behaviors you previously had to work around or remove.

By building focused, project-specific solutions, I keep systems lean, predictable, and easier to maintain over the long term.

For more detailed information on liability and third-party dependencies, you can review my Terms & Conditions.

Not by default. I avoid using experimental or beta features unless you specifically agree to it. Just like with third-party tools and dependencies, these features aren’t guaranteed to be stable, supported long-term, or even available in future engine versions.

If your project really needs something that’s experimental, I’ll discuss the risks with you first so you can make an informed decision. As always with such potentially risky elements, I elaborate further on this in my Terms & Conditions.

I process payments securely through Stripe and currently support:

• Credit & debit cards

• PayPal (EEA countries only)

• Digital wallets (Apple Pay, Google Pay, MobilePay)

• Klarna (available in most EEA countries)

• Alipay

• Link

• iDEAL

• Bancontact

• EPS

• TWINT

• Billie

• Bank transfer

Payments are generally always made upfront. In cases where budget or cash flow is limited, it is possible to split a milestone into two installments. A one-time 3% fee, based on that milestone’s total price, is added to the first installment for each milestone that is split.

I also accept PayPal, Klarna, and Billie, which allow you to pay in installments or defer payment.