Recently I’ve been putting in quite a few evenings and weekends working on one of my side projects, the Instagram WordPress plugin Intagrate (née Instagrate Pro), due to the recent changes Instagram imposed on access to their API from June 1st.
Instagram announced back in November last year that they were making changes to how developers accessed the API (allegedly following a password breach). After working through those changes to make my plugin compatible, I started thinking how precarious a business model it really is, relying on another service or product like this. I’m certainly not alone in doing this, but is it the most stupid thing ever or actually a viable model?
Of course I didn’t start out thinking, “I’m going to make money from Instagram”. The plugin started as a simple plugin to scratch my own itch, and quickly got released on the plugin repository so other people could have their Instagram images automatically published on their WordPress sites. It took six months to realize there was enough interest and scope in the plugin that I could monetize it, and the Pro version was built.
At the time (mid 2012), Instagram was in its infancy, but with a pretty robust API that anyone could sign up and use. It was great, here was a service that was being used by countless iOS users with a good portion wishing that WordPress was an option, alongside Twitter, Facebook and Tumblr, to post their images to. I had built the first solution for this problem that I was aware of, and after jumping on the premium plugin bandwagon I couldn’t believe my luck that my product had such a large, ready-made audience.
My monthly sales figures were good enough to nicely supplement my income but perhaps not at the giddy heights of some of the plugin business transparency reports that do the rounds of the WordPress developer community every year. However, when Instagram announced their platform update, it was clear my small plugin was at risk and I realized I needed to fight to keep the plugin and the income alive.
Instagram’s changes meant that every new API client app created after November 17th 2015 would enter sandbox mode and would require approval before going live. Existing accounts would need to be approved before June 1st, 2016, or they would be automatically sandboxed. Clients would need to fit into one of a limited selection of use cases, with the introduction of ‘Permission Scopes’ for various parts of the API, such as access to public content (not just that of the connected account), Comments, and Likes. When submitting the client for review you would need to supply a screencast video of your product demonstrating the authentication and interaction with the API. I looked to Twitter to see how this review process was working out for developers. It didn’t fill me with confidence:
@mikeyk Instagram review process for API use broken. My app is rejected & my video walkthru has zero views. No response to support requests.
— John Morton (@johnmorton) December 14, 2015
— BHN (@swingoflife) December 17, 2015
I started my submission for review last month (I do most things last minute) and it didn’t go smoothly. I started out with the API client used by the free version, submitting a new client for review so as not to interrupt existing users as the client had to be sandboxed during the review process (Instagram were not clear if the review would create downtime for the client app, so I assumed the worst case scenario).
The first submission was rejected. I instantly felt that feeling in the pit of my stomach. That feeling of a little trepidation and mostly “I’m screwed”. Luckily the rejection was based around the misunderstanding that the client was being used by a one-off project, not as one client that would service many users and many projects. After a second submission with some clarification, it was accepted and I was cooking with gas.
This was a confidence boost, but I still had the app for the premium plugin to go, and I was wary of how Instagram would view a money making product piggy-backing off their service, even though they didn’t explicitly mention or disallow premium products in their terms of service. This review needed to be slightly different, as the premium plugin allows you to access any public images, by username, hashtag and location. This required a separate part of the submission for the permission scope. Straight away I was faced with a big red rejection again. This time on a general issue of breaching the terms of service regarding brand. I was relieved that it wasn’t an ultimate “No” because of its premium nature.
A Rose by Any Other Name
The branding issue was a silly one, one that, unless Instagram had recently altered their API terms of service, I had ignored from day one:
You cannot use “insta”, “gram” or “Instagram” in your company or product name
“Instagrate Pro” wasn’t going to work anymore, as much as I loved the name as I had been saying it for the last 4 years! A rebrand was necessary if I wanted the plugin to continue, as much as that would be a hassle and come with some downsides. One of the great things about working with the Delicious Brains team is that it’s like having a set of great advisors on tap. After some good advice and an excellent name brainstorming session with the team, a very subtle rebrand to Intagrate (S, what s?) was decided upon.
This meant I had to work through getting the new domain, spin up a new site on the server, migrate over the old site’s database and media, configure the SSL certificate, and redirect the old site. I also had to push out updates to both the premium and free plugins, but took the opportunity to remove the ‘Pro’ and rebrand the free plugin as “Intagrate Lite”. This took time and unfortunately I couldn’t get intagrate.com so settled with the .io domain. Hopefully any issues with SEO for the redirect will be negligible as most of my traffic comes from the free plugin on the repository.
However, it seems that becoming compliant with the API changes puts my product in the minority, as the review process seems to have claimed a few victims, including the iOS app Flipboard. This has actually worked in my favour and after announcing the plugin would work beyond June 1st, May turned out to be a record month of sales!
The People v. Twitter
This isn’t the first time a large company has made changes to their API that has impacted the developer community around it. Back in 2012 Twitter made some controversial changes that caused widespread issues for developers building products and business based on the Twitter platform, most notably Tweetbot. I remember thinking back then that something like this was inevitable for Instagram and rationalized that if it happened and my plugin was affected, then so be it, I would have done well while it lasted. Of course, Intagrate has never been my only focus or sole income which partially explained my pragmatic attitude. Back then I viewed this kind of piggy-back business model as fundamentally flawed and one that would always live on borrowed time.
The Model Works
So why now did I fight so hard to keep Intagrate going? This would have been the perfect time to wrap things up and concentrate on working on something that had no major dependencies, and a lifespan that was purely down to me. Aside from wanting to maintain the income, the reasons as I see it, are still the same as they are when starting the premium product:
- Development is fast and easier, working with existing platforms
- You leverage an existing, ready made audience and community
- You can solve problems within a defined workflow
After all, these are the same reasons I build and sell addon plugins for Ninja Forms and Easy Digital Downloads. Hell, many of us are doing it by building and selling products and services for WordPress!
It’s a two way street. These types of parent products actually benefit from growing a developer community around them. Having products built for them both enhances them and increases exposure. I’m not sure WordPress would have grown to a 25% market share of the web without this kind of symbiotic relationship with theme and plugin businesses.
But what is the alternative? Put on your thinking cap and dream up the next big thing – the next Instagram or Twitter or WordPress? Build a product that is a parent not a child. Not so simple. First of all, original is hard, as is taking an existing idea and making it better. And second of all you are fighting against all three of the reasons mentioned above. Build from scratch, solve a new problem, and find customer 1, 2, 3, 10 and so on.
However, It seems like there are some smart people out there who are pitching their product as service agnostic. Solving a problem faced by a wider range of users regardless of the primary service they use. For example, Buffer started out as a tweet scheduler for Twitter, but now caters for other social media channels. Baremetrics, the analytics and insights tool for Stripe, will soon be supporting Braintree analytics as well.
Of course these products both started out as dependant on one platform but managed to transcend that dependency and widen their offering as they grew, because the problem they solve exists across multiple services. This is something we have been thinking about for a while when it comes to solving the database merging problem with Mergebot. Although Mergebot will initially be a WordPress product, the issue of database merging afflicts any CMS or database driven application. The potential is there, as well as longevity and security in being standalone without inherent dependencies.
How do you view this type of piggy-back business model? Is it inevitable or something we should avoid? Let me know in the comments below.