In my last post, Developer Relations 101, I discussed some strategies for how to find the developer that’s the right fit for you and your project. In the next entry in my course book, Developer Relations 102, I’m here to talk about how to set up a smart legal arrangement to ensure that once you’ve found a production partner, things get off on the right foot and stay cordial throughout production.

So, you’ve found the developer of your dreams, and they like you back! What do you do next?

Consider a Discovery Phase

During an RFP process, or even a less formal introduction between a potential client and a potential developer, it’s common to hit up against a moment where the developer has done as much work as they’re comfortable doing without being paid, yet the client still needs a bit more information before they’re ready to sign on the dotted line and hire the developer for a full scope of work. A discovery phase can be a great way forward in this situation, and they are increasingly common for many good reasons.

The idea behind a discovery phase is for both parties — the client and the developer — to dig into the project in detail and know that their interests are protected. No one likes worrying about someone running off with their idea, or working endlessly in the hope of a paying gig in the future, so having a formal arrangement in place before things go too far can help make everyone feel more secure. Discovery establishes a limited scope of work that basically acknowledges, “We’re going to get a better sense of what this project entails,” and compensates a developer for the time and resources they’re putting towards helping figure that out (as Carla wisely advised in her post on How to Make a Children’s App, paying your developer is a good idea). A discovery phase can also be a great first step towards getting a realistic longer-term scope in place once you decide you’re ready for a larger commitment.

Take Stock of How Much You Know – and How Much You Don’t

Even if you have gone through a discovery phase and are totally comfortable with your developer, you may still not have a full sense of the scope of your project at the beginning of production. On the other hand, you may be completely sure of all of the details of your idea, and understand what exactly it will take to execute. The kind of deal you make with a development partner should be fundamentally shaped by both your expectations and your understanding of your own process and point in development.

When you know exactly what you want to make, and have deadlines of when you need to make it, a traditional milestone-based arrangement can be a good fit. Setting up a production calendar with specific deliverables including Alpha, Beta and Release candidates and detailed lists of what those deliverables entail can give a large sense of security to both client and developer. Generally speaking, these arrangements tie payments to key milestones, so you as a client will pay a certain amount up front followed by x percent at Alpha, Beta, etc.

The advantage to this kind of agreement is things are defined from the get go — the developer knows exactly how much they’ll be paid and when those payments will arrive. They have a good sense of how much work they’ll have to do to complete the project, making it easy for them to schedule their time and allocate resources. The client knows with precision how much their final product will cost, and more or less what features it will have. Any changes to scope from the time of signing the deal generally need to be mutually agreed upon and written up in a fresh scope. Deliverables-based agreements like these are very straightforward, but this kind of arrangement can be very problematic if your project is one with a lot of unknowns.

Maybe you have some firm ideas for a great character group or a innovative new way to teach math on an iPad, but you’re looking for a developer to help you figure out what to do with it exactly and you want to be able to change tactics nimbly if needed down the road. In this case, what’s known as a “time and materials” agreement may be a better fit. “Time and materials” refers to the fact that you’re paying a developer for their time (and the time of their team members), as well as any out-of-pocket expenses related to your project. At some set interval, say monthly, the developer will send you a bill specifying how they’ve used their time on your project, something along the lines of, “20 hours of our engineers time at this much per hour, 15 hours of our producer’s time, 5 hours of ux design, etc.”

Time and materials makes for a flexible arrangement, one where it is easier to make scope changes without hearing, “But we agreed to only one round of revision on the character design!” from your developer. It’s also an arrangement that can make everyone very nervous — if you’re not careful, having a fluid scope and budget can be a way to spend a bunch of money “figuring things out” without ever arriving at a final destination. It can also be risky for the developer, especially one with a staff who still needs some reasonable sense of how to allocate their resources and plan ahead. One way to help mitigate this — *wink wink* – is a discovery period! I’ve had good experiences with time and material arrangements with a discovery period up front – it gives everyone a better sense of total costs and schedule, while allowing a realistic amount of flexibility down the road. Additionally, many time and materials agreements still contain a loose set of deliverables, forcing everyone to think up front about what they realistically want to accomplish in general terms.

Negotiate Frankly

Finally, keep in mind that, discovery period or no, the way you treat your developer during the negotiation of a statement of work sets the stage for your relationship to come. It pays to be honest, straightforward, and responsive. Don’t leave your would-be developer hanging waiting for a reply from you for weeks at a time or change your mind constantly (and make sure you’re comfortable with their degree of responsiveness and realism as well). If you – or your counsel – comes off as rude, evasive, or less than honest, you’re off on a terrible foot, and your relationship with your developer may be over before it ever began.

So, once your deal is done and you’re off to the races, what then? Carla offered some great tips on sending and receiving feedback in her last post, and I’ll offer some more general tips on communication and project management in my next post, Developer Relations 103. You may have a master’s degree by the time you’re done reading these!

In the meantime, you are always welcome to email us at KidsGotGame@NoCrusts.com, follow us @NoCrusts on Twitter, or sign-up to receive email updates.