One fine day, late summer 2013, I noticed that Apple had added a ton of new functionality to iOS, in particular related to barcodes. This set a train of thought in motion, the fruits of which are just now beginning to show.
Apple investing into barcode technology opened my eyes to the technology. Our eyes have learned to not see the barcodes and consider them as white noise. The iOS 7 news were beginning to undo this learned barcode noise filter in my brain.
I began to see barcodes everywhere. UPCs on physical products, serial number barcodes on devices and boxes, delivery service tracking labels, and many more.
Barcodes are simply numbers which are represented in a fashion that can be deciphered by a barcode scanner. This technology – based on a laser – has been around 40 years this year in commercial use. Scanning technology based on CCDs is relatively new, but is now on par with lasers. So much so that all iOS 7 devices have a built-in barcode scanner, available for free to be used by any developer.
In short, barcodes are a mature technology – being 40 years in production – and they meet up with the rise of mobile technology. Always-on Internet connectivity, mobile sensors and a camera for scanning form a technology nexus. Everybody with an iPhone is carrying the ability to scan barcodes and retrieve information about them over the Internet.
So went my thought process.
Then I began to research into what sources of product information could be tapped to make sense of those scanned numbers. I found the Amazon Product Advertising API and toyed with some queries. But then I found their terms of service which forbid use of this API in mobile applications and on websites optimized for mobile devices. Bummer!
Searching for Product Info
My search continued, I found a few more silos of data, until I contacted GS1 the worldwide authority managing product numbers. They refer to them as GTINs, Global Trade Identification Numbers instead of UPCs or EANs… this was only one of many hurdles to understand when diving into barcode technology.
You would expect for the standards body to have a database of all products… but you would be wrong. They have around 6 million products in their GEPIR database, accessible only through an obscure SOAP-based API. Do I hear a “yuck!”?
Next I talked to a US-based company which had collected – mostly by scraping – 30 million products. But there it dawned on me that the only way to be able to offer product information that is unencumbered by licensing issues would be to collect those yourself.
Enter: A Book Contract
Then in September I got contacted by a book publisher’s Acquisitions Editor, who asked me if I would have a book in mind. It so happens that I had 3 ideas to pitch, but I felt the most passionate about barcodes. After a short back-and-forth about the TOC, the book contract was signed and I went to work on it.
The book “Barcodes and iOS” which will be done and published later this year is looking at barcodes as a common thread throughout the book. It explains what kinds of barcodes are supported by iOS 7 and where they are usually used. With this foundation it goes on to explain a variety of technologies somehow related to barcodes. The point of the book is to open your eyes to the promises of barcodes meeting mobile devices. With this book under your belt you will begin to see opportunities for a new kind of mobile apps everywhere.
To this date I have produced 4 out of 7 chapters. The first three are with 10 reviewers for the first review and I hope they like what I created.
The Product Layer for the Internet
Around the same time when I started working on the book I put together a vision document about a web-based Product API which I sent to a few interested people for feedback. I called it PAPI, but I was told that this is an unfortunate name, in particular for US people.
One piece of feedback came from Jonathan Libov who on July 28th, 2013, mailed me:
What’s the elevator pitch? “Product information as a service” is not such a bad one IMO. Or, to paraphrase Mr. FourSquare himself, “the product layer for the internet”.
And so the baby got a new name. Thanks Jonathan!
The whole thing was cooking on small flame for a couple of months, until in December 2013 I decided that I wanted to try out 99 Designs to have a logo for ProductLayer. Even if is not ideal from a marketing point of view, having a logo for the project somehow made it “more real”.
At that time I had pitched ProductLayer to several of the people around me, amongst them one who decided to quit his full-time job and start working on it full time as of February 2014.
What is it?
ProductLayer – from the point of view of mobile app development – is the API you need to build product-centric apps. It will be a modern and simple JSON/REST-based API which lets you retrieve basic product information for each scanned bar code.
Imagine designing beautiful apps for organizing a user’s books, audio media, DVDs and Blue-rays, perishable food, medicines … there is no limit to your imagination.
ProductLayer aims to get to the sweet spot between both worlds: official sanctioned product information and where this is – initially – lacking, crowd-sourced info. Initially it will happen that many products are not found by a barcode you scan. But the SDK which I will begin to work on after I finished my book will offer a way for any app using it to contribute simple product information back to the database. This way the first person adding a book title is multiplying the benefit to all subsequent people scanning the same book.
Of course there needs to be a commercial angle to this to be sustainable. We are going to work this as a start up. There are multiple places where revenue can come from. Affiliate commissions, advertising on product web pages, selling anonymous analytics to product vendors and many more.
As a developer we want to you to be able to experiment with many different kinds of apps. If you have one that sells incredibly well and causes lots of traffic on our servers then there will have to be a certain fee for that. But we will never ask you for a share of your profits. Rather we want to do tiered plans based on actual usage. A free tier up to a certain amount of traffic and then several tiers above that that adjust monthly to your needs per app. A couple of dollars per month to cover the cost.
The details for that will have to be hashed out, but the idea is that you are successful with your apps and have happy customers. And out of this bliss you will be happy to support ProductLayer which is the platform you built your product-centric apps on.
The Failure of Crowd-Sourcing?
There are several companies out there who tried crowd-sourcing data and who failed. We believe that this is a risk to us as well, but with a key difference. We want to be the platform and interesting and useful apps should be a multiplier. The more useful apps there are, the more users will use them. The more users scan products, the more products will be in the database.
We will be promoting your app heavily on multiple channels and also frequently highlight the coolest ideas. This will be free marketing for you.
On top of that we are working on a few strategies to get “official data” in there and to add gamification elements that allow users to correct other user’s mistakes and report spam.
In a way you could say we are still in the feasibility study stage. There are many unknowns. So we need your help.
Your Chance to Something Great
We launched a teaser page a few days ago at productlayer.com. There you can pre-register for a developer account. We are using this pre-registration number to gauge global interest in such a service. I might have been wrong; maybe I am the only developer who feels inspired by barcodes and product information… the registration stats will tell us.
Once we reach a certain number of registrations we can proceed with a private BETA where we will work with you on building prototypes for your ideas based on our API/SDK. The first version lets you query for GTINs, pictures, create products and upload pictures, plus a few more features. In time for you shipping your app we will have a stable v1 API that you can go into production with.
Me tweeting about it got us a few hundred developers in 2 days. I’m hoping that this blog post piqued your interest as well and you will go pre-register, too. Emails entered there will not be used for any other purpose then becoming a developer account.