Game Audio Outsourcing: How to Hire a Sound Designer for Your Indie Game

An indie developer finishes the vertical slice of their game, exports a trailer, and sends it to a few publishers. The responses come back with the same note in different words: the game looks good but the audio does not carry the same weight as the visuals. The developer, who has been using free sound libraries and a few generated effects, realizes that audio is the part of the project they cannot judge well enough to fix themselves. They need to hire a sound designer, and they have never done it before.

This article is for that developer. It assumes you are on the buying side of the transaction, you have a budget somewhere between $500 and $15,000, and you do not know what the process actually looks like. The freelance pricing guide and the marketplace guide cover the same transaction from the designer's side; this article covers it from yours.

When should you hire a sound designer instead of doing it yourself?

The honest answer is that you should do it yourself for as long as the audio is not the thing standing between the game and its next milestone. Hiring has a real cost — money, coordination time, and the risk of a bad fit — and it only pays off when the audio has become the bottleneck rather than a task on the list.

The specific triggers that indicate you have crossed that line:

• Publishers or platform holders have commented on the audio. When an external party with no investment in your ego tells you the audio is weak, it usually is. This is the most reliable signal that the current approach is not working.
• The game is playable end to end and the audio is the only remaining rough edge. A vertical slice with good visuals, good mechanics, and poor audio is a project where audio is the highest-return investment. A prototype with rough visuals and rough audio is a project where the audio is not yet the priority.
• You have spent more than 40 hours on audio and the result is still not good enough. At an opportunity cost of even $25 per hour, 40 hours of your time is $1,000. If the same $1,000 buys a sound designer's time and produces a better result, hiring is the better use of the budget.
• You are approaching a demo or a festival deadline. A trailer or a playable demo that goes to reviewers needs audio that does not distract. A sound designer can produce this in two to three weeks, which is often faster than a solo developer can learn enough to do it well.
• The game's audio needs middleware. Adaptive music, dynamic mixing, or a state-driven ambience system are not things a solo developer usually knows how to build. The middleware comparison covers what it takes to learn them.

The cases where hiring does not make sense are equally specific. A prototype that is still finding its core mechanic does not benefit from professional audio. A game with a budget under $500 does not have enough budget to hire well, and the money is better spent on the free resources covered in the free generator guide. And a game where the audio is deliberately minimal — a puzzle game, a card game, an idle game — does not need the kind of work a sound designer specializes in.

Where do you actually find game audio freelancers?

The channels where indie developers find sound designers in 2026 fall into four categories, and each one has a different cost and quality profile.

Channel	Typical rate	Best for	Watch out for
Direct referrals	Market rate	Trusted quality, established workflow	Limited availability
Discord communities	Below to market rate	Emerging designers, portfolio builders	Variable quality, less project experience
Freelance platforms (Upwork, Fiverr)	Below to market rate	Small, well-defined tasks	Race to the bottom, quality variance
Audio-specific marketplaces	Market rate and above	Specialists with strong reels	Higher minimum project size

Direct referrals are the highest-quality channel and the hardest to access for a first-time hirer. If you know another indie developer who has shipped a game with good audio, ask them who did it. The recommendation is trustworthy in a way that no portfolio can be, because the referrer has already paid the coordination cost of working with the designer.

The Discord communities that matter most are the ones attached to game development networks. The Wwise user community, the FMOD community, and the general game audio Discords all have channels where designers post portfolio work and developers post job listings. The quality is variable, but the pool is large and the designers are usually responsive.

Freelance platforms are the weakest channel for game audio specifically. The platforms are optimized for short, transactional work — a logo, a voice-over, a single sound effect — and game audio projects are usually longer and more collaborative than that. The designers on these platforms who specialize in games tend to be early in their careers, which is not necessarily bad, but it means the developer has to do more of the direction work.

Audio-specific marketplaces — the ones where the primary content is sound design reels rather than general freelance listings — are the highest-quality channel after referrals. The designers there are specialists, and the portfolio filtering that the platform requires means the floor is higher than on a general freelance site.

What does hiring a sound designer cost in 2026?

The rate a sound designer charges depends on three things: their experience level, the scope of the work, and the format of the engagement. The numbers below are the ranges that indie projects actually pay, drawn from the rate structures that freelance designers publish and the pricing that has been described by designers working in the indie market.

Engagement type	Rate range	Typical project size	Notes
Per sound effect	$15 to $150	10 to 50 sounds	Cheapest unit, hard to scale
Hourly	$40 to $120/hr	20 to 100 hours	Flexible, requires trust
Per finished minute of audio	$150 to $500/min	5 to 30 minutes	Common for voiced content
Fixed-price project	$1,500 to $15,000	Full game sound set	Most predictable for both sides
Retainer	$500 to $3,000/mo	Ongoing	Best for live games

The per-sound-effect model is the one most first-time hirers reach for, because it is easy to budget. It is also the model that produces the worst results, because the designer is incentivized to spend minimum time per sound and the developer has no way to evaluate the total scope until the project is over. A game with 200 unique effects at $50 each is $10,000, which is more than most indie projects can justify for audio.

The fixed-price project model is the one that works best for the first engagement. The developer writes a brief that specifies the scope, the deliverables, and the revision rounds, and the designer quotes a single number for the whole project. This forces both sides to think about the scope upfront, and it produces a budget that does not surprise either side later.

The freelance pricing guide covers how designers set these numbers. From the buyer's side, the practical rule is that if the designer's quoted price is less than about $2,000 for a full game sound set, the scope is probably not what you think it is, and the conversation needs to happen before the contract is signed.

What goes in the contract before any work starts?

A game audio contract does not need to be long, but it needs to cover five specific things. The projects that go wrong are almost always the ones where one of these was left undefined.

Scope. The contract should list every sound the designer is producing, organized by category. "Background music" is not a scope. "Three ambient loops of 60 seconds each, one combat music loop of 90 seconds, and one menu music loop of 45 seconds" is a scope. The more specific the list, the fewer disputes later.

Deliverables. The format of the delivered files matters as much as the sounds themselves. The contract should specify the file format (typically WAV), the sample rate (44.1 or 48 kHz depending on the target platform), the bit depth (16 or 24 bit), and whether the deliverables include the source project files or only the finished audio. The sample rate and format guide covers the platform-specific requirements.

Revision rounds. The contract should specify how many rounds of revisions are included in the price, and what constitutes a revision versus a new request. A typical structure is two rounds of revisions per deliverable, with additional rounds billed hourly. A round is defined as a single consolidated set of change requests, not an indefinite conversation.

Rights and licensing. The contract should specify what rights the developer is purchasing. For a commercial game, the standard is full ownership or an exclusive perpetual license for the finished audio. The designer typically retains the right to use the work in their portfolio. Third-party assets used in the audio — licensed samples, music library content — need to be identified along with their licenses, because the developer is responsible for clearing them for the shipped game.

Payment schedule. The standard for freelance game audio is 50 percent upfront and 50 percent on delivery. For larger projects, a milestone-based schedule — 30 percent upfront, 30 percent at the halfway point, 40 percent on final delivery — is common. The contract should specify the payment method and the currency, and it should specify what happens if the project is canceled partway through.

The scope and the deliverables sections are where first-time hirers most often under-specify. The file size reduction guide covers the format choices that need to be in the deliverables section; the mix hierarchy guide covers the routing structure that the finished audio should support. Both of these should be discussed with the designer before the contract is signed, not after.

How do you write a brief that gets the result you want?

The brief is the document that tells the designer what to produce. A good brief is specific, references other games, and describes the intent rather than the implementation. A bad brief describes the sound instead of the situation.

The template that works has five sections.

Section 1: The game. Two or three sentences describing the game's genre, tone, and the experience the player is supposed to have. A shooter with a horror aesthetic and a shooter with an arcade aesthetic need different audio even if the mechanics are similar.

Section 2: References. Three to five specific games, films, or sound design examples that resemble what you want. "Similar to the audio in Hollow Knight" is more useful than "atmospheric". A reference tells the designer the target aesthetic; a description tells them only your interpretation of it.

Section 3: The sound list. Every sound needed, organized by category, with a brief description of each. The description should focus on the situation and the feeling, not the technical implementation. "A weapon impact that feels heavier than the pistol but shorter than the shotgun" is a useful brief. "A 200 Hz thump with a 300 ms decay" is a spec, not a brief, and the designer is better at turning the first into the second than you are.

Section 4: Constraints. The delivery format, the target platforms, the file size budget, and any technical requirements the game has. A game shipping on mobile has different constraints from a game shipping on PC, and the mobile optimization guide covers what those constraints actually mean in practice.

Section 5: Timeline and milestones. When the first batch of sounds is needed, when the full set is needed, and what feedback the designer can expect at each stage. A timeline that allows for two weeks of design followed by two weeks of review followed by one week of revisions is more realistic than a timeline that compresses everything into two weeks.

The most common mistake in briefs is over-specifying the sound and under-specifying the context. A designer who receives "bright, punchy, 200 ms decay, low-pass filter at 8 kHz" will produce a sound that satisfies the spec and may still feel wrong for the game. A designer who receives "an impact that feels satisfying when the player's sword connects with a metal shield, similar to the weight of the shield blocks in Dark Souls" will produce something that is more likely to work in context.

What deliverables should the contract specify?

The deliverables section of the contract is what the developer actually receives at the end of the project. It is worth being specific, because the difference between a well-organized delivery and a poorly-organized one is the difference between a game that is easy to ship and a game that requires a week of file cleanup.

Deliverable	Typical format	Why it matters
Final audio files	WAV, 44.1 or 48 kHz, 16 or 24 bit	Ready to import into the engine
Source project files	DAW session or engine project	Allows future edits without the designer
Naming convention doc	One-page PDF or README	Prevents confusion during integration
License documentation	Text file listing third-party assets	Required for legal clearance
Placeholder versions	Lower-quality previews	For testing before final delivery

The source project files are the deliverable that most first-time hirers forget to ask for, and the one they regret not having six months later. If the game's design changes and a sound needs to be re-tuned, having the source files means the work can be done by anyone with the right software. Without them, the designer is the only person who can touch the audio, which locks the developer into a relationship they may not want.

The naming convention is the other deliverable that matters more than it appears. A folder of 200 files named sword_impact_v2_FINAL.wav and sword_hit_final_v2.wav is a folder that takes a day to organize. The large library production guide covers the naming conventions that work at scale; the contract should require the designer to follow a convention that the developer specifies, not one the designer chooses.

How do you evaluate work when you are not a sound designer?

This is the question that first-time hirers do not know how to answer, and it is the one that determines whether the engagement succeeds. You are not expected to evaluate the audio at the level a sound designer would. You are expected to evaluate whether the audio works in the game, which is a different question and one you are qualified to answer.

The evaluation happens in three passes.

Pass 1: In the game. Import the audio into a build and play through the scene. Do the sounds land at the right moments? Does the audio support the gameplay or fight it? Does anything sound out of place? This is the pass where the most important problems show up, because the audio is being evaluated in the context it was designed for.

Pass 2: Against the references. Play the delivered audio next to the references from the brief. Does it sound like it belongs in the same category as the references? If the brief referenced Hollow Knight and the delivered audio sounds like a mobile puzzle game, the designer missed the target, and the conversation should be about that specific gap.

Pass 3: Level-matched comparison. Import the audio and normalize all the sounds to the same average level. Then listen for whether any sound stands out as louder, quieter, longer, or shorter than the others. The variation system guide covers the perceptual thresholds that determine whether these differences are noticeable; the practical test is whether the sounds feel like they belong to the same set.

The one thing the developer should not do is evaluate the audio in isolation, on headphones, without the game running. A sound that seems slightly wrong when auditioned alone can be perfect in context, and a sound that seems fine alone can be buried in the mix once the game is playing. The evaluation has to happen in the environment the player will experience.

The most useful feedback a developer can give a sound designer is not "this sound is wrong" but "this sound is doing X when I need it to do Y". A weapon impact that the designer made punchy but that the developer needs to be subtle during stealth sections is a specific, actionable note. A note that just says "this doesn't feel right" is not, and it puts the designer in the position of guessing what the developer actually wants.

The final observation is that the first engagement with a sound designer is a learning experience for the developer as much as for the designer. The brief that works, the revision process that produces the right result, and the deliverables that actually get used are all things that are easier to get right the second time. The developers who have the best long-term relationships with their sound designers are the ones who treated the first project as a way to learn how to work with the second one.