How to Stop Getting Ghosted on r/INAT (And What to Try Instead)

If you've posted on r/INAT in the last year, you already know that r/INAT ghosting isn't a bug. It's the default outcome. The subreddit has a sarcastic running meme that one actual poster wrote into their own collaboration request:

"Please pm me if you are interested, don't forget that I'll ghost you in around 2 weeks as everyone loses interest." — r/INAT

That's not flaking. That's diagnosis. People are naming the pattern because the structure of the subreddit makes it inevitable.

This post is a how-to, but the diagnosis matters first. You're not picking wrong teammates. You're fishing in a pond that's designed to return unreliable replies. Once you see that, the fix is changing the filter before you meet anyone, not trying harder on r/INAT.

Here are the six steps. Each one replaces a missing piece of structure that r/INAT can't enforce. Use them in order; each step assumes the previous one passed. By the end you'll also have three pre-ghost signals that let you leave a fraying project before you sink another three months into it.

Why r/INAT predictably fails

Before the fixes, the failure model. r/INAT doesn't produce ghosting because gamers are flakes. It produces ghosting because three things are free on r/INAT that should cost something.

1. Zero commitment cost. Posting "LF artist, paid in rev-share, MMO concept, DM me" costs about 40 seconds. Replying to it costs 20. Nothing the poster or the replier has said, signed, or done is staked. Compare that to a game jam with a 48-hour deadline and a public leaderboard. Even Ludum Dare LD46, which had a hard clock and a submission page, only got ~48% of its 10,330 sign-ups to submit something finished, per the Ludum Dare archive. If half the people drop out even when there's a deadline, imagine what happens with zero deadline.

2. Zero flake cost. On r/INAT, disappearing in week three has no consequence. No money forfeited. No reputation loss in a community that remembers you. No one you'll run into at the next meetup. The DevPods host on YouTube described the pattern on free mentorship calls, "they just would flat out skip, just not show up," and added that the same people never did that on paid calls. When leaving costs nothing, many will leave.

3. Zero filter. Anyone can reply to an r/INAT post. There is no skin in the game before the DM starts. One collaborator described getting "over ten responses" to a post within 24 hours, "but only less than a handful had decent effort put into them." That's the expected hit rate of any open call with no filtering.

Every one of these is structural. Every one can be replaced by a concrete step on your side, without waiting for r/INAT to fix itself. Here are the six.

Step 1 of 6 — Rewrite your post like your reader has seen 200 of these today

Because they have.

What to do: Cut every sentence that could appear in any other r/INAT post. Replace "LF artist for rev-share on my MMO" with a specific scope, a specific unpaid time commitment, one short demo link, and one sentence explaining why you, personally, can ship this piece of it.

Why it matters: The wheat-from-chaff separator happens in your post, not in your DMs. Readers with the time and skill to contribute are skimming. They will stop the second you sound like every other post. Specificity is the filter.

Watch for: If your draft uses "rev-share," "MMO," "passion project," or "looking for everything," you're writing the ghost bait version. Rewrite until a stranger could describe your next two weeks of work in one sentence.

Step 2 of 6 — Filter replies with a 15-minute trial task

Don't schedule a call. Don't talk about rev-share. Send a tiny, concrete, time-boxed task.

What to do: Reply to every interested DM with the same 15-minute task: a mood-board page, a 30-second UI mock, an eight-bar combat loop, or a one-screen Godot prototype. Tell them you'll give feedback on what comes back. Do not schedule anything until you've seen the output.

Why it matters: Behavioral economists Bryan, Karlan, and Nelson review research on commitment devices and find that only 10-30% of offered commitments get taken, but the people who do accept follow through at much higher rates. A trial task is a tiny commitment device. It loses you the 70-90% who were never going to stay, at the cost of one afternoon.

Watch for: Anyone who wants to "hop on a call first" before doing the task. That's the free-call pattern. The DevPods host's rule applies here: if someone won't show up for a free trial task, they will not show up for a year-long project. Better to learn it on week one than on week twelve.

Step 3 of 6 — Require a 2-week demo-able milestone before equity talk

No splits. No contracts. No rev-share math. Not yet.

What to do: Agree on one tiny shared milestone, demoable in two weeks, before you discuss any ownership, credit, or revenue. One level, one boss fight, one character sheet with walk cycles, or one music loop hooked into a test scene. The word "demoable" is load-bearing. It must be something you can show a third person at the end.

Why it matters: The author of the "2 games in 2 months with a stranger from Reddit" post-mortem put the rule bluntly: "Keep the first collaboration together small. If the game is too big then one of you will eventually abandon and all that time and effort will be wasted." A two-week milestone is the smallest box that proves you can both ship something together without knowing whether you like each other long-term.

Watch for: "Let's sort out the rev-share split first." That's the ghost bait signal in reverse. If the split matters before the first demoable thing exists, you're talking about imaginary money on an imaginary game. Nothing good has ever started that way.

Step 4 of 6 — Put the deal in writing before the first real asset is built

After the two-week demo, and before anyone starts shipping real work, write down the deal.

This doesn't need a lawyer. It needs the following five things in a shared doc, in plain English, signed by both parties. A Google Doc with typed names and dates is legally weak but socially enormous.

1. Scope. One paragraph describing what the project is and isn't. Genre, platform, rough size (hours to play), and what's explicitly out of scope.
2. Deliverables per contributor. What each person is on the hook for, over what cadence. "Artist: five character sheets and two environments per month" beats "art."
3. Split. How credit, IP ownership, and (if applicable) revenue divide. If you're pre-launch and don't want to talk money, write "no revenue split until we both agree to one in writing" and sign that. It's a split.
4. Exit clause. How someone leaves cleanly. Minimum notice, what they keep, what returns to the project. This is the anti-ghost clause: the polite version of "say goodbye, don't just disappear."
5. IP retention. Everyone keeps the right to show their own contributions in their portfolio, including for cancelled projects. This single line is why good artists and composers will sign something they otherwise wouldn't.

Why it matters: Written agreements convert "I'll think about it" flakes into "I signed, so I'll show up" contributors. They don't create commitment by magic. They make existing commitment legible. When something goes sideways, you argue over paper instead of vibes.

Watch for: Anyone who won't put their commitment in writing after shipping a two-week demo. That's a week-six ghost dressed as a week-two teammate. For how the cadence works once two or more people have signed, read Accountability Circles.

Step 5 of 6 — Make progress observable: weekly public demo, not a DM

Private Discord progress updates are not progress. They are private theater.

What to do: Publish a weekly Friday demo (screenshot, 30-second clip, audio snippet, or playable link) somewhere a third person can see it. X, Bluesky, a Discord channel that isn't your project channel, a devlog, or a stream. Small is fine. Public is the requirement.

Why it matters: Exley and Naecker of Harvard Business School found that observability by others significantly raises demand for commitment devices. Being watched makes people pick harder commitments and follow through on them. A weekly public demo is the cheapest watching mechanism indie dev has. It also flips recruitment, as one DevPods guest put it: "if it's worth recruiting a collaborator and you have a fun game, it's way easier to do that when your game exists." You recruit better after you've shown you ship.

Watch for: Weeks where nobody posts anything and nobody says why. That's the first pre-ghost signal. Name it that Friday ("hey, we skipped the demo, what happened?"), not six weeks later.

Step 6 of 6 — Leave early when the pre-ghost signals show up

The loyal move, counter-intuitively, is to leave early. A ghost who goes unnamed continues. A project without the ghost can still ship.

What to do: Commit in advance to three pre-ghost signals, and act the week you see any of them:

1. Replies stop within the agreed cadence. You said weekly demo. Two Fridays pass with nothing, no heads-up. That's a signal, not a coincidence.
2. Scope changes without discussion. The roguelike is suddenly an MMO, or the two-week milestone quietly became "whenever it's ready." Unilateral scope changes are how one partner exits mentally while still on the roster.
3. "Real life got busy" without a specific return date. Real life does get busy. Real teammates say "I'm out Apr 20 to May 4, I'll pick up the combat pass on May 5." Non-committal versions of this mean the ghost is already booking the flight.

Why it matters: As one contributor to the Escapist's piece on r/INAT's "pick-up indie scene" put it, unpaid teammates "are always a button press away from quitting." Your job is to notice when that button has been pressed, name it, and let the rest of the project continue without the dead weight.

Watch for: Your own reluctance to name the ghost. You'll feel rude. You're not. You're doing the one thing that keeps the remaining collaborators from wasting their month too.

Common pitfalls

A few traps that will undo all six steps if you don't name them:

• "I'm just an idea guy." On most indie forums, including gamedev.net's classifieds, the running consensus is blunt: "most likely nobody needs an idea guy." If ideas are all you bring, you're the ghost in someone else's project, not the victim of one. Ship the first hour of gameplay yourself, then recruit.
• Treating rev-share as a contract. Revenue share on a game that won't ship is fantasy math. "20% of zero is still zero," a line from Eric Nevala's Your Indie Game Dev Team Will Fail that keeps getting re-quoted because it's true. Use rev-share only on top of a real written agreement and only after a shipped milestone.
• Rewriting the r/INAT post and expecting different structural results. Steps 1 and 2 fix the post and the filter. If you're not also doing steps 3 through 6, a better post just gets you ghosted by more qualified people.

Frequently asked questions

Why do r/INAT posts get ghosted?

Because the subreddit has zero commitment cost, zero flake cost, and zero filter. Replying to a post costs nothing, and leaving costs nothing. GDC's producer panel on managing indie teams frames the same problem from the producer side: keeping unpaid distributed teammates aligned is structurally hard. r/INAT is where that structural problem is most visible.

How long should a trial task be?

15 to 30 minutes. Long enough that someone who wasn't going to show up won't bother, short enough that someone who would show up will do it the same evening. Avoid multi-hour tests: they filter out people with day jobs, which is almost everyone worth working with.

Is rev-share automatically a red flag?

No. Rev-share as the first subject of conversation is a red flag. Rev-share after a shipped two-week milestone, written up in step 4's agreement, is a legitimate arrangement. The heuristic: if the split gets proposed before a demoable artifact exists, the "share" is fiction. If it's proposed after, it's a deal.

How early should I leave a project that's going quiet?

The week you see any of the three pre-ghost signals from step 6. Not the month. Leaving early feels disloyal and is the opposite. Staying in a dead project means you're not available for a live one, and the remaining collaborators are pouring work into a fraying context they don't know is fraying.

What should a 2-week milestone look like?

One shared demoable thing. Not polished. Not the whole game. A boss fight with a placeholder boss. One level grey-boxed with the intended mechanics. A minute of looped music hooked into a test scene. Something a third person can watch and say "okay, that's a game." If you can't name that thing in a sentence, the milestone is still too big.

What to do next

If you've tried r/INAT more than once and it keeps ending the same way, the follow-on posts are these:

• How to Find Reliable Teammates for Your Indie Game Project: the sibling on where to look instead of r/INAT, and the two vetting rituals that save you from repeating steps 1 and 2.
• Accountability Circles: how the step-5 cadence actually runs once two or more people have committed. Weekly commitments, owned areas, the ritual that replaces the Discord "family."
• Solo Dev vs. Team: Which Path Is Right for Your Game?: if after reading this you think solo is simpler, this post compares the honest tradeoffs.

You're not lazy. You're unsupported. r/INAT isn't giving you the three structural pieces (filter, commitment cost, observability) that a shipping team needs. You can build them yourself with the six steps above, or you can sign up for Clowdr and work inside a structure where someone is counting on your build by Friday from day one.