How to Protect Your IP in P2P Alliances

A reluctance to talk through the tech. Before ever signing with a software development firm, partners should sit in a room until they’re convinced the ISV understands what they want. This may take hours, and the development team may balk, but this should be non-negotiable. Talking through workflows, user experience, and back-end processes in person is essential to defining the scope of the project. You never know what unforeseen hiccups might arise in these brainstorm sessions. Companies have been known to change their entire go-to-market strategy based on these discussions.

Vague deliverables and timelines. How does a partner track the progress of ‘software solution development’? ISVs should be able to provide a breakdown of each stage of the project, what components are involved, and the time it will take to develop them. Yes, things may change down the road. Market or customer research may impact the go-to-market strategy or the user experience, for example. Contingencies for situations like this should be written into the contract. But if there isn’t a well-defined schedule of deliverables, partners have little to no recourse when the project drags on longer than anticipated or is delivered incomplete.

Clarity on subcontractors. A lot of development houses work with subcontractors outside of the U.S., typically low-level developers, engineers, or testers that perform mundane tasks at a fraction of the cost of workers in the States. These subcontractors are in many cases not subject to the terms laid out in the original contract, and their use can carry unexpected consequences. If there’s a hold on the project, for example, will the developer be able to bring the same contractor that worked on the project before and is familiar with the workflows when development resumes? Does the contract stipulate that these workers are paid at the same rate as higher-skilled American workers? Most importantly, the terms and conditions outlined in the contract partners have with development houses may not apply to the subcontractor. After all, they’re in a different country with different regulations. Even if it’s determined that the subcontractor violated a binding contract, who’s going to head over to India or Romania to engage in foreign arbitration? Partners should look at these clauses carefully. If there’s no mention of subcontractors in the contract, or if their definition, hourly rate, or confidentiality agreement is vague, the ISV should amend the contract to address these concerns.

ISV rights to use of IP. Even in the simplest situations, there are considerations that should be taken into account when it comes to clauses specifying what rights the developer has to the intellectual property. The most innocuous stipulation can carry consequences. For example, it’s best practice to allow ISVs to use the tech they’ve developed for marketing purposes. But what happens when they slap that project on their website before the partner has even launched it? Service providers should watch out for clauses dealing with the use of code, too. Most contracts say that the developer can use the code they’ve written for other projects as long as those clients aren’t direct competitors and the purpose of the tech is different. But as anyone who’s gone through a commissioned SaaS project can attest, things rarely go according to plan, and what started out as one solution can easily turn into another. When an e-commerce portal turns into a data collection platform, for instance, the competitive landscape changes.

Remuneration and revenue sharing structures. It’s complicated enough if the project is just on a one-time basis. But what about when service providers and software developers decide to go into business together? Suddenly, the complexity increases exponentially. If the ISV accompanies the reseller on a sales call, and they land the deal, who gets the commission? What percentage of the revenue does each party get each month? What happens if the ISV partners with another VAR on a similar project? Who is responsible for the customer support costs? Whose brand will be on the end user solution, and who will bear the cost of marketing? If these considerations, and a host of others, aren’t addressed in the contract, partners can find themselves embroiled in a bitter legal battle or hostile working relationship they can’t afford to get out of.