Quick answer: Look where people demonstrate work, not where they describe themselves: game jams (the best audition that exists), dev communities where you've seen their output, and credits of small games you admired. Vet for reliability and communication over raw talent, start with a small bounded trial, and put the split conversation in writing before momentum makes it awkward.
Look where people demonstrate work, not where they describe themselves: game jams (the best audition that exists), dev communities where you've seen their output, and credits of small games you admired. Vet for reliability and communication over raw talent, start with a small bounded trial, and put the split conversation in writing before momentum makes it awkward. That's the short version — the sections below get into the how, the why, and the mistakes worth dodging.
Jams are interviews that can't lie
A weekend jam with a potential teammate reveals what months of Discord chat can't: how they scope, communicate under pressure, handle disagreement, and whether they actually finish. It's also the natural recruiting venue — you meet people precisely when they're demonstrating shipping behavior.
Failing a jam, recruit from evidence anyway: people whose posted work, jam entries, or open-source contributions you've seen. 'Idea person seeks team' posts attract idea people; finished-thing people are found near their finished things.
Vet for the traits that actually kill projects
Indie teams rarely die from insufficient talent; they die from ghosting, chronic overcommitment, and communication styles that turn friction into drama. Weight your evaluation accordingly: Do they respond predictably? Estimate honestly and hit small promises? Take feedback without bleeding? Have life-bandwidth that matches their claims?
The portfolio answers 'can they do the work'; only behavior over weeks answers 'will they'. That's what trial periods are for — judge the working relationship, not the showreel.
Structure the first month so exit is cheap
Start every collaboration with a bounded trial: one defined deliverable, a few weeks, explicitly framed as mutual evaluation — 'let's do this small thing and see how we work together'. Both sides keep dignity if it fizzles, and most fizzle; that's the system working.
If it clicks, immediately do the grown-up things: written split with vesting, role boundaries, decision rights, and a communication cadence. The best moment to structure a partnership is the honeymoon — it's also the moment teams most confidently skip it.
Momentum is a resource — budget it
Progress you can see is fuel. Long stretches of invisible work — refactors, systems with no on-screen result — drain motivation even when they're necessary. Good project plans alternate: one stretch of plumbing, then something you can watch move on screen.
When motivation dips, shrink the loop. Pick the smallest change that makes the game visibly better today. Shipping anything, even a menu fix, restarts the engine.
Decide how you'll know it's working
Every project needs a definition of done that isn't a feeling. Pick the few signals you'll trust — playtesters finishing the demo, crash-free sessions, wishlists per week — and check them on a schedule. Otherwise you'll steer by whichever anxiety is loudest that day.
This is also the honest defence against endless polishing. When the signals say players get through it, enjoy it, and nothing breaks, the feature is done. Move on.
The quiet work that protects all of this
Everything in this post gets undone by an unstable build. A great store page, a clever marketing beat, a perfect jam entry — none of it survives 'crashed twice, refunded'. Stability isn't a feature players praise, but it's the floor everything else stands on.
Give yourself visibility before you need it: crash reports with stack traces, a simple way for players to flag issues from inside the game, and a habit of fixing the top recurring error before adding anything new.
Putting it to work
Don't try to act on all of this at once. Pick the one change that costs you the least and pays the most this week, do it, and see what actually happens before reaching for the next.
Most of this rewards steadiness over intensity. A small improvement made every week, checked against how real players respond, outruns any single burst of effort — in this corner of game development and every other one.
Scope to the hours you really have, then ship the small game that fits them.