If you're writing for RPGs, it's pretty likely you'll get asked to turn over a "milestone" about halfway through the process. This is basically a midpoint check-in, where you show you've got about half the word count completed. But a milestone can and should be a greater opportunity for that for you, the freelancer, to interface with your developer. What makes a good milestone?

* Word Count. What is "about half" of your word count? Anywhere near 50 percent is fine, so long as it's showing good progress toward the goal. Forty-five percent is probably fine. Twenty-five percent is not. If that's all you have, you'd better add an explanation about how you're going to make up the words to stay on schedule, and perhaps propose a follow-up milestone in a week or so that's above the 50 percent mark. (Few developers like seriously under-count milestones, as they REALLY worry us, but we know life can get in the way sometimes.)

* Writing Mix. Most projects have some flavorful writing and some crunchy bits. Although it might be tempting to blaze through whichever of those is easier for you to hit your milestone word count, that's doing a disservice. You should be sure your milestone includes large chunks of both flavor and crunch. If anything, you should skew toward the one of those you aren't as good at, because you'll be able to focus on questions that work raises (and it'll make your inevitable sprint to the final turnover date that much easier!). From the developer side, I like seeing someone's work on both types of writing, so I can guide a bit better if one seems a little weaker.

* Good But Not Polished. Your turnover doesn't need to be fully styled, cross-checked, and spellchecked, but it should nevertheless be a good representative of the type of work you'll be turning in. If you have a 5,000 word assignment and turn in 2,500 words of meandering outline and bullet points, it doesn't do yourself or your developer any good. It doesn't do you any good since you'll have to rewrite lots of that anyway, and it doesn't do your developer any good because they can't judge the quality of your progress thus far. 

* Questions, Questions, Questions. The milestone is the best possible time to ask questions about your project. These probably don't need to be specific details (like "should I put a comma or semicolon in this place in the stat block?") but should be general thinks you need clarification on ("I can't see why the gnome would give up the rubies to the pirate captain when he has sick children at home who presumably need money for medicine"). Save the very specific questions for the final turnover or, even better, research them yourself. A piece of advice I give to anybody, in any walk of life, when asking a question: always include an answer with your question. It shows you've been thinking about it, and doesn't just dump the responsibility for digging up an answer onto someone else. ("Should this be a comma or a semicolon here? I think the latter, because although the baomal uses a comma in the Bestiary, the wood golem uses a semicolon in Bestiary 2, and later sources generally prevail." "I can't see why the gnome would give up the rubies to the pirate captain, unless there's some threat to the gnome's family (beyond sickness) that the pirate captain can help end, maybe?")

Also! You might not have any qeustions at this milestone point, and that's fine. They aren't necessary. Just say you don't have any questions.

* Deviations. You shouldn't ever deviate from your assignment too much without checking in with your developer first, but the milestone is a good place for you to note deviations from the outline or previous discussions. You should always note why you're deviating; if you don't have a good reason, then you probably don't need to be deviating at all. (A good explanation might run, "this part of the plot says the gnome goes to the dock to give away the rubies, but Source XYZ says gnomes in this region are deathly afraid of water, so I made it a halfling instead.")

* Always Mention the Due Date. Now is the time to take a serious, critical look at whether you'll make your due date. If you'll need an extra week or so because your pet has scheduled surgery or something, say so. However, if you don't anticipate any problems and still plan to hit your due date, say so! And give the date itself, so it's clear you're on the right track. After all, that's what developers really want to get out of the milestone. Ending your email with "I'm still well on track to hit my final turnover date of June 3rd!" is a great way to show this.

* Take a Breather. I like to take a few days off after turning in a milestone, both to give myself some mental space away from the project, and to give the developer some time to get back to me with comments, concerns, or answers to my questions. Sometimes, a developer says something simple like, "All looks good; carry on!" That's sometimes a clue that the developer is a little too overworked to give your milestone a close eye, but it's more often the case that you are, indeed, doing just fine.

Then keep just doing fine, and your turnover will be a snap!