Our Delivery Guarantee: How "Fix or Refund" Works in Practice

Every porting partner says they will deliver. It is the easiest promise in the industry to make, and one of the hardest to check before you sign.

The uncomfortable truth is that in most outsourced game development, delivery risk does not sit with the team doing the work. It sits with the client. When a date slips, the publisher moves the marketing plan. When a build ships with known issues, the studio takes the reviews. When a fix takes three weeks instead of three days, it is the game's launch window that pays for it - quietly, after the fact.

We decided to put that risk where it belongs. Our delivery guarantee is simple to say - fix or refund - and it is written into the agreement, not promised on a call. This article explains how it actually works: what triggers it, what happens in the first 24 hours, when a refund applies, and why the guarantee only means something because of everything we agree before the first line of code is touched.

What the guarantee actually promises

Let's start with the exact promise, because a guarantee is only useful if both sides read it the same way.

There are two kinds of trigger:

1. We miss what we agreed. The agreed scope is not delivered, or the agreed timeline is missed.
2. The launch goes badly for technical reasons. The release results in 15% or more negative technical reviews.

There are two possible outcomes:

1. We fix it. A dedicated hotfix team is assigned, with a guaranteed 24-hour response time, at no additional cost to you.
2. If we can't fix it, we refund it. No negotiation about whose fault it was, no "known issues" list, no extended back-and-forth.

That's the whole mechanism. In one table:

The rest of this article is about what makes it work - and what has to be true for a promise like this to be more than marketing.

Why a guarantee starts before the project does

A guarantee is only as good as the definition of "delivered". If nobody wrote down what the port includes, when it is due and what "done" means, then "we'll fix it or refund it" is unenforceable - every disagreement turns into a debate about what was promised.

That is why the guarantee is the last step of a process, not the first:

1. A free technical assessment. You send us the details of your game and the target platforms. Within 3 business days you get a first estimate, followed by a review of the repository before any commitment. We look at the engine, the build, third-party dependencies, input, saves, online features and platform requirements - the things that decide how hard a port really is. Our project scan makes that first look fast and thorough, and an engineer reviews every finding. (If you want to know what that kind of review usually covers, our technical due diligence entry is a good starting point.)

2. A fixed price for an agreed scope. The assessment turns into a written scope and a flat fee, agreed before we start and billed per milestone. We explained how that works in detail in our article on fixed-price porting.

3. A clear baseline. The scope is agreed against a known PC version of the game. If your game is still in development, that's fine - but then the planned PC work is part of the scope from the start, rather than something that surprises everyone in month three.

4. Written acceptance points. Milestones are tied to things that can be checked, not to feelings. That's what acceptance criteria are for: they turn "is it done?" into a yes or no.

Only once all of that exists does the guarantee have something solid to stand on. It protects you against us failing to deliver what we both signed - and because that is written down, there is very little room for interpretation later.

What happens when something goes wrong: step by step

Here is how the guarantee plays out in practice, from the moment a problem appears.

Step 1: The problem is visible early

Most delivery problems don't appear out of nowhere on release day. They show up as a milestone at risk, a certification issue that keeps coming back, a performance target that isn't moving. Because we work with transparent milestones, a fixed reporting schedule and weekly updates, you see those signals at the same time we do - not after the deadline.

That matters for the guarantee. The earlier a risk is visible, the cheaper it is to fix, and the less likely it is that the guarantee ever needs to be used.

Step 2: You flag it, or we do

If a milestone is missed, a part of the agreed scope isn't there, or the launch reviews turn negative for technical reasons, the guarantee is triggered. It doesn't have to be you who raises it - we're watching the same milestones and the same reviews.

Step 3: A dedicated hotfix team responds within 24 hours

This is the core of the promise. Within 24 hours, a dedicated hotfix team is on the problem. Not a ticket in a queue, not a "we'll look into it next sprint" - people assigned specifically to fixing it.

Crucially, it is our own in-house team: the same engineers and QA who built the port and already know the codebase. A post-launch bug report doesn't start with someone learning the project from scratch. It starts with people who know exactly where to look.

Step 4: The fix costs you nothing

The hotfix work under the guarantee comes at no additional cost. That includes the engineering, the testing on target hardware by our in-house QA team, and the work of getting the patch through the platform's submission process. Our team prepares submissions, works with platform holders and handles any resubmissions, so a fix doesn't stall because nobody owns the paperwork.

Step 5: If it can't be fixed, you get a refund

Sometimes the honest answer is that a problem can't be solved in a way that meets what we agreed. In that case, you don't get a long explanation and a discount on the next project. You get an instant refund.

We'd much rather never get to this step - and the way to make sure we don't is everything in steps 1 to 4.

An example, from flag to fix

To make this less abstract, here is how a typical case could play out. This is an illustrative scenario, not a specific project - but every step in it follows the process above.

The situation. A publisher has a PC game going to PlayStation 5, Xbox Series X|S and Nintendo Switch. The scope, the fixed price and the milestones were agreed after the technical assessment. Two weeks after launch on one of the platforms, the store reviews start to change: players report that the game crashes when they return to it after the console has been in sleep mode. Within days, a large share of the new reviews mention the crash.

Day 0 - the flag. The publisher's producer sends us the review summary. We've been watching the same reviews, and we already have crash reports from our own test devices that point in the same direction. The guarantee is triggered: the launch has drawn negative technical reviews, and the cause is technical - exactly the kind of problem a port is responsible for.

Within 24 hours - the team. A dedicated hotfix team is assigned: engineers who worked on the port and know how the game handles suspend and resume, plus QA who can reproduce the crash on real hardware. The producer gets a named contact and a first assessment of the cause.

The following days - the fix. The team reproduces the crash, fixes it, and runs regression tests to make sure the fix doesn't break something else - save data, controller reconnects, the other platforms. The patch goes through the platform's submission process, prepared and handled by our team.

The result. The patch goes live. The publisher pays nothing for the work - not for the engineering, not for the testing, not for the submission. And because the same team stays on post-launch support, any follow-up issue lands with people who already know the full history.

The other ending. If the team had found that the problem couldn't be fixed in a way that meets what we agreed, the next step wouldn't have been a long negotiation. It would have been a refund.

What makes this work isn't heroics. It's that every question that usually slows these situations down - is this in scope? who pays? who's on it? how fast? - was already answered in the agreement before the project started.

What "15%+ negative technical reviews" means

The review trigger is the part of the guarantee people ask about most, so it deserves a closer look.

The key word is technical. A port can't change whether players like a game's design, its story or its art style - those reviews belong to the game, not to the port. What a port is responsible for is how the game runs on the new platform: crashes, performance, broken controls, save problems, missing platform features. Those are the reviews the guarantee is about.

The threshold exists for a reason. A handful of negative reviews can happen to any release, on any platform. When 15% or more of the reviews point at technical problems, that's no longer noise - it's a signal that something in the port isn't right, and it's exactly the moment a fast, dedicated response makes the biggest difference to how a launch is remembered.

What the guarantee doesn't cover - and why that's fair

A guarantee that covered everything would cover nothing, because nobody could price it. Ours covers what we agreed to deliver. It doesn't turn changes to that agreement into "misses".

That means the following are not delivery failures - they're changes to the scope, and they get their own quote:

• new platforms added after the scope is agreed,
• DLC, new game modes, features or content,
• engine changes or major backend changes,
• substantial changes to the PC version after the baseline is agreed.

None of these are unusual. Games change, plans change, and sometimes a publisher decides halfway through that a fourth platform makes sense. When that happens, we quote it separately - and the new scope comes with its own price and timeline. The guarantee then applies to that agreed scope too.

The exact wording of all of this lives in your agreement, and we'd always rather walk you through it before you sign than argue about it afterwards.

Why we can afford to offer it

People sometimes ask whether a guarantee like this is risky for us. Honestly - it would be, if we worked differently. It's affordable because of how the rest of the process is built.

One team owns the whole scope. Engineering, optimization, QA and certification are handled by our in-house team. There is no subcontractor to point at when something breaks, which also means there is no gap where problems can hide. A guarantee only means something when the team behind it controls every part of the delivery - we wrote more about that in Any Game. Any Engine. Any Platform.

We know what we're getting into before we commit. The technical assessment and the scan happen before the price is fixed. The most expensive surprises in porting - a plugin with no console support, a save system built around one storefront, a certification requirement discovered at submission - are the ones we look for first. Many of them are on our list of the biggest mistakes we see in game ports.

Quality is checked continuously, not at the end. Our QA team handles functional, localization and compliance testing during the project, and regression testing catches breakage early. Certification readiness is tracked throughout, against the platform's certification requirements, instead of being discovered in the final week.

Post-launch support is already part of the deal. Every port includes three months of post-launch support at no extra cost, handled by the same team. The guarantee sits on top of that - it's the backstop for the cases where a launch goes wrong in a way normal support isn't enough for.

Put together, this means the guarantee rarely has to do anything. Its real job is to make sure everyone - including us - plans as if it might.

What it means for you

From a publisher's or studio's point of view, the guarantee changes three things.

Your budget risk becomes visible. With a fixed price and a guarantee behind it, the cost of the port is a number you can put in a plan. The scenario where a port quietly costs twice what was approved - because nobody owned the delays - is the one the guarantee is designed to remove.

Your launch risk has a response plan. If a launch goes wrong technically, you don't start by negotiating who pays for the fix. You already know: a dedicated team, within 24 hours, at no cost to you.

Your internal approval gets easier. Producers and business teams have to defend partner choices to boards and finance teams. "The agreement includes a fix-or-refund guarantee with a 24-hour response" is a much easier sentence to defend than "they said they're very reliable".

Questions to ask any partner about guarantees

Whether you work with us or with someone else, here are the questions I'd ask about any delivery promise:

• Is it in the contract? If the guarantee only exists in a pitch deck or on a call, it doesn't exist.
• What exactly triggers it? Missed dates, missing scope, post-launch technical problems - get the list.
• What happens in the first 24 hours? "We'll prioritise it" is not a response time.
• Who does the fixing? The same team that built the port, or whoever is free?
• Who pays for the fix - and what if it can't be fixed? A guarantee without a refund at the end is just a support plan.
• What changes the scope? You want that list before the project starts, not when the first disagreement happens.

If a partner can answer all six clearly and in writing, you're in good hands - whoever they are.

A guarantee you hopefully never use

The best outcome of a delivery guarantee is that nobody ever needs it. It works less like insurance you claim on and more like a discipline: it forces the scope to be clear, the price to be honest, the risks to be found early and the team to stay accountable from the first estimate to long after launch.

If you're planning a port and want to see what that looks like for your game, send us the details. You'll get a free technical assessment and a first estimate within 3 business days - and you can read the guarantee in the agreement before you sign anything.

Frequently Asked Questions

What is the LYNXBYTE GAMES delivery guarantee?

It's a written commitment in the agreement: if we miss the agreed scope or timeline, or the launch results in 15%+ negative technical reviews, we assign a dedicated hotfix team with a guaranteed 24-hour response time at no additional cost. If the problem can't be fixed, you get an instant refund.

Is the guarantee part of the contract?

Yes. It's written into the agreement, not promised verbally or only mentioned in a pitch.

What triggers the guarantee?

Missing the agreed scope or timeline, or a launch with 15% or more negative technical reviews - reviews about how the game runs, such as crashes, performance or broken controls, rather than opinions about its design.

How quickly do you respond?

A dedicated hotfix team responds within 24 hours, and the hotfix work is done at no additional cost.

When do I get a refund?

If the problem can't be fixed. In that case you get an instant refund instead of a discount or an extended negotiation.

What isn't covered by the guarantee?

Changes to the agreed scope, such as new platforms, DLC, new features or content, engine or major backend changes, or substantial PC changes after the baseline is agreed. Those are quoted separately, with their own price and timeline.

How does the guarantee relate to post-launch support?

Every port already includes three months of post-launch support at no extra cost, handled by the same team. The guarantee is an additional backstop on top of that support.