Consider Change When Developing Social Media Apps - SoDA - The Digital Society


SoDA Blog Leadership Ideas and Opinions

« Back to Blog

Consider Change When Developing Social Media Apps

by Bradley Gross, Esq. / August 24, 2010

Note: This blog entry is available in English only.

Change is inevitable.  But when it comes to developing apps for social media sites, change has to be considered, even accommodated, by client and agency alike.  Unless everyone understands and appreciates the ever-changing technical landscape of social media sites, expectations will be disappointed and, worst of all, lawyer letters will surely follow.

Here’s an all-too-real hypothetical: an agency is hired to build the next great Facebook app.  The project involves big money (which is a good thing, no?), and the app must be delivered in thirty days.  The agency accepts the deal, the app is developed and launched on time, and it goes viral.  All is well in the world, right?

Maybe not.

Assume that a few days after the app launches, Facebook announces a major change to its API.  Let’s say, for instance, that Facebook announces plans to eliminate iFrames, or reduce the available space on static FBML custom tabs by a third, from 760 to 520 pixels—which will really mess up the client’s magic app.  (Think that can’t happen?  It did.  Check out the Facebook transition doc HERE.)

So, now that the beloved app has been given a death sentence, what do you think happens next?

C’mon, you know what happens.

Ok, I’ll say it.

The client and the agency have a conference call during which one (or more) of the following are offered by the client:

–          “Hey agency!!  How come you didn’t know about this major change?  I thought that’s what you guys do!”

–          “We expect the agency to change the app to work with this new API—at no extra cost.  You knew what our budget was, and we simply can’t spend another dollar making this thing work.”

–          “This app is viral.  It cannot go down for even a day.  If it does, we’re dead—and we’ll look to the agency for indemnity.”

–          “Our lawyers tell us that this was a foreseeable event.  So, how do you want to proceed?” (Might I suggest the answer, “gingerly”.)

Now what?  None of the options is particularly inviting.  Let’s go through some of them.

Option 1:  The agency concedes the issue to the client, and spends thousands of uncollectable dollars to make the app compatible.  By doing so, however, the agency establishes a precedent that it will make future apps compatible, at no charge, when third party APIs change.

Option 2:   The agency doesn’t concede the issue, claiming that the API change was neither foreseeable nor covered under the development deal.  The client promptly drops the agency, retains another agency to get the work done, and bad-mouths the original agency at every opportunity.  Alternatively, the client threatens to sue the agency, forcing the agency to accept option 1, above.

Option 3:  Litigation, ‘nuff said.

There are a few other options available to the parties, but my point is this: there’s no easy way to resolve this problem.  Instead, the agency and the client should avoid the situation altogether by handling the issue in the parties’ development agreement.

The contract language can be written in any number of ways, but I suggest taking a very direct approach that educates everyone about the issue, and sets the parameters within which the problem, if it arises, will be handled.

At a loss for words?  Try this:

The parties understand and agree that from time-to-time, [insert social media site here, such as Facebook] may change its API and/or platform-compatibility requirements, which could render Client’s application partly or fully inoperable.  Agency does not warrant or represent that Client’s application will be operable or compatible with any version of [social media site’s] API or platform other than the API and/or platform that exists as of the date of delivery of the application to Client.  If changes are required to make the application compatible with future versions of [social media site’s] API or platform, such changes will be performed by Agency on a time and materials basis.

Ok, I just gave you a “get-out-of-a-legal-jam-free” card.  Now use it, and consider API and platform changes when developing apps for social media sites.  Questions?  Comments?  Let me know….




  1. Alex Levashov on August 31, 2010

    Great advice, Bradly, may save agencies good money and a bunch of brain cells.

  2. Brian Griffin on September 06, 2010

    Really good point--wish I thought of that a few months ago. N

  3. Michael Chan on September 15, 2010

    your suggestion in the development contract is one of many benefits I received after I jointed the SoDA round table discussion group.
    I hope many will join to make this community grow to its full potential.