Avoiding revision hell

Originally written: 2026.09.13

You’ve finished the client’s revision request and are ready to send it off. A drop of sweat hits your desk. “This time will be different,” you think, as you press the send button. The file named “revision_20” flies through cyberspace. A few minutes later you receive a reply. Another drop hits your desk. But it’s not sweat this time. It’s a tear. The message reads: “I can’t put my finger on it, but it’s not quite there yet. Can you try something else?”

When you work on other people’s projects, no matter whether they are unpaid hobby projects or paid commercial ones, you will likely be asked every now and then to revise your work. And this is completely normal. But an unreasonable amount of revisions can have a negative impact on your mental health, the completion of the project, and future collaborations with the client. In the worst case scenario, you will be trapped in a seemingly endless revision loop: revision hell.

I have experienced revision hell in the past and I’m of course not the only one. I’ll quote excerpts from Aaron Marks’ Complete Guide to Game Audio, who did not only share his personal stories, but also interviewed other game audio professionals. This way I hope to show you that these issues and possible solutions affect and are relevant to all kinds of people working in the industry.

While this guide was written from the perspective of a composer, I’m sure that other creatives can benefit from it as well. Revision hell is something that can occur in many different roles and the tips below apply to creative work in general. It can also help project leads/clients gain realistic expectations towards staff and make the collaboration process smoother.

Set a maximum number of (free) revision

This tip might be the most obvious solution to revision hell. A reasonable maximum number could be two or three (free) revisions, but it’s really up to you. If you’re part of a commercial project, then you could charge for any additional revisions after the free ones are used up. You can calculate your upcharge by multiplying your (theoretical, if you charge per product) hourly rate with an estimate of how many hours the revision is likely to take. Or you could work out a flat sum for all extra revisions beforehand. If the requested revision is very minor, you could also make an exception and do it for free as a favor. This could improve your relationship with the client and they might be more likely to hire you again. But there’s also a risk of them exploiting your generosity in the future. Either way, it’s important to let your clients know about this rule beforehand and put the details into a contract if any money is involved.

One upside of setting a maximum number of (free) revisions is that the client will be disincentivized from asking for unnecessary changes. They will think harder about what revisions are actually important. There are clients out there who are unsure about how they want a track to be revised and whose feedback amounts to a vague ‘try something else.’ There might also be clients who just want to hear many different alternatives to have more choices to pick from or who have an overly specific image of the music in mind that they want realized. By following this tip, you’ll be able to better protect yourself against an endless barrage of revision requests (or at least get paid for your time).

Pasi Pitkanen: “Limit the amount of free revisions that the client can ask for the audio content. If they go past that amount, then you can set a separate fee for the following revisions. I always include this in my contracts because it protects me from the revision chaos that might happen in a project.”¹

Bradley Meyer: “If there isn’t already a working relationship with a client, I may add a line in my contract limiting the number of revisions for a delivered sound without further payment to prevent being taken advantage of. You always want to keep your client(s) happy, but you should be mindful of doing so at the expense of your quality of life.”²

Reduce cooks

What’s harder than pleasing one person? Pleasing two, three, or even more. The title of this tip is a reference to the saying ‘too many cooks spoil the broth,’ meaning if too many people share a task (deciding how the music should sound in this case) the result will be worse. You might even get conflicting feedback. Depending on the hierarchical make-up of the team, you might have a say in how the music approval pipeline should work. In that case, you could discuss who the best person to handle the music feedback is (for example the project lead or the audio director).

Other teams might want to pool together the feedback of multiple people, especially in small and tight-knit teams. To make it more manageable, one person could be chosen as the focal point for the audio feedback and this person has the final say over what requests are valid and how to resolve conflicting requests before the filtered feedback is forwarded to you.

Sometimes it also helps to find the person who has the final say (the chef cook, so to speak) and include them in the feedback loop. In his Complete Guide to Game Audio, Marks tells a story about a situation just like this. The producer kept sending him revision requests without really explaining why. In the end it was the very first batch of sounds he made that was picked for the game, not the revisions. Turns out that it wasn’t even the producer who had the final say but the producer’s boss and he was the one who ended up picking the first batch.³ This tip is more about finding the right cook, but you’re indirectly reducing the amount of cooks by filtering out those who have less or even no say over how the music should sound in the end. And if you loop them in from the start, then you’re potentially less likely to receive additional revision requests: “If they get the sense you are working hard, they’ll feel they are getting their money’s worth and are more apt to use sounds and music you’ve submitted instead of having you redo them.”⁴

Aaron Walz (answering the question “Have you ever had any development issues negatively influence your workflow?”): “Lord yes. When the whole studio staff critiques your sounds, and they all offer contrasting feedback and then wait for you to defend yourself.”⁵

Establish trust

Trust goes both ways. You should be able to trust the vision of the one in charge of the project. They will oftentimes have a more complete picture of the final product and have a better overview of all parts that make up the project. Putting trust in them means trusting that their decision will improve the quality of the whole. Marks explains that you should “[d]iscuss their interpretation of the music they feel would enhance the game. It may seem rather odd, you being the composer and all, but asking them will only clarify your musical direction. Remember, they’ve been living with this game for several months, and I’m sure the subject has already come up among themselves.”⁶

But people aren’t perfect. There are those those that don’t make choices based on how much it will improve the project, but based on personal preferences. They might want to see an image that they have in mind realized without being able to explain why they want something to be a specific way. Marks suggests that “[i]n times like this, you need to remind the producers that, while you can appreciate their personal tastes in music, the project definitely calls for a particular style. Help steer them back on the path of what is best for the project.”⁷

When someone wants to work together with you they, at least in theory, should have enough trust in your expertise. If they question your every decision, then this prerequisite was not met. To these kinds of clients, Marks suggests the following: “I don’t recommend telling them [the composer] exactly what to play and how to play it. Unless your musical background is substantial, this will not guarantee their best work. But, if you point them in the right direction and trust their expertise and musical judgment, the results will be dramatic.”⁸ Following this, you, the composer, could explain to your client that you might be able to produce better results if they put more trust in your expertise. Perhaps that client will start seeing why trust is so important if they’re aware that it might lead to a better product and that micromanagement may lead to a worse one.

Jon Holland: “I also want to make sure they trust me enough to let me do my job so I don’t have to waste time redoing things.”⁹

Make sure you have all the important information

On one hand, the client has the responsibility to give you all the important information about the kind of music they want beforehand. On the other hand, you are the one who has audio production expertise and as such could have a better feel for what additional information is necessary. They might, for example, ask for metal, but not know that there are tons of distinct subgenres. Or they might ask for music fit for a medieval setting and then be surprised when you make something inspired by Gregorian chants while they were thinking of something that sounds like a Bach choral (who didn’t even live in the Middle Ages, making you all the more confused). Marks explains that “[w]hat means one thing to one person could mean something completely different to another, even if the exact same description was given. […] [D]on’t be afraid to ask as many questions as possible to ensure you pinpoint what the client wants.”¹⁰

Reference pieces can help, but it’s also important to ask what parts of the reference piece are relevant and what parts are irrelevant to their request. Otherwise you might end up focusing on the wrong aspects. Marks recounts a negative experience that stemmed from exactly this kind of misunderstanding: “I used the same instrumentation, almost the same beat and tempo, and thought I’d matched their idea fairly well. Turns out, it wasn’t any of those elements they were looking for. They liked the distortion patch on the electric guitar and wanted me to focus on that! Aaahh!!! Funny, there was absolutely no discussion about that.”¹¹

But the client might also want to deliberately give you a lot of freedom. Maybe it doesn’t matter to them which metal subgenre you pick, or if it sounds like a Gregorian chant or a Bach choral. They trust you to make the right decision that benefits the project most (see “Establish trust”). But to make sure, you can always just ask them whether the details matter to them.

Figuring out what the final piece should sound like can also be a collaborative process. Clients might have ideas that you can’t realize either because it’s generally very difficult or because you personally lack the means. Or maybe it’s the exact opposite and you have resources that the client did not know about (you actually regularly sing in a choir that performs Gregorian chants, so you can easily record some Gregorian chanting, for example). Also make sure that the information you have is up-to-date. If there’s a gap between the time when you received the information for a specific piece and the time when you start working on the piece, then there’s a chance that things might have changed and they forgot to tell you.

Keth Arem: “Some clients have preconceived ideas of how things should be accomplished, while others may have a concept for a sound, but no tangible example to reference. Sometimes these ideas don’t always translate into the real world, so it’s important that they understand what is feasible or sonically possible. I spend much of the early time on a project understanding and listening to the client’s goals, and then helping to educate them on how we can both achieve those goals.”¹²

Aaron Marks: “At our initial creative meeting, we had discussed the personality of a particular character and all seemed to be in agreement. I received the scripts for the rather long narratives, hired the voice talent, and spent 2 days in the studio recording and editing the sequences. I was very happy with our work and sent it off to the developer. I received a phone call after the producer had heard the recordings saying they had changed this dark, evil character to a more mystical, less intimidating one instead. ‘I thought you knew,’ was the chilling statement I received.”

Make sure you know what the revision request is actually about

This tip ties back to “Make sure you have all the important information,” so I will keep it short. Sometimes you might get vague revision requests or ones that are easy to misunderstand. What could ‘adding more action’ mean, for example? Adding more drums? Do they want another E-guitar layer? Or do they just want you to increase the tempo? The safest way to be sure is to ask them.

Get feedback early

In an ideal world you would always know what the client wants and create a product that matches their needs perfectly on the first try. But misunderstandings can always happen, even if you’ve made sure that you have all the important information. To minimize your potential workload, you can get feedback early in the composition process. Send a client the first 30–60 seconds as a draft instead of sending them the full piece. If they approve it, then great. The chance that the rest of the draft will also go in the right direction is high. If they find that something is fundamentally wrong with it, you will have to revise less and can work on the rest of the piece while taking the revision request into account. But keep in mind that sending drafts that are too rough around the edges can be a risk.

Aaron Walz: “Be really careful about sending rough drafts and sketches. Some developers will not understand unpolished versions of things or be able to imagine the finished product based on sketches. They can be useful, but have made me lost gigs.”¹³

You can minimize this problem by making very clear that you’re sending a rough draft, what parts you need feedback on (you likely won’t want mixing and mastering feedback yet, for example), and what the next steps could be if the draft is approved. Or, and this is what I prefer doing, you could make it a draft in length only. That would mean making these first 30 seconds polished enough to give a clearer picture of how the finished track might sound.

Present alternatives

Sometimes you are asked to create multiple alternatives of a track by a client. Marks identifies these clients as the “hands on” type: “You’ll create many musical ‘sketches,’ letting them choose which ones are closest to their vision. Once they’ve approved them, you’ll flesh them out to their final versions”.¹⁴ This is quite similar to getting feedback early. But there might also be cases where you will want to present alternatives on your own accord. You might come up with multiple variations of a track that could fit the project. Maybe you’ve tried both, a saxophone and a concert flute as the lead instrument, and they both sound great. Or you want to quickly draft several ideas that could help clarify what the client actually wants.

Giving your client a choice also has a psychological effect. On one hand you have the “choice-induced preference change” which states that “actions or items seem to acquire value simply because one has chosen them.”¹⁵ On the other hand you have “choice overload” which states that “choices from larger assortments can lead to disconfirmation of consumer expectations, resulting in greater choice deferral and lower satisfaction with the chosen option.”¹⁶ Though, the quoted meta study also found that if the amount of options is overall smaller, choice overload becomes less likely.¹⁷ So, as long as you give your client a few options instead of a dozen, you should be fine. I would not recommend using psychological tricks on your clients, but asking people to choose between alternatives can actively help clarify the direction that fits the project best, which can reduce revisions later down the line (and the “choice-induced preference change” is just a nice bonus).

Keep backups of prior versions

It’s always possible that a client will want to return to a previous version. Maybe they’ve changed their mind or they’ve realized that no revisions were necessary after all. Or it turns out that the head chef prefers the first version and the revision requests by the souse chef were not necessary (I’ve mentioned Marks’ story about this in the “Reduce cooks” section). Either way, it will save you the effort of having to return a piece to its original state, which is technically also a revision.

Aaron Walz: “[D]evelopers sometimes backpedal. I learned to keep separate DAW files of every revision I do.”¹⁸

Conclusion

In this guide, I’ve presented eight different ways to avoid revision hell:

Set a maximum number of (free) revision
Reduce cooks
Establish trust
Make sure you have all the important information
Make sure you know what the revision request is actually about
Get feedback early
Present alternatives
Keep backups of prior versions

Their aim is not to protect you from revision requests in general. Revision requests are, as mentioned, completely normal. But they can highly reduce their amount. What if you still get an unreasonable amount of revision requests despite following these tips? Having a talk with your client can help. “Most of the time, developers don’t know or don’t care about the impact they may have on you with what seems to be ‘simple’ requests. [...] Don’t be afraid to express your concern over events which may interfere with your creative activities.”¹⁹ And if they won’t accommodate you? If you’re part of a paid project, then these words by Marks might resonate with you: “Can’t get your point across? Then, do the style of music they want you to do, but make sure you don’t end up redoing the work for free.”²⁰ If you’re working on an unpaid hobby project or even if it’s a paid project that is very negatively affecting your mental health, then you should weight stepping back from it. Marks, too, mentioned that he considered quitting when he told the story mentioned in the “Reduce cooks” section. Whether you gain more from powering through or escaping the situation is ultimately up to your discretion. But hopefully the tips can help you avoid getting into such a situation in the first place and reduce the amount of sweat and tears dripping onto your desk.

Sources

Arem, Keth, interview by Aaron Marks, “Interview,” in: Aaron Marks’ Complete Guide to Game Audio. For composers, sound designers, musicians and game developers, 3rd edition, Boca Raton 2001/2017, pp. 418–421.

Chernev, Alexander; Böckenholt, Ulf; Goodman, Joseph, “Choice overload. A conceptual review and meta-analysis,” in: Journal of Consumer Psychology 25/2 (2015), pp. 333–358.

Holland, Jon, interview by Aaron Marks, “Interview,” in: Aaron Marks’ Complete Guide to Game Audio. For composers, sound designers, musicians and game developers, 3rd edition, Boca Raton 2001/2017, pp. 460–462.

Lee, Douglas and Daunizeau, Jean, “Choosing what we like vs liking what we choose. How choice-induced preference change might actually be instrumental to decision-making,” in: PloS ONE 15/5 (2020), pp. 1–15.

Marks, Aaron, Aaron Marks’ Complete Guide to Game Audio. For composers, sound designers, musicians and game developers, 3rd edition, Boca Raton 2001/2017.

Meyer, Bradley, interview by Aaron Marks, “Interview,” in: Aaron Marks’ Complete Guide to Game Audio. For composers, sound designers, musicians and game developers, 3rd edition, Boca Raton 2001/2017, pp. 509–514.

Pitkanen, Pasi, interview by Aaron Marks, “Interview,” in: Aaron Marks’ Complete Guide to Game Audio. For composers, sound designers, musicians and game developers, 3rd edition, Boca Raton 2001/2017, pp. 286–290.

Walz, Aaron, interview by Aaron Marks, “Interview,” in: Aaron Marks’ Complete Guide to Game Audio. For composers, sound designers, musicians and game developers, 3rd edition, Boca Raton 2001/2017, pp. 131–135.

Footnotes

Pitkanen, Pasi, interview by Aaron Marks, “Interview,” in: Aaron Marks’ Complete Guide to Game Audio. For composers, sound designers, musicians and game developers, 3rd edition, Boca Raton 2001/2017, p. 289. ↑
Meyer, Bradley, interview by Aaron Marks, “Interview,” in: Aaron Marks’ Complete Guide to Game Audio. For composers, sound designers, musicians and game developers, 3rd edition, Boca Raton 2001/2017, p. 512. ↑
Marks, Aaron, Aaron Marks’ Complete Guide to Game Audio. For composers, sound designers, musicians and game developers, 3rd edition, Boca Raton 2001/2017, pp. 231–232. ↑
Marks, Aaron, Aaron Marks’ Complete Guide to Game Audio. For composers, sound designers, musicians and game developers, 3rd edition, Boca Raton 2001/2017, p. 174. ↑
Walz, Aaron, interview by Aaron Marks, “Interview,” in: Aaron Marks’ Complete Guide to Game Audio. For composers, sound designers, musicians and game developers, 3rd edition, Boca Raton 2001/2017, p. 134. ↑
Marks, Aaron, Aaron Marks’ Complete Guide to Game Audio. For composers, sound designers, musicians and game developers, 3rd edition, Boca Raton 2001/2017, p. 209. ↑
Marks, Aaron, Aaron Marks’ Complete Guide to Game Audio. For composers, sound designers, musicians and game developers, 3rd edition, Boca Raton 2001/2017, p. 231. ↑
Marks, Aaron, Aaron Marks’ Complete Guide to Game Audio. For composers, sound designers, musicians and game developers, 3rd edition, Boca Raton 2001/2017, p. 507. ↑
Holland, Jon, interview by Aaron Marks, “Interview,” in: Aaron Marks’ Complete Guide to Game Audio. For composers, sound designers, musicians and game developers, 3rd edition, Boca Raton 2001/2017, p. 462. ↑
Marks, Aaron, Aaron Marks’ Complete Guide to Game Audio. For composers, sound designers, musicians and game developers, 3rd edition, Boca Raton 2001/2017, pp. 205–206. ↑
Marks, Aaron, Aaron Marks’ Complete Guide to Game Audio. For composers, sound designers, musicians and game developers, 3rd edition, Boca Raton 2001/2017, p. 255. ↑
Arem, Keth, interview by Aaron Marks, “Interview,” in: Aaron Marks’ Complete Guide to Game Audio. For composers, sound designers, musicians and game developers, 3rd edition, Boca Raton 2001/2017, p. 419. ↑
Walz, Aaron, interview by Aaron Marks, “Interview,” in: Aaron Marks’ Complete Guide to Game Audio. For composers, sound designers, musicians and game developers, 3rd edition, Boca Raton 2001/2017, p. 135. ↑
Marks, Aaron, Aaron Marks’ Complete Guide to Game Audio. For composers, sound designers, musicians and game developers, 3rd edition, Boca Raton 2001/2017, p. 206. ↑
Lee, Douglas and Daunizeau, Jean, “Choosing what we like vs liking what we choose. How choice-induced preference change might actually be instrumental to decision-making,” in: PloS ONE 15/5 (2020), p. 2. ↑
Chernev, Alexander; Böckenholt, Ulf; Goodman, Joseph, “Choice overload. A conceptual review and meta-analysis,” in: Journal of Consumer Psychology 25/2 (2015), p. 335. ↑
Chernev, Alexander; Böckenholt, Ulf; Goodman, Joseph, “Choice overload. A conceptual review and meta-analysis,” in: Journal of Consumer Psychology 25/2 (2015), p. 348. ↑
Walz, Aaron, interview by Aaron Marks, “Interview,” in: Aaron Marks’ Complete Guide to Game Audio. For composers, sound designers, musicians and game developers, 3rd edition, Boca Raton 2001/2017, p. 134. ↑
Marks, Aaron, Aaron Marks’ Complete Guide to Game Audio. For composers, sound designers, musicians and game developers, 3rd edition, Boca Raton 2001/2017, p. 232. ↑
Marks, Aaron, Aaron Marks’ Complete Guide to Game Audio. For composers, sound designers, musicians and game developers, 3rd edition, Boca Raton 2001/2017, p. 231. ↑

Contents